Spectre and Meltdown: When the CPU's Cleverness Became a Leak

Imagine a librarian so eager to help that the moment you start asking for a book, they sprint off to fetch what they think you will want next, before you have even finished your sentence. Usually they guess right and you are served in a flash. When they guess wrong, they quietly put the book back and pretend it never happened. Clever. But here is the twist. Even after they reshelve the wrong book, the shelf it came from is now slightly warm, and someone watching closely can tell which book was touched. From that warmth alone, they can work out a secret you were never shown.

That warm shelf is the whole story of Spectre and Meltdown. Most vulnerabilities are mistakes in software, a line of code someone wrote wrong. Spectre and Meltdown were different and far more unsettling. They were flaws in the way processors themselves are designed to work fast. Disclosed in early 2018, they showed that a performance trick built into nearly every modern CPU could be turned into a way to read memory that should have been completely off limits.

First, what a CPU is trying to do

The CPU, or central processing unit, is the part of a computer that actually carries out instructions, one after another, billions of times a second. For decades, making CPUs faster meant simply running them at higher speeds. When that approach ran into physical limits, chip designers turned to a different idea. Instead of doing one thing at a time and waiting, why not work on several things at once and get ahead of the game?

That instinct, to never sit idle, is the engine behind the two tricks at the heart of this story.

The clever trick: speculative execution

Programs are full of decisions. A typical one looks like "if this value is inside the allowed range, then read that piece of data". Checking the condition takes time, because the value being checked might still be travelling in from slow memory. A cautious CPU would stop and wait for the answer before doing anything else. That waiting is wasted time.

Modern CPUs refuse to wait. When they hit a decision, they guess the most likely outcome and start doing the work ahead of time, on the assumption the guess is correct. This is called speculative execution, because the CPU is speculating about what will happen. If the guess was right, the answer is already prepared and time was saved. If it was wrong, the CPU throws the speculative work away, rolls back its visible state, and carries on as if nothing happened.

The problem is that "as if nothing happened" was not quite true.

The leak: guessing leaves footprints

When the CPU speculatively runs work it later discards, it is careful to undo the results you can see directly. Registers get reset, wrong answers get erased. But it does not fully undo the side effects, the incidental traces the work leaves behind. The most important of these lives in the cache.

The cache is a small, very fast pocket of memory that sits right next to the CPU and holds recently used data, so the CPU does not have to make the long trip out to main memory every time. Here is the key fact. Data that is sitting in the cache is fetched noticeably faster than data that is not. And whether a given piece of data is in the cache or not is something you can measure, simply by timing how long it takes to read.

So the speculative work is discarded, but the cache still quietly remembers which memory locations that discarded work happened to touch. That memory is the warm shelf.

1. Trick the CPU into speculatively reading a secret it should not.
2. Have it speculatively use that secret to touch a specific memory location.
3. The CPU realises the guess was wrong and discards the result...
4. ...but the cache now carries a faint trace of which location was touched.
5. Measure memory access times to read that trace back, one bit at a time.

The reason step two works is subtle and worth spelling out. The attacker arranges things so that the exact memory location the CPU touches depends on the secret value. So by measuring which location ended up cached, and therefore fast, they learn something about the secret, even though they never got to read it directly.

This is the definition of a side channel: the secret is not read out in the open, it is inferred from a physical side effect, in this case timing. It is slow and indirect, reading the secret a fraction at a time, but it works, and it works on hardware that was doing exactly what it was designed to do.

The two attacks used this same core insight in different ways.

• Meltdown used it to break the wall between an ordinary program and the operating system's protected memory. Normally the operating system keeps its most sensitive memory, the kernel memory, strictly walled off from ordinary programs. Meltdown exploited a timing gap in how one family of processors handled that protection during speculation, letting a program read kernel memory it should never see.
• Spectre was broader and more troubling. It tricked other well behaved programs into speculatively leaking their own secrets, by manipulating the very predictions the CPU makes about which way a decision will go. Because it abuses a mechanism common to almost all fast processors rather than one specific flaw, it is much harder to fully fix.

The three official identifiers reflect this split. CVE-2017-5753 and CVE-2017-5715 are the two Spectre variants, and CVE-2017-5754 is Meltdown.

Why "just turn off the guessing" is not an option

A tempting reaction is to simply stop speculating. If guessing ahead is what leaks the secret, remove the guessing. The trouble is that speculative execution is not a small optional feature bolted onto the side. It is one of the main reasons modern processors are as fast as they are. Turning it off entirely would set performance back by years, making it a cure worse than the disease for most workloads.

That is why the real defences are surgical rather than blunt. They aim to close off the specific ways an attacker can steer speculation towards a secret, or to break the link between the discarded work and the measurable cache trace, while keeping the useful speed for everything else.

Defending against them

For almost everyone, the defence is unglamorous and effective. You do not need to understand microarchitecture to be protected, you need to keep the pieces of your system that others have already fixed up to date.

1. Apply operating system and firmware updates. The mitigations ship as operating system patches and CPU microcode updates, which are small pieces of code that adjust how the processor behaves, delivered through your hardware or system vendor. Keeping both current is the main protection.
2. Update browsers. Because these attacks can be attempted from code running inside a web page, such as scripts on a site you visit, browser makers added their own mitigations, including making their timers less precise so the tiny time differences are harder to measure. Stay on current versions.
3. Patch cloud and shared systems first. The risk is highest where untrusted code runs right beside sensitive data, such as multi tenant cloud hosts where many customers share the same physical machine. If you run such systems, they are the priority.

The takeaway

Spectre and Meltdown turned a universal performance optimisation into an information leak, using timing as a side channel to read secrets the CPU only touched by accident, then discarded. Meltdown broke the wall between a program and the kernel, while Spectre tricked well behaved programs into leaking their own secrets, which is why it has been so much harder to close. They are a landmark reminder that security lives at every layer, right down to the silicon, and that "we discarded the result" is not the same as "we left no trace". For the rest of us, the practical response is the familiar one. Keep your operating system, firmware, and browser patched, and if you run shared infrastructure, patch it first.