What Is Spectre? How Can a CPU Leak Data It Wasn't Supposed to Read?

What if a CPU could reveal information from an operation that, architecturally, never happened?

That sounds like a contradiction. Either an operation executed or it didn't. If it didn't, how can it expose anything?

Modern CPUs execute instructions speculatively before knowing whether those instructions belong on the actual execution path. When they find out they were wrong, they discard the architectural results of that speculative work. The program behaves as if the incorrect path never ran.

But discarding architectural results is not the same as erasing every physical effect inside the processor. Some effects can persist at the microarchitectural level. And some of those effects are indirectly observable through timing.

That gap between what architecturally happened and what physically happened is where Spectre lives.

Why CPUs Don't Execute Instructions One at a Time

A CPU executing instructions strictly in order, one at a time, waiting for every result before starting the next instruction, would leave enormous amounts of hardware idle. Memory is slow compared to the processor. An instruction might need to wait dozens or hundreds of cycles for data to arrive. While it waits, every execution unit sits unused.

Modern CPUs are built around the insight that sequential, one-at-a-time execution is almost never necessary. Most instructions do not depend on the one immediately before them. A processor can execute multiple independent instructions simultaneously, dispatch them out of order to available execution units, and produce the same architecturally correct result as sequential execution would.

This is out-of-order execution. It is complemented by pipelining, which overlaps the stages of instruction processing so that while one instruction is being decoded, the next is being fetched, and the one before it is being executed.

Both techniques require the CPU to be working on instructions before all the information needed to fully resolve those instructions is available. The processor is constantly running ahead of what it knows for certain.

Branch Prediction

A branch instruction forces a decision:

if (condition) {
    // path A
} else {
    // path B
}

The CPU cannot simply continue fetching instructions until it knows which path to take. By the time the branch condition resolves, the pipeline is already several stages deep. Waiting would mean stalling the entire pipeline.

So the processor predicts.

A branch predictor observes execution history and makes a prediction about which direction each branch will go. If a branch has gone the same way the last forty times, it will probably go that way again. The predictor uses this pattern information, and more sophisticated structures tracking correlated branches and global history, to guess the outcome before it is known.

Based on that prediction, the processor begins fetching and executing instructions from the predicted path. This is speculative execution: running code on a path that may turn out to be the wrong one.

The prediction is a performance optimization. It is not a security decision. The processor has no model of whether predicting one direction or another is appropriate from a security perspective. It only considers what is likely to be correct.

Speculative Execution and What Happens When the Prediction Is Wrong

When the branch condition is finally resolved, two things can happen:

The prediction was correct. The work done speculatively becomes real. The pipeline continues without interruption.

The prediction was wrong. This is a misprediction. The processor needs to undo what it speculatively started.

For the architectural state, the registers and memory state visible to the program, this rollback is precise. The processor restores those values to what they were before the speculative path was taken. From the perspective of the instruction set architecture, execution continues as though the incorrect path was never entered. The program behaves correctly.

This is an important precision: when speculation is discarded, the architectural results are removed. The program's observable state is restored.

But the processor is a physical machine. While executing those speculative instructions, it performed physical operations: loading data into caches, updating internal prediction structures, moving data through execution units. These are microarchitectural effects. They are not part of the architecturally defined behavior of the instruction set. They are implementation details of how the hardware achieves that architectural behavior.

And they do not always get reversed when speculation is discarded.

Architectural State vs Microarchitectural State

This distinction is where Spectre becomes possible, and it is worth being precise.

Architectural state is what the CPU's instruction set architecture defines as part of the visible program state. Register values, the program counter, the defined contents of memory. This is what the program can read, what the compiler reasons about, what the operating system manages when switching between processes. When speculation is discarded, architectural state is restored.

Microarchitectural state is the internal implementation machinery that makes the CPU fast: the state of the caches, the branch predictor's history tables, the translation lookaside buffer, reorder buffer entries, and other structures that are not architecturally defined. These exist because of how the hardware is built, not because the instruction set says they must exist.

Software cannot directly query microarchitectural state. A program cannot ask "is this cache line currently in L1?" The ISA provides no instruction for that.

But software can sometimes infer microarchitectural state indirectly, by measuring timing.

The Cache as a Side Channel

CPU caches exist to bridge the speed gap between fast processors and slower memory. When data is accessed, a copy of it is placed in a cache. Subsequent accesses to the same data can be served from the cache rather than from memory.

The difference in access time between a cache hit and a cache miss is measurable:

Cache hit → fast
Cache miss → slower (data must be fetched from higher-level cache or memory)

A program can measure how long a memory access takes, even without direct hardware support for querying cache state. If accessing a particular address takes a short time, the data was in cache. If it takes longer, it was not.

This is a timing side channel. The program does not directly reveal information about cache state. But the timing of operations reveals that information indirectly.

Cache-based timing side channels have been studied for a long time. Spectre makes them security-critical by creating a path through which secret data can influence cache state during speculative execution, even when that speculative execution is later discarded at the architectural level.

How Spectre Works

The essential chain:

Attacker-influenced conditions
        ↓
Branch predictor trained to expect one outcome
        ↓
Speculative/transient execution follows predicted path
        ↓
Transient execution accesses secret-dependent data
        ↓
Cache state is modified based on that data
        ↓
Branch condition resolves (speculation was incorrect)
        ↓
Architectural results discarded
        ↓
Cache state persists
        ↓
Attacker measures access timing
        ↓
Information about secret is inferred

The secret does not get returned by the program. The program never architecturally completes a read of the secret. But during the transient speculative window, the processor loaded data from an address derived from or depending on the secret. That load affected cache state. That cache state change is observable through timing. The secret influenced a side effect that outlasted the speculation.

The key insight: the CPU becomes an unintended information channel. The same mechanism that makes the processor fast also creates a path for information to escape through microarchitectural state.

A Bounds Check That Doesn't Fully Protect

Consider a simplified pattern:

if (index < array_length) {
    value = array[index];
}

The architectural semantics are clear. The bounds check prevents access to array elements beyond the end of the array. If index is out of bounds, the condition is false, the body does not execute, and no out-of-bounds access occurs.

With speculative execution, the story is more complicated.

A branch predictor that has observed this check passing many times in succession may predict that it will pass again. Before the condition is fully resolved, the processor begins executing the body of the if statement speculatively, loading array[index] into the pipeline.

If index is actually out of bounds, the branch condition eventually resolves as false. The architectural result of the out-of-bounds array access is discarded. The program sees no out-of-bounds value.

But during that transient window, the processor may have loaded data from a location beyond the array boundary. If that load influences subsequent memory accesses during speculative execution, such as by using the loaded value as an index into another array, the cache state reflects which location was accessed. After the misprediction is resolved and the architectural work rolled back, that cache state persists.

An attacker who can then measure the timing of accesses to that second array can infer what value was loaded during the transient window, even though the architectural program state never reflected it.

This is a conceptual description of the bounds-check bypass class of Spectre vulnerability. The specific attack requires careful setup and measurement, the conditions must be crafted precisely for particular microarchitectures, and the signal may be noisy. But the conceptual chain is real.

Why This Is Not a Normal Memory Bug

Ordinary memory corruption involves a program reading or writing memory it should not, with the effects visible in the architectural program state. A buffer overflow writes past the end of a buffer and the extra bytes change memory the program later reads. A use-after-free accesses memory that has been freed, with results visible in the program's execution.

Spectre involves none of this in the traditional sense. The architecture correctly enforces the bounds check. The architectural state never reflects the out-of-bounds access. The program's defined behavior is correct.

The vulnerability exists in the interaction between the architectural programming model and the microarchitectural implementation underneath it. Correctly functioning hardware, performing a performance optimization that is architecturally invisible, creates an observable side effect that carries security-sensitive information.

This is what makes Spectre fundamentally different. The security boundary that software and OS developers reason about, the architectural state model, does not capture everything that is happening in the physical hardware.

Spectre Is a Class of Vulnerabilities

"Spectre" describes a family of vulnerabilities that share the core pattern of manipulating speculative execution to cause transient operations that leave microarchitectural side effects. The original disclosure described multiple variants.

Variant 1 (bounds-check bypass) involves the conditional branch prediction pattern described above. Variant 2 (branch target injection) involves manipulating the branch predictor's target prediction structures so that a victim process speculatively jumps to an attacker-chosen location.

Different variants exploit different prediction mechanisms, affect different attack scenarios, and require different mitigations. What unites them is the combination of speculative execution, microarchitectural side effects, and timing-based observation.

Spectre vs Meltdown

Both Meltdown and Spectre became public in January 2018 and both involve transient execution and side channels, but they describe different vulnerability classes.

Meltdown exploited a different aspect of transient execution involving delayed fault handling. On affected implementations, user-space code could transiently access privileged memory contents before a fault was raised and handled, with those contents leaving observable cache traces. The fix, kernel page-table isolation, removes privileged memory mappings from the page tables used in user-space context.

Spectre involves causing victim code, including code in the victim's own context, to perform unintended transient operations through branch prediction manipulation. The victim's own code becomes the vehicle for the information leak. This is conceptually harder to patch completely because it exploits fundamental aspects of how branch predictors and speculative execution work.

Meltdown primarily affected a specific implementation failure in the intersection of transient execution and privilege checking. Spectre identifies a deeper tension between performance-oriented speculation and the security model of isolation.

Why Permission Checks Are Not Sufficient

Software and hardware security are conventionally reasoned about at the architectural level.

If permission checks prevent a read, the read does not happen. If a bounds check fails, the body does not execute. This reasoning is correct at the architectural level.

Spectre demonstrates that it is not always sufficient.

The processor may transiently execute instructions past a permission or bounds check before that check is resolved. If the transient execution produces observable microarchitectural side effects, information can cross a security boundary without any architectural violation occurring.

The security boundary exists in the architecture. The information leaks through the microarchitecture underneath it. These are different layers, and they do not always align.

Mitigations

Spectre mitigations are complex because they need to address the underlying speculation mechanisms while preserving as much performance as possible.

Speculation barriers are instructions that prevent the processor from executing past a certain point until certain conditions are resolved. Inserting them after security-critical checks prevents transient execution from proceeding past those checks. This has a performance cost because it reduces the CPU's ability to speculate usefully.

Retpolines are a software technique for indirect calls that replace the vulnerable indirect branch instruction with a structure that causes the branch predictor to predict a benign target rather than an attacker-controlled one. This addresses certain branch-target-injection attacks.

Bounds-check hardening generates code that makes the data accessed in a transient window not carry information about out-of-bounds memory, even if transient execution occurs. The secret-dependent microarchitectural effect is neutralized.

Microcode updates can modify CPU behavior, including branch predictor behavior, to be less susceptible to training attacks. These are specific to CPU generations and variants.

Hardware-based mitigations in newer processors can isolate branch predictor state between security domains, reducing the ability to train a predictor in one context and exploit it in another.

No universal fix exists because Spectre is a class of vulnerabilities rooted in fundamental CPU design properties. Different variants require different mitigations, and the appropriate mitigation depends on the CPU architecture and the specific attack scenario.

What Spectre Changed

Before Spectre, the security model for software generally operated at the architectural level. Privilege separation, address space isolation, memory protection all work through architectural mechanisms. The architecture defines what a process can access, and enforcement happens through defined instruction semantics and hardware checks.

Spectre forced a realization: security also depends on what the microarchitectural implementation does underneath the architecture. A correct architectural security boundary can leak information through the hardware that implements it.

Software model
     ↓
Architecture
     ↓
Microarchitecture
     ↓
Physical hardware
     ↓
Side channels
     ↓
Observable information

The security boundary is not always where the programming model says it is. Information can escape through layers that software cannot directly observe or control.

This is a significant change in how CPU security has to be reasoned about. The CPU's performance optimizations are not neutral with respect to security. The same techniques that make modern processors fast, prediction, speculation, out-of-order execution, can create paths for information to move through microarchitectural state in ways that cross intended security boundaries.

Security is not only about what the system architecturally guarantees. It is also about what an attacker can infer from the behavior underneath those guarantees.