“Meltdown” and “Spectre”: Every modern processor has unfixable security flaws

Windows, Linux, and macOS have all received security patches that significantly alter how the operating systems handle virtual memory in order to protect against a hitherto undisclosed flaw. This is more than a little notable; it has been clear that Microsoft and the Linux kernel developers have been informed of some non-public security issue and have been rushing to fix it. But nobody knew quite what the problem was, leading to lots of speculation and experimentation based on pre-releases of the patches.

Now we know what the flaw is. And it’s not great news, because there are in fact two related families of flaws with similar impact, and only one of them has any easy fix.

The flaws have been named Meltdown and Spectre. Meltdown was independently discovered by three groups—researchers from the Technical University of Graz in Austria, German security firm Cerberus Security, and Google’s Project Zero. Spectre was discovered independently by Project Zero and independent researcher Paul Kocher.

At their heart, both attacks take advantage of the fact that processors execute instructions speculatively. All modern processors perform speculative execution to a greater or lesser extent; they’ll assume that, for example, a given condition will be true and execute instructions accordingly. If it later turns out that the condition was false, the speculatively executed instructions are discarded as if they had no effect.

However, while the discarded effects of this speculative execution don’t alter the outcome of a program, they do make changes to the lowest level architectural features of the processors. For example, speculative execution can load data into cache even if it turns out that the data should never have been loaded in the first place. The presence of the data in the cache can then be detected, because accessing it will be a little bit quicker than if it weren’t cached. Other data structures in the processor, such as the branch predictor, can also be probed and have their performance measured, which can similarly be used to reveal sensitive information.

Meltdown

The first problem, Meltdown, is the one that stimulated the flurry of operating system patches. It uses speculative execution to leak kernel data to regular user programs.

Our original coverage gave a high-level summary of how operating systems virtualize system memory, the use of page tables to map from virtual memory addresses to physical addresses, how processors cache those mappings, and how the kernel’s page table mapping is shared between processes in order to maximize the value of this special cache.

While all modern processors, including those from Intel, AMD, and ARM, perform speculation around memory accesses, Intel’s processors do so in a particularly aggressive way. Operating system memory has associated metadata that determines whether it can be accessed from user programs or is restricted to access from the kernel (again: our original coverage has more detail about this point). Intel chips allow user programs to speculatively use kernel data, and the access check (to see if the kernel memory is accessible to a user program) happens some time after the instruction starts executing. The speculative execution is properly blocked, but the impact that speculation has on the processor’s cache can be measured. With careful timing, this can be used to infer the values stored in kernel memory.

The researchers say they haven’t been able to perform the same kind of kernel memory-based speculation on AMD or ARM processors, though they hold out some hope that some way of using this speculation offensively will be developed. While AMD has stated specifically that its chips don’t speculate around kernel addresses in this way, ARM has said that some of its designs may be vulnerable, and ARM employees have contributed patches to Linux to protect against Meltdown.

For systems with Intel chips, the impact is quite severe, as potentially any kernel memory can be read by user programs. It’s this attack that the operating system patches are designed to fix. It works by removing the shared kernel mapping, an operating system design that has been a mainstay since the early 1990s due to the efficiency it provides. Without that shared mapping, there’s no way for user programs to provoke the speculative reads of kernel memory, and hence no way to leak kernel information. But it comes at a cost: it makes every single call into the kernel a bit slower, because each switch to the kernel now requires the kernel page to be reloaded.

The impact of this change will vary wildly depending on workload. Applications that are heavily dependent on user programs and which don’t call into the kernel often will see very little impact; games, for example, should see very little change. But applications that call into the operating system extensively, typically to perform disk or network operations, can see a much more substantial impact. In synthetic benchmarks that do nothing but make kernel calls, the difference can be substantial, dropping from five million kernel calls per second to two-to-three million.

Spectre

Owners of AMD and ARM systems shouldn’t rest easy, though, and that’s thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.

Moreover, Spectre doesn’t offer any straightforward solution. Speculation is essential to high-performance processors, and while there may be limited ways to block certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren’t known.

Sensitive pieces of code could be amended to include “serializing instructions”—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.

In the immediate term, it looks like most systems will shortly have patches for Meltdown. At least for Linux and Windows, these patches allow end-users to opt out if they would prefer. The most vulnerable users are probably cloud service providers; Meltdown and Spectre can both in principle be used to further attacks against hypervisors, making it easier for malicious users to break out of their virtual machines.

For typical desktop users, the risk is arguably less significant. While both Meltdown and Spectre can have value in expanding the scope of an existing flaw, neither one is sufficient on its own to, for example, break out of a Web browser.

Longer term, we’d expect a future Intel architecture to offer some kind of a fix, either by avoiding speculation around this kind of problematic memory access or making the memory access permission checks faster so that this time interval between reading kernel memory, and checking that the process has permission to read kernel memory, is eliminated.

https://arstechnica.com/?p=1239407