In January 2018 the whole computing industry had a very bad week. Researchers at Google Project Zero and several universities revealed that essentially every high-performance CPU built in the previous two decades — Intel, AMD, ARM, the lot — leaked secrets through the very feature that made them fast: speculative execution. The patches that followed slowed servers worldwide by measurable percentage points, and cloud providers rebooted their entire fleets. Two attacks led the headlines: Meltdown and Spectre.
The lesson is profound and a little unsettling. Everything you have learned about
A modern out-of-order core runs instructions ahead of certain knowledge — past an unresolved branch, or before a permission check has finished. If the guess was wrong, the reorder buffer discards the results and the programmer never sees them. But along the way those transient instructions may have touched memory, and touching memory loads a line into the cache. Squashing the instruction does not evict that line. The data value is gone; the fact that a particular address was accessed survives, recorded as a difference in how fast that address responds next time.
The trick that turns a value into a measurable cache footprint is the flush+reload covert channel, and it is worth seeing on its own before we build the full attacks on top of it.
Set up a probe array with 256 slots, each on its own cache line, and imagine we want to smuggle out one
secret byte
Notice the secret never travels through a register the attacker can read; it travels through the cache-vs-not-cache status of the array. That is the covert channel. Run it below — we simulate access latencies and recover the byte purely from which slot is fast.
On the affected Intel chips, a load from a kernel address you have no right to read still executes speculatively while the permission check runs in parallel. The permission fault will eventually squash the instruction — but out-of-order execution lets a second transient instruction use the forbidden byte first, before the fault retires:
Architecturally the illegal read is annulled — the program that ran it just gets a segmentation fault. But the cache footprint of step 2 survives, and flush+reload reads the kernel byte out of it. Repeat byte by byte and you can dump the entire kernel — passwords, keys, anything — from an unprivileged process. Meltdown melts the fundamental isolation between user and kernel that the whole operating-system model depends on.
Spectre is subtler and, sadly, more durable. Instead of running an illegal instruction, it tricks a
victim program into leaking its own secrets by abusing
The attacker first calls this with many in-bounds
| Meltdown | Spectre (v1) | |
|---|---|---|
| Boundary broken | user ↔ kernel isolation | within-process bounds / sandboxes |
| Mechanism | out-of-order use of a faulting load | mistrained branch prediction |
| Leak channel | cache (flush+reload) | cache (flush+reload) |
| Fixable in OS? | yes — KPTI unmaps the kernel | no clean fix; per-gadget hardening |
| Root cause | a specific Intel oversight | speculation itself |
There is no single patch, because these are not bugs in the ordinary sense — they are consequences of doing speculation at all. The defences chip away at specific gadgets, and each has a price:
The uncomfortable summary: Meltdown was largely closed by KPTI and new silicon, but Spectre is a family, not a bug. As long as CPUs speculate — and they must, to be fast — new variants keep appearing, and mitigation is a permanent, case-by-case tax on performance.
The kernel-unmapping defence was published in 2017 as KAISER, by researchers at TU Graz, as a fix for a different problem: they wanted to stop attackers defeating kernel address-space layout randomisation (KASLR) by timing the TLB. Their remedy — don't map the kernel into user space — turned out, months later, to also block Meltdown, which the same group then co-discovered. Linux adopted it under the name KPTI, sometimes jokingly expanded as "Forcefully Unmap Complete Kernel With Interrupt Trampolines" (initials left as an exercise). A rare case where a mitigation existed before the world knew it needed one.
It is tempting to lump them together — both leak via cache timing after speculation — but they differ where it matters. Meltdown exploited a specific implementation flaw (using a faulting load's data before the fault retired) and is genuinely fixed by KPTI and by newer hardware that never forwards privileged data speculatively. Spectre attacks the concept of speculation through the branch predictor; it cannot be "patched away" because the predictor is doing its job correctly. Believing one fix covers both, or that a software update makes the class disappear, is exactly the mistake that keeps these vulnerabilities alive. Defence here is ongoing hygiene, not a one-time cure.