Spectre and Meltdown

In January 2018, two security vulnerabilities—Spectre and Meltdown—were publicly disclosed. They showed us yet again that our computers, and the data we store in them, are more vulnerable than we might think.

Four independent research teams discovered these vulnerabilities within a span of months. Both attacks abuse speculative execution to allow unprivileged users to read privileged data through a side channel. The underlying performance techniques, including branch prediction and speculative execution, have existed for decades. It is difficult to know whether others encountered the same class of attacks earlier and used them privately.

To understand how Spectre and Meltdown work, we first need some background on side-channel attacks, out-of-order execution, speculative execution, and branch prediction.

Background knowledge

A side-channel attack steals information through effects created by a system’s implementation rather than through a weakness in the implemented algorithm itself. These effects can include timing, power consumption, electromagnetic emissions, and other measurable physical behavior.

Spectre and Meltdown use cache-timing attacks. Modern CPUs use caches to hide slow memory-access latency, and a cache hit is significantly faster than a cache miss. An attacker can flush a targeted memory location and then measure how long it takes to reload. That timing reveals whether another process loaded the data into the cache in the meantime. The victim sees no direct fault or visible change.

Out-of-order execution

Out-of-order execution improves processor performance by executing instructions in a different order from the one in which they appear, as long as the final result remains correct. Hardware examines a moving window of instructions, selects instructions that are ready, and holds their intermediate results. It then commits those results in the original program order so that execution appears sequential.

In theory, users should notice only that programs run faster. However, a processor may perform a privilege check and a memory access at the same time. If the memory access finishes before the privilege check, protected data may be loaded into the cache. Even if the processor later rejects the instruction, that cache state can remain observable.

Speculative execution and branch prediction

Speculative execution and branch prediction are two other techniques used by modern CPUs. With speculative execution, instructions can enter the pipeline and begin running before the processor knows whether they will actually be needed.

When a CPU encounters a conditional branch, its branch predictor estimates which path is most likely. The CPU fetches and begins executing instructions along that path before the condition has been fully evaluated. If the prediction is correct, execution continues without a pipeline stall. If the prediction is wrong, the CPU discards the architectural results—but may leave behind changes to its microarchitectural state, including the cache.

How Meltdown works

Meltdown takes advantage of out-of-order execution to make the CPU load privileged data into its cache. The attack can be understood in three steps.

First, the CPU encounters an instruction that accesses a value, A, at an address the process is forbidden to read. Because of out-of-order execution, the CPU may schedule the privilege check and memory access together. The attacker cannot read this protected memory directly.

Second, before the CPU recognizes the illegal access and raises an exception, speculative instructions use A to access another memory address chosen by the attacker, such as Base + A. This loads a corresponding location into the cache. When the privilege check eventually fails, the CPU discards the direct result but does not necessarily undo the cache change.

Third, the attacker measures access times across the chosen memory range. The location at Base + A loads faster because it is already cached, revealing the value of A through a side channel.

An analogy for Meltdown

Imagine that a family goes shopping and the father will pay the bill. One approach is for each family member to enter the store one at a time, choose an item, pay, and leave. This is orderly, but slow.

Instead, everyone enters together and picks out what they want. They line up at the checkout afterward so their purchases can be finalized in order. At the register, the father realizes that he forgot his wallet. The transaction fails, nobody may leave with the goods, and no receipt is created.

But the selected items have already been brought to the checkout counter. Someone looking at what was left there could infer what the family intended to buy. The failed transaction is like an exception, the goods at the counter are like cached data, and the observer’s inference is the side-channel attack.

How Spectre works

Spectre and Meltdown share several techniques. Both encode confidential information in microarchitectural state and recover it through a timing side channel. Their primary difference is how they gain access to the information in the first place.

The original Spectre paper describes variants that exploit conditional and indirect branches. In both cases, an attacker first mistrains the branch predictor so it will later make an incorrect prediction. The attacker also delays the data needed to resolve the correct control flow. During that delay, the CPU speculatively executes code that accesses confidential information and encodes it in the cache. The architectural effects are discarded, but the attacker recovers the secret by measuring cache timing.

Similarities and differences

Both attacks require the attacker to execute code on the target system, and both use a side channel to recover information from memory that was accessed transiently.

Spectre tricks a program into accessing arbitrary locations within that program’s address space. Meltdown allows a process to read privileged memory mapped into its address space even though the process would normally be forbidden from accessing it.

Meltdown can be addressed through software techniques that isolate kernel memory, although those mitigations may reduce performance. Spectre describes a broader class of attacks and therefore does not have one universal patch, though hardware and software mitigations can reduce its impact.

System-design lessons

Every system-design decision involves tradeoffs. Out-of-order and speculative execution were introduced to improve performance, but they created security consequences that were not adequately represented by the abstractions exposed to software.

This makes Spectre and Meltdown powerful examples of leaky abstractions. Speculative and out-of-order execution are intended to remain invisible at the architectural level. Ideally, instructions that are never committed should have no visible effect on user code. In practice, they can load data into the cache, and those cache changes remain measurable. Developers building reliable systems therefore sometimes need to understand the implementation details beneath an abstraction, especially when those details affect security or performance.

They also reinforce the importance of planning for security from the start. It is easier to establish and preserve an invariant—such as preventing unauthorized data from influencing observable state—than to retrofit that invariant into decades of hardware and software optimization.

Finally, mobile code deserves particular caution. Sending code to another system can provide more capability than sending data alone, but that capability brings risk. Spectre and Meltdown both rely on running seemingly harmless code on a target system to extract information. Code that manipulates or influences other code, from compilers to processor control logic, must be treated as part of the trusted computing base.

Conclusion

After Spectre and Meltdown, researchers found additional vulnerabilities targeting speculative execution, including Foreshadow, SPOILER, and Microarchitectural Data Sampling. The disclosure of these attacks opened a new area of security research and demonstrated that even behavior designed to be invisible can become observable through side effects.

The deeper lesson is that performance optimizations do not exist outside the security model. When software and hardware share resources such as caches, small timing differences can expose information across boundaries that otherwise appear sound.

References

1. Andy Greenberg, “Triple Meltdown: How So Many Researchers Found a 20-Year-Old Chip Flaw at the Same Time,” Wired, January 7, 2018. https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/

2. Swarup Bhunia and Mark Tehranipoor, Hardware Security, 2019.

3. Yuval Yarom and Katrina Falkner, “FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack,” 2014. https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/yarom

4. Yoav Etsion, “Computer Architecture: Out-of-order Execution.” https://iis-people.ee.ethz.ch/~gmichi/asocd/addinfo/Out-of-Order_execution.pdf

5. Moritz Lipp et al., “Meltdown: Reading Kernel Memory from User Space,” 2018. https://meltdownattack.com/meltdown.pdf

6. Joel Hruska, “What Is Speculative Execution?” April 5, 2021. https://www.extremetech.com/computing/261792-what-is-speculative-execution

7. Paul Kocher et al., “Spectre Attacks: Exploiting Speculative Execution,” 2019. https://spectreattack.com/spectre.pdf

8. Joel Hruska, “Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches,” May 20, 2019. https://www.extremetech.com/computing/291649-intel-performance-amd-spectre-meltdown-mds-patches

9. Joel Spolsky, “The Law of Leaky Abstractions,” 2002. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

10. Craig Disselkoen et al., “The Code That Never Ran: Modeling Attacks on Speculative Evaluation,” May 2019. https://cseweb.ucsd.edu/~cdisselk/papers/code-that-never-ran.pdf

11. Jann Horn, “Reading Privileged Memory with a Side-Channel,” Project Zero, January 3, 2018. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

12. Linux kernel documentation, “Spectre Side Channels.” https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/spectre.html

13. Peter Bright, “Meltdown and Spectre: Here’s What Intel, Apple, Microsoft, Others Are Doing About It,” Ars Technica, January 5, 2018. https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/