CPU hardware implementations are vulnerable to side-channel attacks referred to as Meltdown and Spectre. Both Spectre and Meltdown take advantage of the ability to extract information from instructions that have executed on a CPU using the CPU cache as a side-channel. These attacks are described in detail by Google Project Zero, the Institute of Applied Information Processing and Communications (IAIK) at Graz University of Technology (TU Graz) and Anders Fogh. The issues are organized into three variants:
Spectre attacks take advantage of a CPU's branch prediction capabilities. Modern CPUs include a feature called branch prediction, which speculatively executes instructions at a location that the CPU believes it will branch to. Such speculative execution helps to more fully utilize the parts of the CPU, minimizing the time waiting, and therefore improving performance. When a branch is successfully predicted, instructions will retire, which means the outcomes of the instructions such as register and memory writes will be committed. If a branch is mispredicted, the speculatively-executed instructions will be discarded, and the direct side-effects of the instructions are undone. What is not undone are the indirect side-effects, such as CPU cache changes. By measuring latency of memory access operations, the cache can be used to extract values from speculatively-executed instructions.
With Spectre variant 1 (CVE-2017-5753), the instructions after a conditional branch are speculatively executed as the result of a misprediction. With Spectre variant 2 (CVE-2017-5715), the CPU executes instructions at a location determined by a mispredicted branch target.
With both variants of the Spectre attack, the impact is that a process may leak sensitive data to other processes on a system. Spectre may also allow one part of an application to access other parts of the same process memory space that would otherwise not be permitted.
While the Spectre attack itself does not cross a user/kernel memory privilege boundary, depending on the configuration of the target platform, the Spectre attack may indirectly allow a user-space application to access kernel memory. For example, the Project Zero blog post describes a scenario that uses eBPF to exfiltrate kernel memory contents into user-space code. This is made possible because eBPF JIT allows for userspace applications to inject code that is executed in kernel space. While this code is verified by the kernel, eBPF-compliant code will be allowed to execute with kernel permissions. The exploit described by Project Zero leverages eBPF to execute the Spectre attack in kernel space, while exfiltrating the data to user space. It is possible that other technologies that allow in-kernel code execution may also possibly be leveraged to leak kernel memory using Spectre.
Meltdown is related to the Spectre attack in that it also uses a cache side channel to access data that otherwise wouldn't be available. The main difference is that it leverages out-of-order execution capabilities in modern CPUs. Like speculative execution due to branch prediction, as used by Spectre, out-of-order execution on a CPU is a technique for ensuring fullest utilization of the CPU's parts. Although instructions may appear sequentially in the machine language, a CPU that supports out-of-order execution may execute instructions in a non-sequential manner, which can minimize the time that a CPU spends idle.
Meltdown leverages insecure behavior that has been demonstrated in Intel CPUs and may affect CPUs from other vendors. Vulnerable CPUs allow memory reads in out-of-order instruction execution, and also contain a race condition between the raising of exceptions and the out-of-order instruction execution. The Meltdown attack reads a kernel memory value, which raises an exception because code running with user-space privileges are not permitted to directly read kernel memory. However, due to the race condition, out-of-order instructions following the faulting instruction may also execute. Even though instructions appear after the faulting instruction, out-of-order execution allows them to execute, using data retrieved from the instruction that raises the exception. By the time the exception is raised, some number of out-of-order instructions have executed. Although the raised exception causes the CPU to roll back the out-of-order instructions, the cache state is not reverted. This allows data from out-of-order instructions to persist beyond the point when the exception has been raised.
The impact of Meltdown is that a process running in user space is able to view the contents of kernel memory. Meltdown may also allow Spectre-like memory content leaking that does not cross the user/kernel privilege boundary.
The Linux kernel mitigations for Meltdown are referred to as KAISER, and subsequently KPTI, which aim to improve separation of kernel and user memory pages. Because the Spectre attacks do not cross user/kernel boundaries, the protections introduced with KAISER/KPTI do not add any protection against them.
The following table compares Spectre and Meltdown.
An attacker able to execute code with user privileges can achieve various impacts. The Meltdown attack allows reading of kernel memory from userspace. This can result in privilege escalation, disclosure of sensitive information, or it can weaken kernel-level protections, such as KASLR. The Spectre attack can allow inter-process or intra-process data leaks.
Android Open Source Project Affected
Debian GNU/Linux Affected
DragonFly BSD Project Affected
Fedora Project Affected
Fortinet, Inc. Affected
FreeBSD Project Affected
Hewlett Packard Enterprise Affected
IBM Corporation Affected
Linux Kernel Affected
Oracle Corporation Affected
QUALCOMM Incorporated Affected
Red Hat, Inc. Affected
SUSE Linux Affected
Trend Micro Affected
openSUSE project Affected
NetApp Not Affected
Raspberry Pi Not Affected
Technicolor Not Affected
ASUSTeK Computer Inc. Unknown
F5 Networks, Inc. Unknown
HP Inc. Unknown
Samsung Semiconductor Inc. Unknown
Toshiba Corporation Unknown
These issues were researched and reported by researchers at Google Project Zero (Jann Horn) the Institute of Applied Information Processing and Communications (IAIK) at Graz University of Technology (Gruss et. al.), Paul Kocher, and Anders Fogh.
This document was written by Art Manion and Will Dormann.