Spectre and Meltdown: When Speculation Crossed a Boundary
In 2018 a class of vulnerabilities showed that speculative execution — a two-decade-old performance technique — could be steered into performing accesses that architecturally never happened, while leaving microarchitectural traces that a timing side channel could read. The durable lesson is not the specific bug but its shape: a performance optimisation created a security boundary violation, and the mitigations cost real performance.
Software view, hardware view
The gap between what you wrote and what the machine does is where this whole domain lives.
The mechanism, in the abstract
Speculative execution exists because waiting for a branch to resolve wastes a deep pipeline (Speculative Execution: Doing Work Before You Know You Need It, Misprediction: What a Wrong Guess Costs). The CPU predicts, proceeds, and discards the work if it guessed wrong. The discard was understood to be complete because the *architectural* state — registers, memory, flags — is correctly rolled back, and the architectural state is what the ISA promises.
The insight behind this vulnerability class was that the rollback is not complete in a broader sense. Speculatively executed loads still allocate cache lines, still train predictors, still fill translation buffers. That state is not rolled back, because it is not part of the architectural contract and rolling it back would be expensive and was never thought necessary.
That yields the general shape: arrange for the CPU to speculatively perform an access it should not, then read the microarchitectural residue through a timing channel (Side Channels: When Performance Optimisations Leak). The two named families differed in how they got the speculation to happen — one abused the boundary between privilege levels, the other trained predictors to steer a victim's own code — but shared this structure. Numerous related variants followed, which is itself the point: it was a class, not an incident.
Why the mitigations were expensive
The fixes fell into recognisable families, and each attacked the mechanism at a different point. Isolating address spaces more strictly removed the ability to speculate into kernel mappings, at the cost of more work on every privilege transition — which made system calls measurably more expensive on affected hardware (Why a System Call Costs More Than a Function Call). Restricting or flushing predictor state across boundaries removed the ability to train a victim's predictors, at the cost of losing prediction accuracy after every transition. Adding speculation barriers at sensitive points stopped the CPU proceeding past a check, at the cost of a pipeline stall exactly where the pipeline used to be kept full.
The pattern is consistent and worth internalising: each mitigation removes some of the speculation or sharing that the performance was built on. There was no free fix, because the vulnerability was not a defect to be corrected — it was the intended behaviour being observed through an unintended channel. Reported slowdowns varied enormously by workload; system-call-heavy and I/O-heavy workloads were affected far more than compute-bound ones, which is exactly what the mechanism predicts.
Later CPU generations addressed parts of this in hardware, which is why mitigation cost is strongly generation-dependent and why blanket performance claims about it are unreliable. Some mitigations are also configurable, meaning the effective security posture of a machine depends on firmware, kernel and hypervisor settings rather than on the CPU alone.
| Approach | What it prevents | Performance cost | Falls on |
|---|---|---|---|
| Stronger address-space separation | Speculating into privileged mappings | Extra work at every privilege transition | System-call- and interrupt-heavy workloads |
| Predictor flushing or partitioning | Training a victim's predictors across a boundary | Cold predictors after every transition | Workloads with frequent context switches |
| Speculation barriers at checks | Proceeding past a security-relevant check | A stall precisely where the pipeline was full | Hot paths containing such checks |
| Disabling SMT | Sibling-thread observation of shared structures | Loss of the throughput SMT provided | Workloads that benefited from SMT |
| Hardware redesign in later parts | The channel itself, at the source | Little or none once shipped | Nobody — but it requires new hardware |
The durable lessons
Microarchitectural state is security-relevant. Before this, the security model reasoned about architectural state and treated everything beneath it as an implementation detail. That is no longer defensible, and hardware security analysis now routinely considers what optimisations leave behind.
Performance and isolation genuinely trade against each other. They are not always aligned goals with a clever solution that satisfies both. Sharing a resource to keep it busy is exactly what makes it a channel, and the cost of the mitigations was the accumulated benefit of the sharing being handed back.
Correct-by-the-contract is not the same as safe. Every layer behaved as specified: the CPU implemented its ISA faithfully, the OS enforced its boundaries, the caches cached. The vulnerability lived in the space between the specifications — which is a general lesson about layered systems, not a hardware-specific one.
For a working engineer the practical residue is modest but real: keep firmware and kernels current, understand that co-tenancy has a security cost (What a vCPU Actually Is), know that mitigation settings affect both security posture and benchmark results, and be suspicious of performance comparisons that do not state the mitigation state of the machines involved.
- Microarchitectural state counts — what an optimisation remembers is part of the security surface.
- No free mitigation — every fix returns some of the performance that the shared or speculative behaviour was buying.
- Cost is workload-shaped — system-call-heavy code paid far more than compute-bound code.
- Generation-dependent — later hardware fixed parts of it, so blanket "N percent slower" claims are unreliable.
- Benchmarks must state mitigation state — otherwise the comparison is not reproducible.
Key points
- Speculative execution correctly rolls back architectural state but leaves microarchitectural traces, which were never part of the contract.
- The attack shape is: induce speculation past a boundary check, then read the residue through a timing side channel.
- It was a vulnerability class rather than a single bug, with many variants sharing the same structure.
- Every mitigation family removes some speculation or sharing, so the cost is the performance that behaviour was providing.
- Mitigation cost is strongly workload- and generation-dependent, which makes unqualified slowdown figures unreliable.
Follow the mechanism
The path through the machine, hop by hop — and the conclusions it invites that are wrong.
- 1Boundary check → speculation: the CPU predicts the check will pass and proceeds before it resolves (Branch Prediction: Guessing Well Enough to Matter).
- 2Speculation → access: an access the architecture would forbid is performed transiently by the execution units.
- 3Access → cache fill: the load allocates a cache line, and that allocation is not part of the state that gets rolled back.
- 4Check resolves → rollback: architectural results are correctly discarded, so the program never observes the value directly.
- 5Residue → timing probe: an observer times its own accesses and infers which line was filled, recovering the value indirectly (Side Channels: When Performance Optimisations Leak).
- • "This was a bug in a specific CPU" — it was a design-level consequence of speculation affecting many vendors and generations.
- • "The mitigations cost N percent" — the figure varies enormously by workload and hardware generation; unqualified numbers are not meaningful.
- • "Speculation was a mistake" — it is responsible for a large fraction of single-thread performance; removing it is not on the table.
- • "It is fixed now, so it does not matter" — later hardware addressed parts of it, but the structural lesson about microarchitectural state persists.
Consequences, controls and cost
- • Kernel and hypervisor boundaries required software mitigation on affected hardware, making privilege transitions more expensive.
- • System-call-heavy and virtualised workloads saw meaningfully larger regressions than compute-bound ones.
- • Disabling SMT became a recognised hardening option with a real throughput cost.
- • Performance comparisons across machines became unreliable unless mitigation state is stated, since it can dominate the difference.
- • Keep firmware, microcode, kernel and hypervisor current — most mitigations arrive through those channels rather than the application.
- • Treat co-tenancy with untrusted workloads as a threat-model decision, and use dedicated capacity where it matters.
- • Record mitigation settings alongside benchmark results so comparisons remain reproducible and honest.
- • For most application code, rely on platform mitigations rather than attempting anything at application level.
- • Where secrets are handled directly, follow constant-time discipline, which reduces exposure to this and related channels.
- • Check the reported mitigation status of the machine before drawing any performance conclusion from it.
- • Benchmark system-call-heavy paths specifically, since those absorbed the largest share of the cost.
- • Compare the same workload with mitigations configured differently to size the effect for your own code rather than trusting published figures.
- • Track firmware and kernel versions as part of performance records, because they change the baseline.
- • Mitigations return performance that speculation and sharing were providing, and the loss is permanent on affected hardware.
- • Disabling SMT halves logical CPU count for workloads that were benefiting from it.
- • Dedicated hardware avoids co-tenancy exposure at substantially higher cost.
- • Keeping firmware current introduces its own operational risk and requires reboot windows.
Scope
§224 — what these claims are specific to.
- MICROARCH-SPECIFICWhich variants apply, and how expensive their mitigations are, depend on the specific CPU generation and vendor; later designs addressed some channels in hardware and pay little or nothing for them.
- PLATFORM-SPECIFICEffective mitigation depends on the combination of microcode, firmware, kernel and hypervisor, and several mitigations are configurable — so two machines with the same CPU can have different exposure and different performance.
- SIMPLIFIEDThis is a conceptual account of the vulnerability class for engineers. It deliberately omits the specific conditions and sequences that distinguish individual variants.