Meltdown and Spectre

Meltdown and Spectre are 3 CPU vulnerabilities disclosed in 2018 that leak memory through microarchitectural side channels.

Side-channel attacks cover timing, power, electromagnetic, and fault leakage beyond these CPU flaws.

• Variant 1
  Bounds check bypass, CVE-2017-5753, Spectre.
• Variant 2
  Branch target injection, CVE-2017-5715, Spectre.
• Variant 3
  Rogue data cache load, CVE-2017-5754, Meltdown.

Microarchitectural Foundations

Side Channel Attacks

A side channel attack infers secret data from an observable side effect of a computation, such as timing, cache state, power use, or electromagnetic emission. The attacker never reads the secret through a legitimate interface, and the program’s logic has no bug that reveals it.

• Indirect nature
  The leak comes from shared hardware state, so a correct program under a correct OS can still be attacked.
• Hard to foresee
  Developers reason about the architectural behaviour of code, not its microarchitectural side effects.

Exploited CPU Features

• Out-of-order execution
  Starts instructions as soon as their operands are ready. Instructions are issued in order, executed out of order, then retired in order. This avoids stalls waiting for data.
• Speculative execution
  Goes further and executes ahead of a predicted branch. If the prediction was wrong, results are discarded, but microarchitectural state, the cache, is not fully reverted.
• Caching
  Keeps recently or nearby accessed memory in a fast cache. Cached data reads measurably faster than data from main memory.

Cache Side Channels

Measure how fast a memory location reads to infer whether it was cached.

• Flush + Reload
  Flushes attacker-controlled memory from the cache with clflush, lets the victim run, then times reloads of each line to see which the victim touched.
• Evict + Reload
  Does the same, but evicts specific cache lines by loading other data instead. Used on CPUs without a flush instruction.

Meltdown

Meltdown breaks isolation between a user program and the OS. A faulting load from a kernel address still forwards its value to dependent speculative instructions before the fault retires, so the program reads kernel memory. It needs the CPU to forward data from a permission-violating load, so it hits mainly Intel and some ARM cores, not AMD.

Attack

1. Allocate a probe array of 256 pages, $256 \times 4096$ bytes, none yet cached.
2. xor rax, rax to clear the register.
3. mov al, byte [rcx] reads one byte from the kernel address in rcx into the low byte of rax. The load is illegal from user mode, but the fault is only raised when the instruction retires. Until then the loaded byte feeds the instructions below.
4. shl rax, 0xc multiplies the secret byte by 4096, the page size. Each of the 256 possible values lands on a distinct page, and the hardware prefetcher cannot create false hits.
5. mov rbx, qword [rbx + rax] accesses page number secret of the probe array, caching exactly that page before the privilege check faults.
6. Catch the exception, then time a read of each of the 256 pages. The one that reads fast reveals the secret byte value.

Mitigations

• KPTI (Kernel Page-Table Isolation)
  Each process gets 2 page tables. In user mode a shadow table with the kernel mostly unmapped is active, so kernel memory is not present to leak. Switching to kernel mode swaps to the full table. This carries a performance cost.
• KASLR
  Randomizes the kernel address space each boot.

The real fix is redesigning the CPU, which is slow and costly. These are software patches in the meantime.

Spectre

Spectre breaks isolation within one privilege level, between processes or between a sandbox and its host. It tricks a correct program into speculatively reading its own secrets past a security check. It relies only on speculation, so it affects nearly all speculating CPUs, including AMD.

The victim speculatively touches memory it is allowed to access, so KPTI does nothing against it.

Variant 1

Conditional branch misprediction. The target is a bounds check such as if (x < array1_len) y = array2[array1[x] * 4096].

1. Call the victim code many times with valid x, so the branch predictor learns that the branch is taken.
2. Flush array2 and array1_len from the cache. A slow array1_len load widens the speculation window.
3. Call the victim code with an out-of-bounds x, chosen so array1[x] is the address of a secret byte.
4. The CPU predicts the branch as taken and speculatively runs the body. It loads the secret byte $s$ and reads array2[s * 4096], which caches 1 page of array2.
5. The bounds check resolves as failed. The CPU discards the results, but the cached page stays.
6. Time reads of each page of array2. The page that reads fast reveals $s$.

Mitigation: put an lfence after a bounds check to block speculation past it, or mask the index into a safe range instead of branching.

Variant 2

Indirect branch poisoning. The target is an indirect branch in the victim, such as a function pointer call.

1. Find a Spectre gadget in the victim’s address space. It reads a secret and uses it to index a probe array, leaving a cache trace.
2. Train the Branch Target Buffer (BTB) from the attacker’s process. Repeatedly run an indirect branch at an address that aliases the victim’s branch, with the gadget’s address as its target. Only the low 31 bits of the branch address index the BTB.
3. Flush the probe array and the victim’s real branch target from the cache, to widen the speculation window.
4. The victim executes its indirect branch. The BTB predicts the gadget, so the CPU speculatively runs it and caches a probe array page selected by the secret.
5. The misprediction is detected and the results are discarded, but the cached page stays.
6. Time reads of the probe array to recover the secret.

Mitigation: retpoline replaces indirect branches with a construct that steers speculation to a harmless spin loop instead of the poisoned BTB target.

Other Mitigations

• Microcode features (IBRS, IBPB, STIBP) restrict or flush the BTB across contexts.
• Chrome site isolation puts one site per process, so a speculative leak only reaches same-site data.

Check a Linux system with speed47/spectre-meltdown-checker.