What we know about Meltdown (Intel) and Spectre (any CPU) processor bugs

Because there is some information noise about the two bugs and their impact, I’ve tried to make an “executive summary” about the bug itself and the potential impact of it and the workarounds which will be rolled out for Windows and Linux kernels.

Sources are mentioned after quotations.



  • Information disclosure vulnerability
  • Allows access to kernel space from unprivileged userland
  • Affects every Intel CPU since 1995 except Itanium and Atom until 2013
  • Affects paravirtualization and containers
  • Does not affect hypervisors (i.e. guests can’t use this to escape to host address space)
  • Planned patches for Windows and Linux kernels will separate kernel address space from userland process address space
  • This will cause frequent CPU cache flushes, which will cause a performance drop of 7 up to 23 percent.

“Every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).”[6]

The vulnerability is expected to impact major cloud providers such as Amazon Web Services (AWS)[7] and Google Cloud Platform. Cloud providers allow users to execute programs on the same physical servers where sensitive data might be stored, and rely on safeguards provided by the CPU to prevent unauthorized access to the privileged memory locations where that data is stored, a feature that the Meltdown vulnerability seems to be able to circumvent.

One of the paper’s authors reports that Paravirtualization (Xen) and containers like Docker, LXC and OpenVZ, are affected[8]. They report that the attack on a fully virtualized machine allows the guest user space to read from the guest kernel memory, but not the host kernel space.”


“Programmers are scrambling to overhaul the open-source Linux kernel’s virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we’re looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit.”


“PTI is the workaroud, page table isolation, which can be enabled/disabled via boot parameters. nopcid disables the use of the hardware feature that reduces the impact of workaround. PCID support

readonly pgbench (tpch-like), 16 clients, i7-6820HQ CPU (skylake):


tps = 236629.778328


tps = 220791.228297 (~0.93x)

pti=on, nopcid:

tps = 198959.801459 (~0.84x)

To get closer to the worst case, I’ve also measured:

pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):


tps = 420490.162391


tps = 350746.065039 (~0.83x)

pti=on, nopcid:

tps = 324269.903152 (~0.77x)”


“Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.”


Windows 10 Benchmarks by computerbase.de

Meltdown PoC


CVE-2017-5753 and CVE-2017-5715

  • Information disclosure vulnerability
  • uses side-channel timing attack on CPU cache
  • all CPUs are affected: includes Intel, AMD and ARM
  • based on speculative exeuction feature

Instead of a single, easy to fix vulnerability, the Spectre paper describes a whole class of potential vulnerabilities. They are all based on exploiting side effects of speculative execution, a common means of hiding memory latency and so speeding up execution in modern microprocessors. Unlike the related Meltdown vulnerability disclosed at the same time, Spectre does not rely on a specific feature of a single processor’s memory management and protection system, but is a more generalized idea, of which the Meltdown vulnerability can be thought of as a particularly easy and efficient-to-implement special case.

The starting point of the white paper is that of a side-channel timing attack, applied to the branch prediction machinery of modern out-of-order-executing microprocessors. While at the architectural level documented in processor data books, any results of misprediction are specified to be annulled after the fact, the resulting speculative execution may still leave around side effects, like loaded cache lines, which affect the so-called non-functional aspects of the computing environment later on. If such side effects visible to a malicious program, including but not being limited to timing of memory references, can be engineered to depend on sensitive data held by the victim process, they can result in the sensitive data becoming discernible. This can happen despite the formal architecture-level security arrangements working as designed; because the lower, microarchitecture-level optimizations to code execution leak information not essential to the correctness of normal program execution.

The Spectre paper displays the attack in four essential steps:

  1. First, it shows, that branch prediction logic in modern processors can be trained to reliably hit or miss based on the internal workings of a malicious program.
  2. Then it goes on to show, that the following difference between cache hits and misses can be reliably timed so, that what should have been a simple non-functional difference, can in fact be translated into a covert channel, which extracts information from an unrelated process’s inner workings.
  3. Thirdly, the paper synthesizes the results with return-oriented programming exploits and other principles with a simple example program and also a JavaScript snippet run under a sandboxing browser; in both cases, the entire address space of the victim process is shown to be readable by simply exploiting speculative execution of conditional branches in code generated by a stock compiler or the JavaScript machinery present in an extant browser. The basic idea is to search existing code for places where speculation touches upon otherwise inaccessible data, manipulate the processor into a state where speculative execution has to touch that data, and then to time the side effect of the processor being faster if its by-now-prepared prefetch machinery indeed did load a cache line.
  4. Finally, the paper concludes by generalizing the attack to any non-functional state visible to a malicious process, whose content is somehow manipulable based on speculative execution.

The basic difference between Spectre and the related Meltdown vulnerability is, that the latter relies on specific features of modern Intel processors: the CPUs can be tricked into speculating into protected system data and to be forced into guaranteed handling of a related security exception. The setup in Spectre has more of a statistical flavor: it does its best to prepare the branch prediction machinery in a certain way, and uses code maybe (or not) found in existing libraries to do essentially the same thing, if at this point only between user programs. This makes Spectre much more involved to utilize, but at the same time also far more general and difficult to defend against. In particular, and unlike Meltdown, Spectre does affect most current AMD and ARM processors.


Spectre is a vulnerability that forces other programs on a user’s operating system to access an arbitrary location in the computer’s memory. Almost every system is affected by Spectre, including desktops, laptops, and mobile devices. Specifically, Spectre has been shown to work on Intel, AMD, and ARM processors.[5][6]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.