On January 3, 2018, Google Project Zero, Cyberus Technology, and Graz University of Technology simultaneously published details of two families of vulnerabilities affecting virtually every modern CPU: Spectre and Meltdown. Spectre (CVE-2017-5753, CVE-2017-5715) exploited speculative execution to leak information across process boundaries. Meltdown (CVE-2017-5754) exploited out-of-order execution to read kernel memory from user processes. Both had been present in processors since the mid-1990s. Both were unfixable in hardware for deployed processors - mitigation required OS patches, microcode updates, and compiler changes that degraded performance.

The disclosures shook the semiconductor industry. Intel, AMD, ARM, and virtually every CPU manufacturer were affected to varying degrees. The cloud providers - Amazon, Google, Microsoft, Alibaba - had to patch millions of servers without taking customers offline, using a coordinated deployment that stretched the limits of live OS patching. Performance impacts of 5-30% were observed on specific workloads. The fundamental techniques used by Spectre and Meltdown exposed a class of vulnerabilities in CPU microarchitecture that researchers continue to explore - dozens of related vulnerabilities have been discovered in the years since.

How Modern CPUs Work: The Relevant Background

Modern CPUs achieve their performance through parallelism and prediction. Out-of-order execution allows the CPU to execute instructions in a different order than the program specifies, as long as the results are eventually correct - this fills pipeline stages that would otherwise stall waiting for slow memory operations. Speculative execution goes further: the CPU predicts which branch of an if-else construct the program will take and begins executing it before the condition is actually evaluated. If the prediction is wrong, the work is discarded. If it's right, execution continues without the branch stall penalty.

Both optimizations depend on the CPU doing work that may be discarded. The Spectre and Meltdown attacks exploit a property of this speculative work: although the architectural state (registers, memory) is not modified when speculative execution is discarded, the microarchitectural state - specifically, which cache lines have been loaded - is not rolled back. Cache state is a side channel: by measuring the time to access memory, an attacker can determine whether specific addresses were loaded into cache by speculative execution, revealing which values were accessed.

[TECHNICAL NOTE]
The Flush+Reload technique used in Spectre/Meltdown attacks: (1) Attacker flushes a probe array from CPU cache using the CLFLUSH instruction. (2) Trigger speculative execution of victim code that reads a secret value and uses it to index into the probe array - the speculative read loads probe_array[secret * 4096] into cache. (3) Even though the speculative execution was discarded, the cache line for probe_array[secret * 4096] remains loaded. (4) Attacker times access to each element of the probe array. The element that returns in ~4 cycles (cache hit) instead of ~100 cycles (cache miss) reveals the secret value. By repeating and averaging timing measurements, arbitrary kernel or process memory can be read at rates of kilobytes per second.

Meltdown: Breaking the User-Kernel Boundary

Meltdown exploited the fact that Intel processors (and some ARM processors) would speculatively execute instructions that accessed kernel memory from user space, even though permission checks would ultimately deny that access. On a correctly functioning processor, a user-space process attempting to read kernel memory receives a segfault - the kernel memory is mapped but marked as supervisor-only. The architectural access is denied.

The microarchitectural access, however, had already happened speculatively. The CPU had read the kernel memory value, used it in subsequent instructions (which were also speculatively executed), and loaded the probe array element corresponding to that value into cache - all before the permission check triggered the fault. The architectural side (registers, memory) was rolled back. The cache was not.

Meltdown was mitigated by Kernel Page Table Isolation (KPTI), also known as KAISER - a technique that keeps two separate page tables, one for user space and one for the kernel, with the kernel table not mapped in user space at all. With KPTI, there is no kernel mapping to speculatively access from user space. The performance cost of KPTI was significant for I/O-heavy workloads because every system call required switching page tables, flushing the TLB. Database servers and file servers with many system calls saw 5-20% performance degradation from KPTI alone.

Spectre: A Harder Problem

Spectre affected a broader range of processors than Meltdown and was significantly harder to mitigate. Spectre variant 1 (bounds check bypass, CVE-2017-5753) exploited speculative execution of array accesses beyond bounds that had been predicted to be in-bounds. Spectre variant 2 (branch target injection, CVE-2017-5715) exploited the branch predictor's indirect branch prediction to redirect speculative execution to attacker-chosen locations.

The fundamental problem with Spectre is that it attacks the speculative execution model itself - the mechanism that gives modern CPUs most of their performance. A complete fix would require disabling speculative execution, which is not a viable option. The mitigations instead tried to fence off specific attack paths: retpoline (return trampoline) replaced indirect branches with constructs that prevented the branch predictor from being trained to speculate to arbitrary locations; IBPB/IBRS/STIBP microcode updates added hardware barriers for indirect branch prediction; serializing instructions like LFENCE prevented speculation across security boundaries.

Spectre mitigations were incomplete and imperfect from the start. They addressed the specific disclosed variants while leaving the underlying principle - microarchitectural state leakage through speculative execution - available for exploitation through other techniques. The years following the initial disclosure produced a steady stream of related vulnerabilities: SpectreRSB, ret2spec, NetSpectre, MDS (Microarchitectural Data Sampling), TAA (TSX Asynchronous Abort), SRBDS, and others - each exploiting related side channels in CPU microarchitecture.

[WARNING]
The Spectre/Meltdown class of vulnerabilities has particular implications for shared environments. In a cloud computing context, multiple customers share physical CPU cores. Spectre allows a malicious virtual machine to potentially read memory from a co-resident VM on the same physical core. This threatens the fundamental cloud security guarantee that customer workloads are isolated from each other. Cloud providers' responses included hyperthreading toggles (disabling SMT increases isolation but halves effective core counts), core dedication for sensitive workloads, and microcode plus OS patching. The residual risk for highly sensitive workloads in shared clouds remains a consideration for threat models involving nation-state adversaries.

The Disclosure Coordination

Jann Horn of Google Project Zero independently discovered both Spectre and Meltdown in mid-2017 and reported them to Intel, AMD, and ARM on June 1, 2017. The vendors were given 90 days to develop fixes before public disclosure - an extension of the normal 90-day disclosure policy, given the complexity of developing cross-platform mitigations for hardware vulnerabilities.

The coordinated disclosure involved dozens of parties: CPU manufacturers, OS vendors (Microsoft, Apple, Linux kernel maintainers, Red Hat, Ubuntu, SUSE), cloud providers, and hypervisor vendors. The coordination worked largely as intended - all major OS patches were available on January 3, 2018, the day of disclosure. But the scale of the disclosure meant that information leaked early: Linux kernel patches for KPTI had been publicly visible in kernel development repositories for weeks before the January 3 date, and security researchers had begun speculating about their purpose.

Intel's disclosure timing also created a controversy: Intel CEO Brian Krzanich sold approximately $24 million in stock in November 2017, after being briefed on the vulnerabilities but before they were publicly disclosed. The SEC investigated and declined to pursue charges, concluding the sales were pursuant to a pre-established trading plan. The episode highlighted the information asymmetry that major vulnerability disclosures create.

[IOC]
Spectre/Meltdown mitigation verification: For Linux: check /sys/devices/system/cpu/vulnerabilities/ for the status of each vulnerability and the applied mitigation. The spectre_v2 file should show "Mitigation: Retpoline" or similar. For Windows: Microsoft released the Get-SpeculationControlSettings PowerShell module to check mitigation status. Cloud: verify hypervisor patches are current with your cloud provider's security bulletins; check whether SMT/hyperthreading is enabled for sensitive workloads. Performance: measure the impact of KPTI and Spectre mitigations on your specific workloads before deployment. Workloads with high system call frequency (databases, NFS servers) are most affected. For extremely sensitive workloads: evaluate dedicated bare-metal hosting to eliminate cross-VM Spectre risk. Ongoing: subscribe to CPU vendor security advisories - the Spectre/Meltdown class of vulnerabilities continues to produce new disclosures, requiring periodic microcode and OS updates.