Meltdown: Reading Kernel Memory from User Space
, , and , Graz University of Technology; and , Cyberus Technology; , G DATA Advanced Analytics; , Google Project Zero; , Graz University of Technology; , Independent; , University of Michigan; , University of Adelaide and Data61; , Rambus, Cryptography Research Division
https://www.usenix.org/conference/usenixsecurity18/presentation/lipp
This paper is included in the Proceedings of the 27th USENIX Security Symposium.
Copyright By PowCoder代写 加微信 powcoder
August 15–17, 2018 • Baltimore, MD, USA
ISBN 978-1-939133-04-5
Open access to the Proceedings of the 27th USENIX Security Symposium
is sponsored by USENIX.
Meltdown: Reading Kernel Memory from User Space
1, 1, 1, 2, 2, 3, 4, 1,
5, 6,9, 7, 8
1Graz University of Technology, 2Cyberus Technology GmbH, 3G-Data Advanced Analytics, 4Google Project Zero, 5Independent (www.paulkocher.com), 6University of Michigan, 7University of Adelaide & Data61, 8Rambus, Cryptography Research Division
The security of computer systems fundamentally relies on memory isolation, e.g., kernel address ranges are marked as non-accessible and are protected from user access. In this paper, we present Meltdown. Meltdown exploits side effects of out-of-order execution on mod- ern processors to read arbitrary kernel-memory locations including personal data and passwords. Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors. The attack is independent of the operating system, and it does not rely on any software vulnerabilities. Meltdown breaks all security guarantees provided by address space isola- tion as well as paravirtualized environments and, thus, every security mechanism building upon this foundation. On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affect- ing millions of customers and virtually every user of a personal computer. We show that the KAISER defense mechanism for KASLR has the important (but inadver- tent) side effect of impeding Meltdown. We stress that KAISER must be deployed immediately to prevent large- scale exploitation of this severe information leakage.
1 Introduction
A central security feature of today’s operating systems is memory isolation. Operating systems ensure that user programs cannot access each other’s memory or kernel memory. This isolation is a cornerstone of our computing environments and allows running multiple applications at the same time on personal devices or executing processes of multiple users on a single machine in the cloud.
On modern processors, the isolation between the ker- nel and user processes is typically realized by a supervi-
9Work was partially done while the author was affiliated to Univer- sity of Pennsylvania and University of Maryland.
sor bit of the processor that defines whether a memory page of the kernel can be accessed or not. The basic idea is that this bit can only be set when entering kernel code and it is cleared when switching to user processes. This hardware feature allows operating systems to map the kernel into the address space of every process and to have very efficient transitions from the user process to the kernel, e.g., for interrupt handling. Consequently, in practice, there is no change of the memory mapping when switching from a user process to the kernel.
In this work, we present Meltdown10. Meltdown is a novel attack that allows overcoming memory isolation completely by providing a simple way for any user pro- cess to read the entire kernel memory of the machine it executes on, including all physical memory mapped in the kernel region. Meltdown does not exploit any soft- ware vulnerability, i.e., it works on all major operating systems. Instead, Meltdown exploits side-channel infor- mation available on most modern processors, e.g., mod- ern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors.
While side-channel attacks typically require very spe- cific knowledge about the target application and are tai- lored to only leak information about its secrets, Melt- down allows an adversary who can run code on the vul- nerable processor to obtain a dump of the entire kernel address space, including any mapped physical memory. The root cause of the simplicity and strength of Melt- down are side effects caused by out-of-order execution.
Out-of-order execution is an important performance feature of today’s processors in order to overcome laten- cies of busy execution units, e.g., a memory fetch unit needs to wait for data arrival from memory. Instead of stalling the execution, modern processors run operations
10Using the practice of responsible disclosure, disjoint groups of au- thors of this paper provided preliminary versions of our results to par- tially overlapping groups of CPU vendors and other affected compa- nies. In coordination with industry, the authors participated in an em- bargo of the results. Meltdown is documented under CVE-2017-5754.
USENIX Association
27th USENIX Security Symposium 973
out-of-order i.e., they look ahead and schedule subse- quent operations to idle execution units of the core. How- ever, such operations often have unwanted side-effects, e.g., timing differences [55, 63, 23] can leak information from both sequential and out-of-order execution.
From a security perspective, one observation is partic- ularly significant: vulnerable out-of-order CPUs allow an unprivileged process to load data from a privileged (kernel or physical) address into a temporary CPU regis- ter. Moreover, the CPU even performs further computa- tions based on this register value, e.g., access to an array based on the register value. By simply discarding the results of the memory lookups (e.g., the modified regis- ter states), if it turns out that an instruction should not have been executed, the processor ensures correct pro- gram execution. Hence, on the architectural level (e.g., the abstract definition of how the processor should per- form computations) no security problem arises.
However, we observed that out-of-order memory lookups influence the cache, which in turn can be de- tected through the cache side channel. As a result, an attacker can dump the entire kernel memory by reading privileged memory in an out-of-order execution stream, and transmit the data from this elusive state via a mi- croarchitectural covert channel (e.g., Flush+Reload) to the outside world. On the receiving end of the covert channel, the register value is reconstructed. Hence, on the microarchitectural level (e.g., the actual hardware im- plementation), there is an exploitable security problem.
Meltdown breaks all security guarantees provided by the CPU’s memory isolation capabilities. We evaluated the attack on modern desktop machines and laptops, as well as servers in the cloud. Meltdown allows an unpriv- ileged process to read data mapped in the kernel address space, including the entire physical memory on Linux, Android and OS X, and a large fraction of the physi- cal memory on Windows. This may include the physical memory of other processes, the kernel, and in the case of kernel-sharing sandbox solutions (e.g., Docker, LXC) or Xen in paravirtualization mode, the memory of the kernel (or hypervisor), and other co-located instances. While the performance heavily depends on the specific machine, e.g., processor speed, TLB and cache sizes, and DRAM speed, we can dump arbitrary kernel and physi- cal memory with 3.2 KB/s to 503 KB/s. Hence, an enor- mous number of systems are affected.
The countermeasure KAISER [20], developed initially to prevent side-channel attacks targeting KASLR, inad- vertently protects against Meltdown as well. Our evalu- ation shows that KAISER prevents Meltdown to a large extent. Consequently, we stress that it is of utmost im- portance to deploy KAISER on all operating systems im- mediately. Fortunately, during a responsible disclosure window, the three major operating systems (Windows,
Linux, and OS X) implemented variants of KAISER and recently rolled out these patches.
Meltdown is distinct from the Spectre Attacks [40] in several ways, notably that Spectre requires tailoring to the victim process’s software environment, but applies more broadly to CPUs and is not mitigated by KAISER.
Contributions. The contributions of this work are:
1. We describe out-of-order execution as a new, ex-
tremely powerful, software-based side channel.
2. We show how out-of-order execution can be com- bined with a microarchitectural covert channel to transfer the data from an elusive state to a receiver
on the outside.
3. We present an end-to-end attack combining out-of-
order execution with exception handlers or TSX, to read arbitrary physical memory without any permis- sions or privileges, on laptops, desktop machines, mobile phones and on public cloud machines.
4. We evaluate the performance of Meltdown and the effects of KAISER on it.
Outline. The remainder of this paper is structured as follows: In Section 2, we describe the fundamental prob- lem which is introduced with out-of-order execution. In Section 3, we provide a toy example illustrating the side channel Meltdown exploits. In Section 4, we describe the building blocks of Meltdown. We present the full attack in Section 5. In Section 6, we evaluate the performance of the Meltdown attack on several different systems and discuss its limitations. In Section 7, we discuss the ef- fects of the software-based KAISER countermeasure and propose solutions in hardware. In Section 8, we discuss related work and conclude our work in Section 9.
2 Background
In this section, we provide background on out-of-order execution, address translation, and cache attacks.
2.1 Out-of-order execution
Out-of-order execution is an optimization technique that allows maximizing the utilization of all execution units of a CPU core as exhaustive as possible. Instead of pro- cessing instructions strictly in the sequential program or- der, the CPU executes them as soon as all required re- sources are available. While the execution unit of the current operation is occupied, other execution units can run ahead. Hence, instructions can be run in parallel as long as their results follow the architectural definition.
In practice, CPUs supporting out-of-order execution allow running operations speculatively to the extent that
974 27th USENIX Security Symposium
USENIX Association
Instruction Fetch & PreDecode
Instruction Queue
4-Way Decode
Branch Predictor
L1 Instruction Cache
μOP Cache μOPs
μOP μOP μOP μOP MUX
Allocation Queue
μOP μOP μOP μOP
Reorder buffer
μOP μOP μOP μOP μOP μOP μOP μOP
μOP μOP μOP μOP μOP μOP μOP μOP
Execution Units
Load Buffer
L1 Data Cache
Store Buffer
Figure 1: Simplified illustration of a single core of the In- tel’s Skylake microarchitecture. Instructions are decoded into μOPs and executed out-of-order in the execution en- gine by individual execution units.
the processor’s out-of-order logic processes instructions before the CPU is certain that the instruction will be needed and committed. In this paper, we refer to spec- ulative execution in a more restricted meaning, where it refers to an instruction sequence following a branch, and use the term out-of-order execution to refer to any way of getting an operation executed before the processor has committed the results of all prior instructions.
In 1967, Tomasulo [61] developed an algorithm that enabled dynamic scheduling of instructions to allow out- of-order execution. Tomasulo [61] introduced a unified reservation station that allows a CPU to use a data value as it has been computed instead of storing it in a reg- ister and re-reading it. The reservation station renames registers to allow instructions that operate on the same physical registers to use the last logical one to solve read- after-write (RAW), write-after-read (WAR) and write- after-write (WAW) hazards. Furthermore, the reserva- tion unit connects all execution units via a common data
bus (CDB). If an operand is not available, the reservation unit can listen on the CDB until it is available and then directly begin the execution of the instruction.
On the Intel architecture, the pipeline consists of the front-end, the execution engine (back-end) and the mem- ory subsystem [32]. x86 instructions are fetched by the front-end from memory and decoded to micro-operations (μOPs) which are continuously sent to the execution en- gine. Out-of-order execution is implemented within the execution engine as illustrated in Figure 1. The Reorder Buffer is responsible for register allocation, register re- naming and retiring. Additionally, other optimizations like move elimination or the recognition of zeroing id- ioms are directly handled by the reorder buffer. The μOPs are forwarded to the Unified Reservation Station (Scheduler) that queues the operations on exit ports that are connected to Execution Units. Each execution unit can perform different tasks like ALU operations, AES operations, address generation units (AGU) or memory loads and stores. AGUs, as well as load and store execu- tion units, are directly connected to the memory subsys- tem to process its requests.
Since CPUs usually do not run linear instruction streams, they have branch prediction units that are used to obtain an educated guess of which instruction is ex- ecuted next. Branch predictors try to determine which direction of a branch is taken before its condition is ac- tually evaluated. Instructions that lie on that path and do not have any dependencies can be executed in advance and their results immediately used if the prediction was correct. If the prediction was incorrect, the reorder buffer allows to rollback to a sane state by clearing the reorder buffer and re-initializing the unified reservation station.
There are various approaches to predict a branch: With static branch prediction [28], the outcome is predicted solely based on the instruction itself. Dynamic branch prediction [8] gathers statistics at run-time to predict the outcome. One-level branch prediction uses a 1-bit or 2- bit counter to record the last outcome of a branch [45]. Modern processors often use two-level adaptive predic- tors [64] with a history of the last n outcomes, allowing to predict regularly recurring patterns. More recently, ideas to use neural branch prediction [62, 38, 60] have been picked up and integrated into CPU architectures [9].
2.2 Address Spaces
To isolate processes from each other, CPUs support vir- tual address spaces where virtual addresses are translated to physical addresses. A virtual address space is divided into a set of pages that can be individually mapped to physical memory through a multi-level page translation table. The translation tables define the actual virtual to physical mapping and also protection properties that
USENIX Association
27th USENIX Security Symposium 975
Memory Subsystem
Execution Engine
ALU, AES, . . . ALU, FMA, . . . ALU, Vect, . . . ALU, Branch
Load data Load data Store data AGU
247 −247 −1
data structures. However, side-channel attacks allow to detect the exact location of kernel data structures [21, 29, 37] or derandomize ASLR in JavaScript [16]. A com- bination of a software bug and the knowledge of these addresses can lead to privileged code execution.
2.3 Cache Attacks
In order to speed-up memory accesses and address trans- lation, the CPU contains small memory buffers, called caches, that store frequently used data. CPU caches hide slow memory access latencies by buffering frequently used data in smaller and faster internal memory. Mod- ern CPUs have multiple levels of caches that are either private per core or shared among them. Address space translation tables are also stored in memory and, thus, also cached in the regular caches.
Cache side-channel attacks exploit timing differences that are introduced by the caches. Different cache attack techniques have been proposed and demonstrated in the past, including Evict+Time [55], Prime+Probe [55, 56], and Flush+Reload [63]. Flush+Reload attacks work on a single cache line granularity. These attacks exploit the shared, inclusive last-level cache. An attacker frequently flushes a targeted memory location using the clflush instruction. By measuring the time it takes to reload the data, the attacker determines whether data was loaded into the cache by another process in the meantime. The Flush+Reload attack has been used for attacks on various computations, e.g., cryptographic algorithms [63, 36, 4], web server function calls [65], user input [23, 47, 58], and kernel addressing information [21].
A special use case of a side-channel attack is a covert channel. Here the attacker controls both, the part that in- duces the side effect, and the part that measures the side effect. This can be used to leak information from one security domain to another, while bypassing any bound- aries existing on the architectural level or above. Both Prime+Probe and Flush+Reload have been used in high- performance covert channels [48, 52, 22].
3 A Toy Example
In this section, we start with a toy example, i.e., a simple code snippet, to illustrate that out-of-order execution can change the microarchitectural state in a way that leaks information. However, despite its simplicity, it is used as a basis for Section 4 and Section 5, where we show how this change in state can be exploited for an attack.
Listing 1 shows a simple code snippet first raising an (unhandled) exception and then accessing an array. The property of an exception is that the control flow does not continue with the code after the exception, but jumps to an exception handler in the operating system. Regardless
Figure 2: The physical memory is directly mapped in the kernel at a certain offset. A physical address (blue) which is mapped accessible to the user space is also mapped in the kernel space through the direct mapping.
are used to enforce privilege checks, such as readable, writable, executable and user-accessible. The currently used translation table is held in a special CPU register. On each context switch, the operating system updates this register with the next process’ translation table ad- dress in order to implement per-process virtual address spaces. Because of that, each process can only reference data that belongs to its virtual address space. Each vir- tual address space itself is split into a user and a kernel part. While the user address space can be accessed by the running application, the kernel address space can only be accessed if the CPU is running in privileged mode. This is enforced by the operating system disabling the user- accessible property of the corresponding translation ta- bles. The kernel address space does not only have mem- ory mapped for the kernel’s own usage, but it also needs to perform operations on user pages, e.g., filling them with data. Consequently, the entire physical memory is typically mapped in the kernel. On Linux and OS X, this is done via a direct-physical map, i.e., the entire physi- cal memory is directly mapped to a pre-defined virtual address (cf. Figure 2).
Instead of a direct-physical map, Windows maintains a multiple so-called paged pools, non-paged pools, and the system cache. These pools are virtual memory re- gions in the kernel address space mapping physical pages to virtual addresses which are either required to remain in the memory (non-paged pool) or can be removed from the memory because a copy is already stored on th
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com