Speculative Execution
Modern processors don't wait. While your code is running, the CPU looks ahead and starts executing instructions it predicts will be needed — before your program has officially asked for them. If the prediction is right, you get those results for free and the program runs faster. If the prediction is wrong, the speculative work is silently discarded and execution continues correctly.
This optimization — called speculative execution — has been standard in processors since the mid-1990s. It is responsible for a significant portion of the raw performance gains computers have seen over the last three decades. It is also what Spectre and Meltdown exploit.
Meltdown: The Wall Falls
Meltdown (CVE-2017-5754) broke the most fundamental security boundary in an operating system: the separation between user-space processes and kernel memory.
When a program speculatively accesses kernel memory — memory it is explicitly forbidden to read — the CPU, racing ahead, loads the data anyway before the permission check completes. The check fails and the access is officially "never happened." But the data left a trace: it changed the state of the CPU's cache.
An attacker can measure how long it takes to read from different cache locations — a technique called a timing side-channel — and reconstruct the forbidden data one bit at a time. Meltdown made it possible for a normal user-space process to read the entire contents of kernel memory at speeds of hundreds of megabytes per second.
// Simplified Meltdown concept (pseudocode)
// probe_array is a 256-page buffer in user memory
// secret_addr points to kernel memory we're not allowed to read
char secret = *secret_addr; // CPU speculatively loads this
// (permission check happens in parallel)
char dummy = probe_array[secret * 4096]; // cache footprint depends on secret value
// Permission check fires → access denied → CPU rolls back
// BUT: probe_array[secret * 4096] is now cached
// Attacker times access to each probe_array page:
// whichever is fastest reveals the value of secretSpectre: The Subtler Threat
Spectre (CVE-2017-5753 and CVE-2017-5715) is harder to explain and harder to fix. Where Meltdown was a specific bug, Spectre is a class of vulnerability rooted in the fundamental design of branch prediction itself.
An attacker trains the CPU's branch predictor — by running code that builds up a pattern the predictor learns — and then triggers a speculative execution path inside a victim process that would never be reached in normal execution. That speculative path leaks data from the victim's own memory through a timing side-channel.
The terrifying part: Spectre doesn't require a bug in the victim program. Any code that branches on secret data can be weaponized. It affects not just kernel memory but also sandboxed execution environments — including JavaScript running in a browser.
Disclosure and Impact
Google's Project Zero discovered both vulnerabilities in mid-2017 and notified Intel, AMD, and ARM under coordinated disclosure. The public announcement came January 3, 2018, earlier than planned after leaks forced their hand.
Virtually every device with a modern CPU — phones, laptops, servers, cloud infrastructure — was affected. Early patches for Meltdown caused measurable performance regressions: some server workloads on Linux saw 5–30% slowdowns depending on how heavily they relied on kernel calls. Browser vendors reduced the precision of timers and disabled SharedArrayBuffer globally as a short-term Spectre mitigation.
Hardware-level fixes arrived in later processor generations. Spectre-class vulnerabilities remain an active research area — new variants continued to be discovered after the initial disclosure, and the fundamental tension between performance optimization and isolation has no clean resolution.