Meltdown and Spectre showed processors leaking memory across bounds

What happened

On 3 January 2018, researchers publicly disclosed two related classes of hardware vulnerability, later named Meltdown and Spectre, affecting most modern processors. According to Google Project Zero's disclosure, the underlying issue is speculative execution: processors run instructions ahead of confirming they are permitted, and measurable timing differences in the processor cache during that speculation can reveal the contents of memory the running program should never see. Project Zero describes three variants, one that lets ordinary code read kernel memory, and two that manipulate branch prediction to read memory across process or privilege boundaries. The researchers reported the issues privately to Intel, AMD and ARM on 1 June 2017, months before public disclosure.

The researchers' joint disclosure site states that Meltdown breaks the most fundamental isolation between user applications and the operating system, while Spectre breaks the isolation between different applications. Intel's advisory confirmed its processors using speculative execution and indirect branch prediction could allow unauthorised disclosure of information and pointed customers to operating-system and firmware updates.

Confidence and limits

The mechanism is documented directly by the researchers who found it and confirmed independently by the affected chipmaker, a strong basis for the account above. What the sources do not settle is a single performance cost: Red Hat's own measurements of its mitigations found effects from under one percent to roughly twenty percent depending on workload, varying considerably by hardware and application. Any specific figure attached to how much the patches slowed computers down should be treated as workload-dependent rather than fixed.

Why it mattered

Meltdown and Spectre showed a flaw could live in processor design rather than in any single piece of software, meaning the fix could not simply be a vendor patch to one application. Operating-system vendors had to change how kernel and user memory were separated, and because that separation is exactly what speculative execution had been optimised to blur, the mitigation reintroduced some of the overhead the hardware had been designed to avoid. That is why the response is better described as a trade-off, accepting a measured performance cost to close an information-disclosure channel, rather than as a conventional patch removing a bug at no cost elsewhere.

Defensive takeaway

Confirm that operating-system and firmware mitigations for Meltdown and Spectre variants are applied on any system that still runs affected processors, and benchmark performance-sensitive workloads before and after applying microcode or kernel updates rather than assuming a vendor's general performance guidance applies to your specific workload.

• Do you know which of your systems still run processors that require ongoing microcode updates for speculative-execution vulnerabilities?
• Have you measured the actual performance impact of these mitigations on your own workloads, rather than relying on a vendor's general estimate?
• Does your patch management process cover firmware and microcode updates, not just operating-system and application patches?

Meltdown and Spectre remain a useful case for distinguishing a software bug from a hardware design trade-off, and for remembering that the researchers' own language, describing broken isolation rather than a single exploitable line of code, is a better guide to the scope of the response than any single performance percentage.