On January 3, 2018, three research teams simultaneously published findings about two classes of CPU vulnerabilities that affected virtually every modern processor manufactured since 1995. The vulnerabilities - named Spectre and Meltdown - were not bugs in software but flaws in the fundamental microarchitectural design of chips made by Intel, AMD, and ARM. There was no patch for the hardware. Fixes required changes to operating systems and hypervisors that, in some cases, degraded performance by 5-30%.

How Modern CPUs Work: The Background

To understand Spectre and Meltdown, you need to understand two CPU performance techniques: out-of-order execution and speculative execution. Modern processors do not execute instructions strictly in order. They look ahead in the instruction stream, identify operations that can be performed in parallel, and execute them simultaneously. When a branch condition is encountered - an if/else decision - the CPU cannot know which path will be taken until the condition is evaluated. Rather than stall and wait, it predicts which branch is more likely and begins executing it speculatively.

If the prediction was correct, execution proceeds normally. If incorrect, the speculatively executed results are discarded and the correct branch executes. The key word is "discarded" - the architectural state (registers, memory) is rolled back. But the microarchitectural state - specifically the CPU cache - is not fully rolled back. The speculative execution left traces.

[TECHNICAL NOTE]
The CPU cache is a small, fast memory that stores recently accessed data. When a program accesses memory, the cache line is loaded. Later accesses to that same address are fast (cache hit); accesses to uncached data are slow (cache miss). This timing difference - measurable with high-precision timers - is the side channel that both Spectre and Meltdown exploit. The attacks never read memory directly; they infer what was read by measuring how long subsequent memory accesses take.

Meltdown

Meltdown (CVE-2017-5754) was discovered independently by Jann Horn at Google Project Zero, and by researchers at Cyberus Technology and Graz University of Technology. It exploited a race condition between permission checks and speculative execution in Intel processors.

Operating systems maintain a strict separation between kernel memory (which contains sensitive data including passwords, encryption keys, and other processes' data) and user-space memory. When a user program attempts to access kernel memory, the CPU is supposed to raise a fault and deny access. But Intel's implementation allowed the CPU to speculatively execute instructions using that kernel memory - performing computations with the forbidden data - before the permission check completed and the fault was raised.

The exploit pattern: trigger speculative execution on a kernel address you're not allowed to read. The CPU loads that kernel data into a register speculatively. Use that register to index into an array - accessing different cache lines depending on the value. Then measure which array element is now fast to access. The bit pattern of the cache timing reveals the value of the kernel memory you were never allowed to read.

The fix was Kernel Page-Table Isolation (KPTI) - completely separating kernel and user-space memory in page tables so that kernel addresses are not even mapped into user-space processes. This required a TLB flush on every kernel-to-user transition, introducing significant overhead for workloads that make frequent system calls. Database servers and I/O-intensive workloads saw 10-30% performance degradation in initial benchmarks.

Spectre

Spectre (CVE-2017-5753, CVE-2017-5715) was more fundamental and more difficult to fix. Unlike Meltdown - which was specific to Intel and exploited a specific implementation flaw - Spectre was a class of attacks affecting AMD, ARM, and Intel chips. It targeted the branch predictor itself.

The branch predictor learns patterns from previous branch history. An attacker can train the predictor to expect a particular branch outcome by running code that creates that history. Then, in a victim process (a different program, or even a sandboxed context), when the CPU speculatively executes based on the attacker-trained predictor, it can be directed to speculatively access memory it would not normally access. The same cache-timing side channel extracts the speculatively touched data.

Variant 1 (bounds check bypass): An array access guarded by a bounds check can be speculatively executed with an out-of-bounds index if the branch predictor has been trained to expect the bounds check to pass. The CPU speculatively reads memory outside the intended array range, loading that data into cache. Subsequent timing measurements reveal what was read.

Variant 2 (branch target injection): An attacker manipulates the indirect branch predictor - used when a function call's destination is determined at runtime - to redirect speculative execution to an arbitrary gadget in the victim's address space. This is effectively speculative ROP (return-oriented programming).

[WARNING]
Spectre fundamentally undermines the security model of JavaScript JIT compilation. When a browser runs untrusted JavaScript, the JIT compiler generates native code and executes it in a sandboxed context. Spectre allows that sandboxed JavaScript to read the browser process's memory - potentially including other tabs' content, cookies, and saved credentials. All major browsers responded by reducing the precision of JavaScript timers (which are used to measure cache timing) and disabling SharedArrayBuffer (which provides a high-resolution implicit timer via a shared counter).

Discovery and Coordinated Disclosure

Jann Horn at Google Project Zero discovered both Spectre and Meltdown in June 2017 and notified Intel, AMD, and ARM on June 1, 2017. The disclosure date was set for January 9, 2018. Three separate research groups had independently discovered the same vulnerabilities: the Google team, the Graz University team (who found Meltdown), and a team from KU Leuven, University of Adelaide, and others (who found Spectre).

Intel, Microsoft, Google, Apple, Amazon, and other major vendors worked secretly for months to develop mitigations. OS vendors were developing KPTI patches. Cloud providers were preparing hypervisor updates - critical because in cloud environments, multiple customers share physical hardware; Spectre could allow one customer's VM to read another's data.

The embargo broke early. On January 2, 2018, a Linux kernel commit was publicly merged with descriptions that clearly implied the nature of the vulnerability. Security researchers immediately began analyzing it. By January 3, the full details were public - six days ahead of the planned disclosure date. The coordinated release scrambled into an emergency simultaneous publication.

Intel's Stock and Disclosure Timeline

Intel CEO Brian Krzanich sold $24 million in Intel stock in late November 2017, retaining only the minimum required by his employment contract. Intel disclosed the vulnerability to Intel, and the sale occurred after that notification but before public disclosure. The SEC investigated; Intel stated Krzanich's sale was pursuant to a pre-planned 10b5-1 trading plan established in October 2017 - potentially before Intel received the disclosure notification. The investigation was eventually dropped.

Krzanich resigned in June 2018 for an unrelated reason: Intel disclosed he had violated company policy with a relationship with an Intel employee.

Impact and Legacy

In the months and years following the initial disclosure, researchers discovered additional variants of both Spectre and Meltdown: SpectreRSB, Ret2Spec, Foreshadow (L1 Terminal Fault), MDS (Microarchitectural Data Sampling - RIDL, Fallout, ZombieLoad), PortSmash, TAA (TSX Asynchronous Abort), LVI (Load Value Injection), and others. Each required its own microcode update or OS mitigation. Many required microcode patches that could not be applied to older processors.

Intel added hardware mitigations to newer processor generations: eIBRS (Enhanced Indirect Branch Restricted Speculation), STIBP (Single Thread Indirect Branch Predictors), and SSBD (Speculative Store Bypass Disable). Each generation addressed specific variants but the fundamental tension between speculative execution performance and security remained. AMD's architectural choices meant AMD chips were largely immune to Meltdown and some Spectre variants, though not all.

The performance impact was significant in production deployments. Linux kernel developer Greg Kroah-Hartman described the situation as "really bad." Cloud providers migrated workloads to processors with hardware mitigations as fast as they could refresh hardware. For workloads like database servers and Linux containers with heavy system call overhead, the KPTI patches imposed 10-30% throughput reduction until hardware mitigations arrived.

Spectre in particular demonstrated a class of microarchitectural side-channel vulnerabilities with no complete fix. You can reduce the attack surface, degrade the timer precision, and add barriers around branch instructions, but the fundamental issue - that speculative execution leaves observable microarchitectural traces - cannot be fully mitigated without abandoning the performance optimization entirely. Every modern processor manufactured after 2005 or so relies on speculative execution as a central performance technique. The alternative is CPUs that are dramatically slower.

[INFO]
Google Project Zero set an unusual precedent with Spectre and Meltdown: after notifying vendors, they worked collaboratively on mitigations for months before disclosure. The standard Project Zero policy is a 90-day disclosure deadline with no extensions. For vulnerabilities affecting billions of devices with no complete software fix, the standard policy clearly did not apply. The disclosure timeline of seven months was a departure that generated significant discussion about responsible disclosure norms for architectural vulnerabilities.