Meltdown (security vulnerability)

The logo of the vulnerability

Meltdown is a hardware vulnerability affecting Intel x86 microprocessors and some ARM-based microprocessors. It effectively allows a rogue process to read any physical, kernel or other process's mapped memory, regardless of whether or not it should be able to do so.

Meltdown affects a wide range of systems. At the time of disclosure, this included all iPhones and Mac devices, in addition to machines with affected hardware running any version of Microsoft Windows, or any but very recent versions of Linux. Accordingly, many servers and Cloud services were impacted, as well as a potential majority of smart devices and embedded devices using ARM based processors (mobile devices, smart TVs and others), including a wide range of networking equipment. A purely software workaround to Meltdown has been assessed as slowing computers between five and 30 percent in certain workloads. Companies responsible for software correction of the exploit are reporting minimal impact from benchmark testing.

Meltdown was issued a Common Vulnerabilities and Exposures ID of CVE-2017-5754, also known as Rogue Data Cache Load, in January 2018. It was disclosed in conjunction with another exploit, Spectre, with which it shares some but not all characteristics.

Overview

Meltdown exploits a race condition inherent in the design of many modern CPUs between memory access and privilege checking during instruction processing, combined with a CPU cache side channel attack, to allow a process to bypass the usual privilege checks that isolate the exploit process from accessing data belonging to the operating system and other running processes. It allows an unauthorized process to read data from any address that is mapped to the current process' memory space, because instruction pipelining in the affected processors means that the data from the unauthorized address will almost always be temporarily loaded into the CPU's cache during speculative execution, from which it can be recovered using other techniques, even if the original read instruction eventually fails due to privilege checking and never produces a readable result.

Since many operating systems map physical memory, kernel processes, and other running user space processes into the address space of every process and rely on privilege checking to prevent unauthorized access, Meltdown effectively allows a rogue process to read any physical, kernel or other process' mapped memory, regardless of whether or not it should be able to do so. Defenses against Meltdown would require avoiding the use of memory mapping in a manner vulnerable to such exploits (a software based solution) or avoidance of the underlying race condition (a modification to the CPU's microcode and/or execution path).

The exploit is viable on any operating system in which privileged data is mapped into virtual memory of unprivileged processes, which includes most major operating systems for the affected CPU architectures. As such Meltdown may potentially impact a wider range of devices than presently identified, as a small number of processor families are used extremely widely.

History

In 2014, the Linux kernel adopted kernel address space layout randomization (KASLR) to mitigate address leaks.

In June 2017, KASLR was found to have a large class of new vulnerabilities. Research at Graz University showed how to solve these vulnerabilities by preventing all access to unauthorized pages. This work led to [Kernel page-table isolation] in 2017, which was confirmed to eliminate a large class of security bugs, including the not-yet-discovered Meltdown -- a fact confirmed by the Meltdown authors.

Meltdown was discovered independently by Jann Horn from Google's Project Zero, Werner Haas and Thomas Prescher from Cyberus Technology, and Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz from Graz University of Technology. The same research teams that discovered Meltdown also discovered a related CPU security vulnerability now called Spectre. The two vulnerabilities were made public jointly, on January 3, 2018, several days ahead of the coordinated release date of January 9, 2018 as news sites started reporting about commits to the Linux kernel and mails to its mailing list. As a result, patches were not available for some platforms, such as Ubuntu, when the vulnerabilities were disclosed.

Affected hardware

The Meltdown vulnerability primarily affects Intel microprocessors. It is thought not to affect AMD microprocessors. Intel has countered that the flaws affect all processors. AMD has denied this, and claims that there is near zero chance for their processors to be affected. Researchers have indicated that the Meltdown vulnerability is exclusive to Intel processors, while the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors. Specifically, processors with speculative execution are affected with these vulnerabilities. Intel and ARM processors are affected the most, while AMD processors are minimally affected. Google has reported that every Intel processor since 1995 with out-of-order execution is potentially vulnerable to the Meltdown vulnerability. Intel introduced speculative execution to their processors with Intel's P6 family microarchitecture with the Pentium Pro IA-32 microprocessor in 1995.

ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. However the ARM Cortex A75 core is affected directly by the Meltdown vulnerability, and cores Cortex-A15, Cortex-A57, and Cortex-A72 are affected by variations of the Meltdown vulnerability This contradicts some early statements made about the Meltdown vulnerability as being Intel only.

A large portion of the current mid-range Android handsets use the Cortex-A53 or Cortex-A55 in an octa-core arrangement and are not affected by either the Meltdown or Specter vulnerability as they don't do out-of-order execution. This includes devices with the Qualcomm Snapdragon 630, Snapdragon 626, Snapdragon 625, and all Snapdragon 4xx processors based on A53 or A55 cores.

Mechanism

Meltdown relies on a CPU race condition that can arise between instruction execution and privilege checking, to read unauthorized memory mapped data in a detectable manner before the privilege check can occur to prevent the data being read. The following provides an overview of the exploit, and the memory mapping which is its target. The attack is described in terms of an Intel processor running Microsoft Windows or Linux, the main test targets used in the original paper, but it also affects other processors and operating systems.

Background - modern CPU design

Modern computer processors use a variety of techniques to gain high levels of efficiency. Four widely-used features are particularly relevant to Meltdown:

• Virtual (paged) memory, also known as memory mapping - used to make memory access more efficient and to control which processes can access which areas of memory.
  A modern computer usually runs many processes in parallel. In an operating system such as Windows or Linux, each process is given the impression that it alone has complete use of the computer's physical memory, and may do with it as it likes. In reality it will be allocated memory to use from the physical memory, which acts as a "pool" of available memory, when it first tries to use any given memory address (by trying to read or write to it). This allows multiple processes, including the kernel or operating system itself, to co-habit on the same system, but retain their individual activity and integrity without being affected by other running processes, and without being vulnerable to interference or unauthorized data leaks caused by a rogue process.

• Privilege levels, or protection domains - provide a means by which the operating system can control which processes are authorized to read which areas of virtual memory.
  As virtual memory permits a computer to refer to vastly more memory than it will ever physically contain, the system can be greatly speeded up by "mapping" every process and their in-use memory - in effect all memory of all active processes - into every process' virtual memory. In some systems all physical memory is mapped as well, for further speed and efficiency. This is usually considered safe, because the operating system can rely on privilege controls built into the processor itself, to limit which areas of memory any given process is permitted to access. An attempt to access authorized memory will immediately succeed, and an attempt to access unauthorized memory will cause an exception and void the read instruction, which will fail. Either the calling process or the operating system directs what will happen if an attempt is made to read from unauthorized memory - typically it causes an error condition and the process that attempted to execute the read will be terminated. As unauthorized reads are usually not part of normal program execution, it is much faster to use this approach than to pause the process every time it executes some function that requires privileged memory to be accessed, to allow that memory to be mapped into a readable address space.

• Instruction pipelining and speculative execution - used to allow instructions to execute in the most efficient manner possible - if necessary allowing them to run out of order or in parallel across various processing units within the CPU - so long as the final outcome is correct.
  Modern processors commonly contain numerous separate execution units, and a scheduler that decodes instructions and decides, at the time they are executed, the most efficient way to execute them. This might involve the decision that two instructions can execute at the same time, or even out of order, on different execution units (known as "instruction pipelining"). So long as the correct outcome is still achieved, this maximizes efficiency by keeping all of the processor's execution units in use as much as possible. When an instruction might lead to two different outcomes (for example "do this if the result is zero, otherwise do that"), rather than wait for succeed or fail, the CPU will often take steps to execute both of these options (known as "speculative execution") and then never save or output the results from the unused option, because this is much faster than making everything wait until the correct branch is known. (see also: branch predictor)

• CPU cache - a modest amount of memory within the CPU used to ensure it can work at high speed, to speed up memory access, and to facilitate "intelligent" execution of instructions in an efficient manner.
  From the perspective of a CPU, the computer's physical memory is slow to access. Also the instructions a CPU runs are very often repetitive, or access the same or similar memory numerous times. To maximize efficient use of the CPUs resources, modern CPUs often have a modest amount of very fast on-board memory, known as "CPU cache". When data is accessed or an instruction is read from physical memory, a copy of that information is routinely saved in the CPU cache at the same time. If the CPU later needs the same instruction or memory contents again, it can obtain it with minimal delay from its own cache rather than waiting for a request related to physical memory to take place.

The Meltdown exploit

Ordinarily, the mechanisms described above are considered secure. They provide the basis for most modern operating systems and processors. Meltdown exploits the way these features interact, to bypass the CPU's fundamental privilege controls and access privileged and sensitive data from the operating system and other processes. To understand Meltdown, we consider the data which is mapped in virtual memory (much of which the process is not supposed to be able to access), and look at how the CPU responds when a process attempts to access unauthorized memory. The process is running on a vulnerable version of Windows or Linux, on a 64 bit processor of a vulnerable type. (This is a very common combination across almost all desktop computers, notebooks, laptops, servers and mobile devices.)

1. Like every other process and the operating system itself, the rogue process has access to a virtual address space (virtual memory) of billions of gigabytes. Ignoring privilege controls, this space will be used in a way that maximizes efficiency. Most is unallocated - it doesn't have any data whatsoever. Some areas are designated to the rogue process for its own instructions and data. For efficiency, and ignoring privilege controls, this space also contains all the other data being used in all the other processes that are running, including the operating system, and possibly even memory that was used but has not been emptied or addresses that always map directly to the entirety of physical memory. However the fact that all of this data is mapped into each process' memory is ordinarily considered completely safe, because the CPU's privilege controls will prevent its abuse. Any attempt by the rogue process to access any of this other data - and indeed anything except its own authorized memory - will result in an exception (error condition). The request will fail and no data will be provided to the rogue process, preserving security.
2. If a process were to try reading from unauthorized memory, the read instruction will at first be scheduled and pipelined by the CPU, as with all instructions. As usual, an execution unit will be selected and a memory controller unit will be told to read the contents of memory from the address in the instruction, so that it is ready and quickly available within the CPU, when it's time to execute the rest of the instruction. At some point before the instruction is allowed to produce any output, the privilege check will complete elsewhere. In the case of an unauthorized read, the execution unit will be told that the instruction failed the privilege check. It will discard all data from the instruction, never pass anything to the process, and it will instead abandon that instruction and move to the next one.
3. In theory, provided the execution unit, memory controller, scheduler and privilege check are fault-free, this is a completely secure approach. Even though the privileged memory was read by the execution unit and memory controller unit initially, the instruction execution was then abandoned midway and the unauthorized part-processed workings were discarded - the outcome was correct. However, as Meltdown shows, it is not as secure as has been believed.
4. In the early stages of the instruction execution, the CPU's scheduler scheduled two events - a privilege check, and the first steps of executing the instruction. As part of that, while it was waiting for the privilege check to complete, the execution unit started by fetching the data. In the case of the rogue process, the data was from an unauthorized address, but it was still fetched by the memory controller during the initial stage of instruction execution, even if it was then discarded and abandoned when the privilege check completed and failed.

5. Ordinarily this has no effect and security is enforced, because the read data is never made available in any way, until the privilege check has completed. However even when the instruction fails, the data has already been requested by the execution unit and fetched by the memory controller, in order to be ready to process it, and although the execution unit discards the data upon privilege check failure, the CPU cache was in fact updated as an automatic part of fetching the data from memory, in case the same data might be needed shortly a second time.

   At this point, Meltdown intervenes:

6. The CPU cache is not readable by an unauthorized process, because it is internal to the CPU. But by using a cache timing attack (a form of side channel attack), it is possible for a rogue process to determine whether data from a specific address is held within the CPU cache, even if it cannot itself read the actual data from that address. If data from some address has been cached by the CPU then a second instruction to read that address will use the CPU cache for the purpose (fast), if not then the CPU would have to request the data to be read from memory (slower). The rogue process can use this difference in timing to detect which of these took place, and whether the address was already in the CPU cache or not. Usually this wouldn't be an insurmountable vulnerability on its own, but Meltdown can use it combined with other features of the CPU instruction set to gain full access to all mapped memory...
7. When an instruction asks for memory to be read, it can specify the address to read from, in many different ways. These include indirect addressing modes - instructions which tell the CPU to read from memory X, use the value stored at X to calculate a second address Y, and the "answer" (or returned value) is the value stored in address Y. Meltdown uses this as part of the basis of a side-channel attack to determine the content of the memory at any given address. Suppose the address at 2000 is not directly readable by the process, but could have any value from 1 to 5, and suppose we ignore privilege checking. One could execute an instruction "Read the value of memory at an address given by (5000 plus the value of memory at address 2000)". If address 2000 contains 1, then the CPU will try to return the value of memory at address 5001; if address 2000 contains 2 it will try to return the value of memory at address 5002, and so on. If we then execute a timing attack, and it shows that the CPU was slower to read from addresses 5001, 5002, 5003 and 5005, but faster for address 5004, then we can conclude that the reason is that it has cached data from address 5004, and that this is because it has recently accessed that address. So we can deduce that address 2000 contained the value "4".
8. If 2000 is an unauthorized address, then this attempt should fail and the process should learn nothing from it, because of the privilege check.
9. But the problem - as shown by Meltdown - is that, in order to be efficient, the CPU has already started to prepare itself by accessing the memory locations that may be needed, in parallel with the privilege check. That means, when the privilege check fails and the execution unit (correctly) discards the data and abandons the read instruction, address 2000 has already been read and its contents already used to read address 5004, even if the read was abandoned and the in-progress data was discarded by the CPU's execution unit. Moreover when the memory controller was told by the execution unit to access address 5004 in preparation for the instruction, it automatically put a copy of that data into the CPU cache as usual, in case of a future request for the same data, and that copy is still present in the CPU cache. (It isn't expected to be detectable without authorization, and will often be needed again quite soon when it's been needed a first time.) So even though the instruction itself failed, and even though the process cannot directly read the contents of address 2000 or the cached content of any of addresses 5001 to 5005, the rogue process can still use its side-channel attack to identify that address 5004 is in the cache and the other addresses between 5001 and 5005 are not, so it can still determine that the address that the instruction would have tried to read is 5004, and therefore that the content of unauthorized address 2000 is "4".

Meltdown uses this technique in sequence to read every address of interest at high speed, and depending on other running processes, the result may contain passwords, encryption data, and any other sensitive information, from any address of any process that exists in its memory map. In practice because cache side-channel attacks are slow, it's faster to extract data one bit at a time (only 2 × 8 = 16 cache attacks needed to read a byte, rather than 2 × 256 = 512 steps if it tried to read all 8 bits at once).

Impact

The impact of Meltdown depends on the design of the CPU, the design of the operating system (specifically how it uses memory paging), and the ability of a malicious party to get any code run on that system, as well as the value of any data it could read if able to execute.

• CPU - Many of the most widely used modern CPUs from the late 1990s until early 2018 have the required exploitable design. However, it is possible to mitigate it within CPU design. A CPU that could detect and avoid memory access for unprivileged instructions, or was not susceptible to cache timing attacks or similar probes, or removed cache entries upon non-privilege detection (and did not allow other processes to access them until authorized) as part of abandoning the instruction, would not be able to be exploited in this manner. Some observers consider that all software solutions will be "workarounds" and the only true solution is to update affected CPU designs and remove the underlying weakness.

• Operating system - Most of the widely used and general-purpose operating systems use privilege levels and virtual memory mapping as part of their design. Meltdown can only access pages that are memory mapped, so the impact will be greatest if all active memory and processes are memory mapped in every process, and least impactful if the operating system is designed so that almost nothing can be reached in this manner. An operating system might also be able to mitigate in software to an extent, by ensuring that probe attempts of this kind will not reveal anything useful. Modern operating systems use memory mapping to increase speed though, so this could lead to performance loss.

• Access to execute - Among the vulnerable chips are those made by ARM and Intel designed for standalone and embedded devices, such as mobile phones, smart TVs, networking equipment, vehicles, hard drives, industrial control, and the like. As with all vulnerabilities, if a third party cannot run code on the device, its internal vulnerabilities remain unexploited. For example, an ARM processor in a cellphone or Internet of Things "smart" device may be vulnerable, but the same processor in a kitchen appliance or hard drive control circuitry may be extremely unlikely to be exploited.

Impact itself depends on the implementation of the address translation mechanism in the OS and the underlying hardware architecture. The attack can reveal the content of any memory which is mapped into a user address space, even if otherwise protected. For example, before kernel page-table isolation is introduced, most versions of Linux maps all physical memory into the address space of every user-space process; the mapped addresses are (mostly) protected, making them unreadable from user-space and accessible only when transitioned into the kernel. The existence of these mappings makes transitioning to/from the kernel faster, but is unsafe in the presence of this Meltdown vulnerability, as the contents of all physical memory (which may contain sensitive information such as passwords belonging to other processes or the kernel) can then be obtained via the above method by any unprivileged process from user-space.

According to researchers, "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)." Intel responded to the reported security vulnerabilities with an official statement.

The vulnerability is expected to impact major cloud providers, such as Amazon Web Services (AWS) 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 exploit circumvents.

One of the paper's authors reports that paravirtualization (Xen) and containers such as Docker, LXC, and OpenVZ, are affected. They report that the attack on a fully virtualized machine allows the guest user space to read from the guest kernel memory, but not read from the host kernel space.

Mitigation

Further information: Kernel page-table isolation

Mitigation of this vulnerability requires changes to operating system kernel code, including increased isolation of kernel memory from user-mode processes. Linux kernel developers have referred to this measure as kernel page-table isolation (KPTI). KPTI patches have been developed for Linux kernel 4.15, and have been released as a backport in kernel 4.14.11. macOS has been patched since 10.13.2 High Sierra. Microsoft released an emergency update to Windows 10, 8.1, and 7 SP1 to address the vulnerability on January 3, 2018, as well as Windows Server. These patches are known to cause conflicts with specific third-party antivirus software that use unsupported kernel calls; systems running these programs will not receive the update until the antivirus is patched. Red Hat released kernel updates to their Red Hat Enterprise Linux distributions version 6 and version 7. CentOS also already released their kernel updates to CentOS-6 and CentOS-7.

It was reported that implementation of KPTI may lead to a reduction in CPU performance, with some researchers claiming up to 30% loss in performance depending on usage, though Intel considered this to be an exaggeration. It was reported that Intel processor generations that support process context identifiers (PCID), a feature introduced with Westmere and available on all chips from the Haswell architecture onward, were not as susceptible to performance losses under KPTI as older generations that lack it.

A statement by Intel said that "any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time." Phoronix benchmarked several popular PC games on a Linux system with Intel's Coffee Lake Core i7-8700K CPU and KPTI patches installed, and found that any performance impact was little to non-existent. In other tests, including synthetic I/O benchmarks, and databases such as PostgreSQL and Redis, a measurable impact in performance was found.

On January 4, 2018, Google's security blog provided additional details how the variant speculative execution vulnerability (Spectre) might be mitigated using an x86 instruction set with a negligible amount of processor overhead in contrast to what earlier accounts have feared.

Several procedures to help protect home computers and related devices from the "Meltdown" and "Spectre" security vulnerabilities have been reported.

See also

• Intel Management Engine
• Kaiser (disambiguation)#Computer security method (Kernel Address Isolation to have Side-channels Efficiently Removed)
• Row hammer – an unintended side effect in dynamic random-access memory causing memory cells to interact electrically

External links

• Official website of the Meltdown and Spectre vulnerabilities
• Meltdown paper
• Google Project Zero write-up
• CVE-2017-5754 at Mitre Corporation
• CVE-2017-5754 at National Vulnerability Database
• KAISER - Kernel Address Isolation to have Side-channels Efficiently Removed