How Branch Prediction and Speculative Execution Work, and Why They Enable Spectre and Meltdown

The problem CPUs face

Every modern CPU is built around a simple tension: instructions execute much faster than they are issued. Your program is a long, mostly sequential stream of data reads, arithmetic, and control flow. A CPU pipeline can process dozens of instructions per clock cycle, but the front end delivers them one at a time. The gap between what the pipeline can do and what it receives is filled with a bet: the CPU guesses what the next instruction will be, fetches it early, and starts executing it before anyone has confirmed the guess is right. That bet is branch prediction, and it is the reason your laptop feels fast even though the instruction stream is full of ifs, loops, and function calls that no single cycle can resolve. A branch predictor that gets ninety-five percent of branches right keeps the pipeline nearly full. The cost is that the remaining five percent run on a wrong assumption, and the CPU must clean up when it discovers the mistake.

Speculative execution

Speculative execution extends that bet beyond the branch itself. Once the CPU has predicted the next path, it does not hold the pipeline idle while waiting for the actual branch target to resolve. It executes instructions down the predicted path, writes results into internal registers, and prefetches data for memory locations it expects to read. If the prediction is correct, the work has already been done and the pipeline never stalled. If the prediction is wrong, the CPU must detect the misprediction, flush the speculative results, and restart from the correct branch target. The penalty for a wrong guess is a pipeline drain of ten to twenty cycles, still far cheaper than an idle pipeline. The critical subtlety is that the speculative work is real: it touches cache lines, updates architectural state in internal copies, and can leave measurable side effects even after the CPU discards the results. That distinction, between architectural state and speculative state, is where the attacks live.

• Instruction fetch unit: preloads the next cache lines based on the predicted program counter
• Branch target buffer: maps recently taken branches to their predicted targets in a small table
• Return stack: tracks function call sites so returns resolve without a full branch lookup
• Load-store queue: speculatively executes memory operations before the branch resolves

How Spectre works

Spectre exploits the fact that speculative execution is not gated by permission checks. A normal CPU pipeline speculatively executes a branch target even when the branch depends on a data load that has not yet returned. The attacker arranges a sequence where the speculative path reads a secret through a pointer that passes a bounds check during speculation but would fail if executed architecturally. The secret value is then encoded into a cache line index. After the speculative work is flushed, that cache line stays warm. The attacker runs a probe loop over a large array and measures which cache line resolves fastest. The timing difference reveals the secret byte, and the entire attack completes in a few hundred cycles without any hardware modification. The attacker never needs to change a permission or violate a memory safety rule; they only need to arrange the instruction sequence so the speculative path crosses a security boundary during the window the operating system does not control.

How Meltdown works

Meltdown exploits a different aspect of speculative execution: the difference between architectural memory permissions and speculative memory access. On Intel, AMD, and ARM CPUs, the memory management unit enforces privilege-level restrictions on explicit loads and stores. During speculative execution, however, a load that would fault on an architectural execution does not fault during the speculative window. The attacker issues a speculative load of a kernel address using a user-space page table entry, reads the result into a register, and uses that value as an index into an attacker-controlled cache array. After the flush, the kernel's secret is now cached in the data cache. The attacker probes the cache from user space and recovers the secret byte by byte. Meltdown is particularly dangerous because it exposes all kernel memory to any unprivileged process, including memory that holds cryptographic keys, passwords, and network credentials. The fix requires switching to separate page tables for kernel and user space, which adds a page table walk on every privilege transition.

Why the fixes are expensive

The fixes for Spectre and Meltdown are expensive because the CPU's performance and its security are in direct tension. Spectre mitigation forces software to insert explicit serialization instructions after security checks, which drains the pipeline and defeats the speculation the pipeline exists to manage. Meltdown mitigation requires separate page tables, which means a page table walk every time the kernel switches to user space, adding dozens of cycles per system call. Combined, these mitigations cost roughly ten to thirty percent of single-threaded performance on affected workloads, and the overhead is worse for latency-sensitive applications like database engines, web servers, and hypervisors. The fundamental trade-off is the same one the CPU made decades ago: the pipeline's speed depends on speculation, and speculation is the channel the attack uses. Remove speculation and the pipeline stalls; keep it and you open a side channel. No patch closes the channel without giving the speed back.

• Spectre Variant 1, bounds check bypass: a bounds check passes during speculation and the load reads out of range
• Spectre Variant 2, branch target injection: an attacker poisons the branch target buffer to redirect speculation to arbitrary code
• Spectre Variant 4, speculative store bypass: a speculative store commits a value before the prior write is flushed
• Meltdown Variant 3, kernel data read: a speculative load crosses the user-kernel boundary without faulting

The state of hardware mitigation

As of 2026, most modern CPUs ship with hardware mitigation features that reduce the severity of both attack families. Intel microarchitectures include restricted speculation controls that can narrow the speculative window after a privilege transition. Apple's M-series chips combine page table isolation with hardware branch predictor invalidation on context switches. ARMv8.4 and later include a speculation barrier instruction that acts as a full pipeline drain. These hardware improvements reduce the attack surface, but they do not eliminate it entirely. Spectre attacks that exploit software-level speculation, such as branch target injection through a poisoned indirect branch, still require software-side mitigation. The performance cost of full mitigation remains significant on workloads that cross privilege boundaries frequently, particularly in virtualized environments where the hypervisor adds another layer of sensitive kernel memory.

Practical implications

For developers, the practical consequence is that memory safety is no longer just a correctness concern; it is a security property. A buffer over-read in C or C++, a use-after-free in a browser engine, or a type confusion in a JavaScript just-in-time compiler can all become a Spectre primitive that leaks sensitive memory. Memory-safe languages like Rust and Go reduce the attack surface but do not eliminate it: an attacker can still use a controlled value to index into a cache and exploit the timing side channel without violating any language safety rule. For system administrators, the performance cost of mitigation is a real deployment consideration, particularly on kernel-heavy workloads where every system call pays the page table overhead. For end users, the takeaway is that the operating system and hardware vendor have already applied the patches, but the underlying physical mechanism remains present in every CPU you own. The side channel is a property of the pipeline, not a bug in a specific chip.

What this means for you

Sources: Spectre: Speculative Execution Side-Channel Attacks (Isaac Levy, 2026); Intel/ARM Spectre & Meltdown Mitigations (ARM Community, 2026).

Corrections: Report an error at corrections@wireshaman.com.