关于Inter漏洞“熔断”的论文翻译（三）（完）

5 Meltdown

5 熔断

In this section, present Meltdown, a powerful attack allowing to read arbitrary physical memory from an unprivileged user program, comprised of the building blocks presented in Section 4. First, we discuss the attack setting to emphasize the wide applicability of this attack. Second, we present an attack overview, showing how Meltdown can be mounted on both Windows and Linux on personal computers as well as in the cloud. Finally, we discuss a concrete implementation of Meltdown allowing to dump kernel memory with up to 503KB/s.

在本节中，如今的熔断，是一个强悍的攻击方式，允许从一个无权限的用户程序中读取任意的物理内存，这个程序由第四部分提供的模块组成。首先，我们讨论攻击配置以强调这种攻击的广泛适用性。其次，我们展示了一个攻击概述，展示了如何将熔断安装在Windows和Linux系统的个人电脑上，以及云服务器中。最后，我们讨论熔断的具体实现，它将允许以高达503KB / s的速度转储内核内存。

Attack setting.

攻击配置

In our attack, we consider personal computers and virtual machines in the cloud. In the attack scenario, the attacker has arbitrary unprivileged code execution on the attacked system, i.e., the attacker can run any code with the privileges of a normal user. However, the attacker has no physical access to the machine. Further, we assume that the system is fully protected with state-of-the-art software-based defenses such as ASLR and KASLR as well as CPU features like SMAP, SMEP, NX, and PXN. Most importantly, we assume a completely bug-free operating system, thus, no software vulnerability exists that can be exploited to gain kernel privileges or leak information. The attacker targets secret user data, e.g., passwords and private keys, or any other valuable information.

在此次攻击中，我们安排的受害者是个人电脑和云虚拟机。在此次攻击场景中，攻击者能够在被攻击的系统上执行任意非特权的代码，即攻击者可以以普通用户的权限运行任何代码，但攻击者没有实际的物理访问权限。此外，我们假设系统拥有诸如ASLR和KASLR等先进软件防御手段以及SMAP，SMEP，NX和PXN等CPU特性的充分保护。最重要的是，我们假设这是一个完全没有bug的操作系统，因此没有任何软件漏洞可以被利用来获得内核权限或泄露信息。攻击者针对保密用户数据，例如密码和私钥或任何其他有价值的信息。

 

5.1 Attack Description

5.1 攻击描述

Meltdown combines the two building blocks discussed in Section 4. First, an attacker makes the CPU execute a transient instruction sequence which uses an inaccessible secret value stored somewhere in physical memory (cf. Section 4.1). The transient instruction sequence acts as the transmitter of a covert channel (cf. Section 4.2), ultimately leaking the secret value to the attacker.

熔断包括在第4节中已讨论过的两个模块。首先，攻击者使CPU执行一个瞬态指令序列，使用物理内存中某处存储的不可访问的保密值（参见4.1节）。瞬态指令序列充当隐蔽信道的发送器（参见4.2节），最终将保密值泄露给攻击者。

Meltdown consists of 3 steps:

熔断包括了三个步骤：

Step 1 The content of an attacker-chosen memory location, which is inaccessible to the attacker, is loaded into a register.

步骤1攻击者选择的，原本其无权访问的，内存地址的内容将被加载到寄存器中。

Step 2 A transient instruction accesses a cache line based on the secret content of the register.

步骤2瞬态指令根据寄存器的保密内容访问高速缓存行。

Step 3 The attacker uses Flush+Reload to determine the accessed cache line and hence the secret stored at the chosen memory location.

步骤3攻击者使用Flush + Reload来确定所访问的缓存行，从而确定存储在所选内存位置的保密值。

By repeating these steps for different memory locations, the attacker can dump the kernel memory, including the entire physical memory.

通过针对不同的内存位置重复这些步骤，攻击者可以转储内核内存，包括整个物理内存。

Listing 2 shows the basic implementation of the transient instruction sequence and the sending part of the covert channel, using x86 assembly instructions. Note that this part of the attack could also be implemented entirely in higher level languages like C. In the following, we will discuss each step of Meltdown and the corresponding code line in Listing 2.

清单2列出了使用x86汇编指令的瞬态指令序列和隐蔽通道发送端的基本实现。请注意，这部分攻击也可以完全在C这样的高级语言中实现。下面我们将讨论熔断的每一步以及清单2中相应的代码行。

Listing 2: The core instruction sequence of Meltdown. An inaccessible kernel address is moved to a register, raising an exception. The subsequent instructions are already executed out of order before the exception is raised, leaking the content of the kernel address through the indirect memory access.

清单2：熔断的核心指令序列。一个无法访问的内核地址被移动到一个寄存器，引发一个异常中断。后续指令在引发异常之前已经被乱序执行，通过间接内存访问泄漏内核地址的内容。

 

Step 1: Reading the secret

步骤1：读取保密值

To load data from the main memory into a register, the data in the main memory is referenced using a virtual address. In parallel to translating a virtual address into a physical address, the CPU also checks the permission bits of the virtual address, i.e., whether this virtual address is user accessible or only accessible by the kernel. As already discussed in Section 2.2, this hardware-based isolation through a permission bit is considered secure and recommended by the hardware vendors. Hence, modern operating systems always map the entire kernel into the virtual address space of every user process.

为了将数据从主内存加载到寄存器中，主内存中的数据通过一个虚拟地址被引用。在将虚拟地址转换成物理地址的同时，CPU还将检查虚拟地址的许可位，即该虚拟地址是用户可访问的还是只能由内核访问的。正如2.2节中所讨论的，通过权限位进行的基于硬件的隔离被认为是安全的，并被硬件厂商推荐。所以现代操作系统总是将整个内核映射到每个用户进程的虚拟地址空间。

As a consequence, all kernel addresses lead to a valid physical address when translating them, and the CPU can access the content of such addresses. The only difference to accessing a user space address is that the CPU raises an exception as the current permission level does not allow to access such an address. Hence, the user space cannot simply read the contents of such an address. However, Meltdown exploits the out-of-order execution of modern CPUs, which still executes instructions in the small time window between the illegal memory access and the raising of the exception.

因此，所有内核地址在被翻译时都会生成一个有效的物理地址，并且CPU可以访问这些地址的内容。与访问用户空间地址的唯一区别是，CPU会抛出异常，因为当前的权限级别不允许访问这样的地址。所以用户空间不能简单地读取这样的地址内容。然而，熔断利用了现代CPU的乱序执行特性，它仍然可以在非法内存访问和异常引发之间的短暂空挡中执行指令。

In line 4 of Listing 2, we load the byte value located at the target kernel address, stored in the RCX register, into the least significant byte of the RAX register represented by AL. As explained in more detail in Section 2.1, the MOV instruction is fetched by the core, decoded into μOPs, allocated, and sent to the reorder buffer. There, architectural registers (e.g., RAX and RCX in Listing 2) are mapped to underlying physical registers enabling out-of-order execution. Trying to utilize the pipeline as much as possible, subsequent instructions (lines 5-7) are already decoded and allocated as μOPs as well. The μOPs are further sent to the reservation station holding the μOPs while they wait to be executed by the corresponding execution unit. The execution of a μOPs can be delayed if execution units are already used to their corresponding capacity or operand values have not been calculated yet.

在清单2的第4行中，我们将存储在RCX寄存器中的目标内核地址处的字节值加载到由AL表示的RAX寄存器的最低有效字节中。正如在第2.1节中更详细的解释，MOV指令由内核提取，解码成微指令，分配并发送到重排序缓冲器。在那里，架构寄存器（例如清单2中的RAX和RCX）被映射到底层物理寄存器，从而实现乱序执行。为了试图尽可能多地利用流水线，随后的指令（第5-7行）已经被解码并分配成微指令。在等待被相应的执行单元执行的时候，微指令进一步被发送到保留段中保存。如果执行单元已经被用作对应的容器或是操作数的值还没有被计算完毕，那么微指令的执行可能被延迟。

When the kernel address is loaded in line 4, it is likely that the CPU already issued the subsequent instructions as part of the out-or-order execution, and that their corresponding μOPs wait in the reservation station for the content of the kernel address to arrive. As soon as the fetched data is observed on the common data bus, the μOPs can begin their execution.

当内核地址在第4行被加载时，作为乱序执行的一部分，CPU很可能已经发出后续指令，并且它们相应的微指令在保留站中等待内核地址的内容到达。只要在公共数据总线上观察到读取的数据，微指令就可以开始执行。

When the μOPs finish their execution, they retire in-order, and, thus, their results are committed to the architectural state. During the retirement, any interrupts and exception that occurred during the execution of the instruction are handled. Thus, if the MOV instruction that loads the kernel address is retired, the exception is registered and the pipeline is flushed to eliminate all results of subsequent instructions which were executed out of order. However, there is a race condition between raising this exception and our attack step 2 which we describe below.

当微指令执行完毕时，就会按顺序退出，因此执行结果会提交到架构状态。在清退期间，任何在执行指令期间发生的中断和异常将被处理。所以如果加载内核地址的MOV指令被退出，则引发异常并刷新流水线以消除乱序执行的后续指令的所有结果。然而，引发这个异常和与我们下面描述的攻击步骤2之间，存在了竞争条件。

As reported by Gruss et al. [9], prefetching kernel addresses sometimes succeeds. We found that prefetching the kernel address can slightly improve the performance of the attack on some systems.

正如Gruss等人^[9]所提出的那样，预取内核地址有时会成功。我们发现预取内核地址可以稍微提高在某些系统上的攻击性能。

 

Step 2: Transmitting the secret

步骤2：传递保密值

The instruction sequence from step 1 which is executed out of order has to be chosen in a way that it becomes a transient instruction sequence. If this transient instruction sequence is executed before the MOV instruction is retired (i.e., raises the exception), and the transient instruction sequence performed computations based on the secret, it can be utilized to transmit the secret to the attacker.

步骤1中的乱序指令序列不得不被选择成为瞬态指令序列。如果在MOV指令退出之前执行该瞬态指令序列（即，引发异常），并且瞬态指令序列基于保密值执行运算，则可以利用该序列将保密值发送给攻击者。

As already discussed, we utilize cache attacks that allow to build fast and low-noise covert channel using the CPU’s cache. Thus, the transient instruction sequence has to encode the secret into the microarchitecturall cache state, similarly to the toy example in Section 3.

正如我们已经讨论过的，我们利用缓存攻击，从而可以利用CPU的缓存构建快速，低噪声的隐蔽通道。因此，与第3节中的玩具示例类似，瞬态指令序列必须将保密值编码为微架构缓存状态。

We allocate a probe array in memory and ensure that no part of this array is cached. To transmit the secret, the transient instruction sequence contains an indirect memory access to an address which is calculated based on the secret (inaccessible) value. In line 5 of Listing 2 the secret value from step 1 is multiplied by the page size, i.e., 4 KB. The multiplication of the secret ensures that accesses to the array have a large spatial distance to each other. This prevents the hardware prefetcher from loading adjacent memory locations into the cache as well. Here, we read a single byte at once, hence our probe array is 256×4096 bytes, assuming 4KB pages.

我们在内存中分配一个探针数组，并确保这个数组的任何部分都不被缓存。为了传输保密值，瞬态指令序列包含对基于（不可访问的）保密值计算的地址的间接内存访问。在清单2的第5行中，来自步骤1的保密值乘以页面大小，即4KB。对保密值的乘法操作保证对数组各个数据的访问之间有很大的空间距离，这可以防止硬件预取器将相邻的内存位置加载到缓存中。在这里，我们一次读取一个字节，假设页面大小为4KB，那么我们的探针数组是256×4096字节。

Note that in the out-of-order execution we have a noise-bias towards register value ‘0’. We discuss the reasons for this in Section 5.2. However, for this reason, we introduce a retry-logic into the transient instruction sequence. In case we read a ‘0’, we try to read the secret again (step 1). In line 7, the multiplied secret is added to the base address of the probe array, forming the target address of the covert channel. This address is read to cache the corresponding cache line. Consequently, our transient instruction sequence affects the cache state based on the secret value that was read in step 1.

值得注意的是，在乱序执行中，我们对寄存器值“0”有一个噪声偏差。我们将在在5.2节讨论原因。出于此我们在瞬态指令序列中引入了一个重试逻辑：如果我们读取“0”，我们将尝试再次读取保密值（步骤1）。在第7行中，将保密值的乘积添加到探针数组的基础地址，构成隐蔽信道的目标地址。这个地址将被读取以缓存相应的缓存行。因此，我们的瞬态指令序列会影响那些在步骤1中读取的保密值的缓存状态。

Since the transient instruction sequence in step 2 races against raising the exception, reducing the runtime of step 2 can significantly improve the performance of the attack. For instance, taking care that the address translation for the probe array is cached in the TLB increases the attack performance on some systems.

由于步骤2中的瞬态指令序列会阻止抛出异常，因此减少步骤2的运行时间可以显着提高攻击的性能。例如，注意探针阵列的地址转换被缓存在TLB中会增加在某些系统上的攻击性能。

 

Step 3: Receiving the secret

步骤3：接收保密值

In step 3, the attacker recovers the secret value (step 1) by leveraging a microarchitectural side-channel attack (i.e., the receiving end of a microarchitectural covert channel) that transfers the cache state (step 2) back into an architectural state. As discussed in Section 4.2, Meltdown relies on Flush+ Reload to transfer the cache state into an architectural state.

在步骤3中，攻击者通过利用将高速缓存状态（步骤2）转移回架构状态的微体系结构旁路信道攻击（即，微体系结构隐蔽通道的接收端）来恢复保密值（步骤1）。正如在第4.2节中讨论的那样，熔断依靠Flush + Reload将缓存状态转换为体系结构状态。

When the transient instruction sequence of step 2 is executed, exactly one cache line of the probe array is cached. The position of the cached cache line within the probe array depends only on the secret which is read in step 1. Thus, the attacker iterates over all 256 pages of the probe array and measures the access time for every first cache line (i.e., offset) on the page. The number of the page containing the cached cache line corresponds directly to the secret value.

当步骤2的瞬态指令序列被执行时，恰好探针数组一个缓存行被缓存。探针数组中被缓存的缓存行的位置仅取决于在步骤1中读取的保密值。因此，攻击者遍历探针数组的所有256个页面并测量页面上首条缓存行的访问时间（即，偏移量 ）。包含缓存的缓存行的页面编号直接对应于保密值。

 

Dumping the entire physical memory

转储整个物理内存

By repeating all 3 steps of Meltdown, the attacker can dump the entire memory by iterating over all different addresses. However, as the memory access to the kernel address raises an exception that terminates the program, we use one of the methods described in Section 4.1 to handle or suppress the exception.

通过重复熔断的所有3个步骤，攻击者可以遍历所有不同的地址来转储整个内存。但是，由于对内核地址的内存访问引发了终止程序的异常，我们使用4.1节中描述的方法之一来处理或抑制异常。

As all major operating systems also typically map the entire physical memory into the kernel address space (cf. Section 2.2) in every user process, Meltdown is not only limited to reading kernel memory but it is capable of reading the entire physical memory of the target machine.

由于所有主要的操作系统通常也将整个物理内存映射到每个用户进程的内核地址空间（参见2.2节），所以熔断不仅限于读取内核内存，还能够读取目标机器的整个物理内存。

 

5.2 Optimizations and Limitations

5.2 优化和限制

The case of 0

有关于0

If the exception is triggered while trying to read from an inaccessible kernel address, the register where the data should be stored, appears to be zeroed out. This is reasonable because if the exception is unhandled, the user space application is terminated, and the value from the inaccessible kernel address could be observed in the register contents stored in the core dump of the crashed process. The direct solution to fix this problem is to zero out the corresponding registers. If the zeroing out of the register is faster than the execution of the subsequent instruction (line 5 in Listing 2), the attacker may read a false value in the third step. To prevent the transient instruction sequence from continuing with a wrong value, i.e., ‘0’, Meltdown retries reading the address until it encounters a value different from ‘0’ (line 6). As the transient instruction sequence terminates after the exception is raised, there is no cache access if the secret value is 0. Thus, Meltdown assumes that the secret value is indeed ‘0’ if there is no cache hit at all.

如果异常是在尝试读取不可访问的内核地址时触发，应将存储数据的寄存器输出为零。这是合理的，因为如果异常未处理，则用户空间应用程序被终止，并且来自不可访问的内核地址的值可以在保存在崩溃进程的内核转储中的寄存器内容中被观察到。解决这个问题的直接方法是将相应的寄存器清零。如果寄存器清零快于后续指令的执行（清单2中的第5行），则攻击者可能会在第三步中读取一个错误的值。为了防止瞬态指令序列持有一个错误的值继续执行，即'0'，熔断重试读取地址，直到它遇到一个不为'0'（第6行）的值。当瞬态指令序列在引发异常之后终止时，如果保密值为0，则不存在高速缓存访问。因此，如果根本没有高速缓存命中，则熔断假定保密值确实为“0”。

The loop is terminated by either the read value not being ‘0’ or by the raised exception of the invalid memory access. Note that this loop does not slow down the attack measurably, since, in either case, the processor runs ahead of the illegal memory access, regardless of whether ahead is a loop or ahead is a linear control flow. In either case, the time until the control flow returned from exception handling or exception suppression remains the same with and without this loop. Thus, capturing read ‘0’s beforehand and recovering early from a lost race condition vastly increases the reading speed.

当读取值不为“0”或无效内存访问引发的异常都将导致循环终止。请注意，此循环不会显著减慢攻击，因为在任何情况下，处理器都会在非法内存访问之前运行，无论之前是一个循环还是线性控制流。在任何一种情况下，无论有无此循环，异常处理或异常抑制之后重回控制流的时间都保持不变。因此，事先捕获读取“0”并且从耗损的高速状态中提前恢复，这大大提高了读取速度。

 

Single-bit transmission

单比特传输

In the attack description in Section 5.1, the attacker transmitted 8 bits through the covert channel at once and performed 28 = 256 Flush+ Reload measurements to recover the secret. However, there is a clear trade-off between running more transient instruction sequences and performing more Flush+ Reload measurements. The attacker could transmit an arbitrary number of bits in a single transmission through the covert channel, by either reading more bits using a MOV instruction for a larger data value. Furthermore, the attacker could mask bits using additional instructions in the transient instruction sequence. We found the number of additional instructions in the transient instruction sequence to have a negligible influence on the performance of the attack.

在5.1节的攻击描述中，攻击者立即通过隐蔽信道发送8位数据，并执行2⁸ = 256次Flush + Reload来恢复保密值。然而，在运行更多的瞬态指令序列和执行更多的Flush + Reload之间往往可以找到一个清晰的平衡点。攻击者可以通过隐藏信道在一次传输中传输任意数量的比特，通过使用MOV指令读取更多的比特来获取更多的数值。此外，攻击者可以使用瞬态指令序列中的附加指令来屏蔽位。我们发现，瞬态指令序列中的附加指令的数量对于攻击的性能的影响是微乎其微的。

The performance bottleneck in the generic attack description above is indeed, the time spent on Flush+ Reload measurements. In fact, with this implementation, almost the entire time will be spent on Flush+Reload measurements. By transmitting only a single bit, we can omit all but one Flush+Reload measurement, i.e., the measurement on cache line 1. If the transmitted bit was a ‘1’, then we observe a cache hit on cache line 1. Otherwise, we observe no cache hit on cache line 1.

上述通用攻击描述中的性能瓶颈确实是花费在Flush + Reload测量上的时间。实际上，在这个实现中，几乎全部时间都将花在Flush + Reload测量上。通过只发送单比特数据，我们可以省略除了一次Flush + Reload测量之外的所有测量，即在高速缓存行1上的测量。如果发送的位是“1”，那么我们可以观测到缓存行1上的缓存命中。否则就不会观测到缓存行1上的缓存命中。

Transmitting only a single bit at once also has drawbacks. As described above, our side channel has a bias towards a secret value of ‘0’. If we read and transmit multiple bits at once, the likelihood that all bits are ‘0’ may quite small for actual user data. The likelihood that a single bit is ‘0’ is typically close to 50 %. Hence, the number of bits read and transmitted at once is a trade-off between some implicit error-reduction and the overall transmission rate of the covert channel.

一次只传送单比特也有缺点。如上所述，我们的旁路信道对保密值“0”存在歧义。如果我们一次读取和传输多个位，则对于实际用户数据而言，所有位全为“0”的可能性相当的小。而单个位为“0”的可能性通常接近50％。因此，一次性读取和传输的位数，是隐式错误发生率和隐蔽信道总体传输速率之间的平衡点。

However, since the error rates are quite small in either case, our evaluation (cf. Section 6) is based on the single-bit transmission mechanics.

但是，由于这两种情况下的误码率都很小，所以我们的评估（参见第6节）是基于单比特传输机制。

 

Exception Suppression using Intel TSX

使用Intel TSX异常抑制

In Section 4.1, we discussed the option to prevent that an exception is raised due an invalid memory access in the first place. Using Intel TSX, a hardware transactional memory implementation, we can completely suppress the exception [17].

在4.1节中，我们首先讨论了防止由于无效内存访问而引发异常的选项。使用英特尔TSX，一个硬件事务存储器实现，我们完全可以抑制异常^[17]。

With Intel TSX, multiple instructions can be grouped to a transaction, which appears to be an atomic operation, i.e., either all or no instruction is executed. If one instruction within the transaction fails, already executed instructions are reverted, but no exception is raised.

使用英特尔TSX时，可以将多条指令组合到一个事务中，这看起来是一个原子操作，即全部或全不执行指令。如果事务中的一条指令失败，已经执行的指令将被恢复，但不会产生异常。

If we wrap the code from Listing 2 with such a TSX instruction, any exception is suppressed. However, the microarchitectural effects are still visible, i.e., the cache state is persistently manipulated from within the hardware transaction [7]. This results in a higher channel capacity, as suppressing the exception is significantly faster than trapping into the kernel for handling the exception, and continuing afterwards.

如果我们用清单2中的代码封装这样的TSX指令，任何异常都会被抑制。然而，微体系结构的效果仍然是可见的，即高速缓存状态在硬件事务中被持久地持有^[7]。这样的结果是更高的通道容量，因为抑制异常的速度明显快于陷入内核处理异常之后再继续。

 

Dealing with KASLR

使用KASLR

In 2013, kernel address space layout randomization (KASLR) had been introduced to the Linux kernel (starting from version 3.14 [4]) allowing to randomize the location of the kernel code at boot time. However, only as recently as May 2017, KASLR had been enabled by default in version 4.12 [27]. With KASLR also the direct-physical map is randomized and, thus, not fixed at a certain address such that the attacker is required to obtain the randomized offset before mounting the Meltdown attack. However, the randomization is limited to 40 bit.

在2013年，内核地址空间分配随机化（KASLR）已经引入到Linux内核（从版本3.14 ^[4]开始），允许在启动时随机化内核代码的位置。但是，直到2017年5月，KASLR才在4.12版本中默认启用[27]。使用KASLR时，直接物理映射也是随机的，因此不固定在某个地址，这样攻击者在启动熔毁攻击之前需要获得随机偏移量。但随机偏移量被限制在40位。

Thus, if we assume a setup of the target machine with 8GB of RAM, it is sufficient to test the address space for addresses in 8GB steps. This allows to cover the search space of 40 bit with only 128 tests in the worst case. If the attacker can successfully obtain a value from a tested address, the attacker can proceed dumping the entire memory from that location. This allows to mount Meltdown on a system despite being protected by KASLR within seconds.

因此，如果我们假设使用8GB RAM配置的目标机器，则以8GB的长度来测试地址空间是足够的。这允许在最坏的情况下仅用128次测试覆盖40位的搜索空间。如果攻击者能够成功地从测试地址获取值，则攻击者可以从该位置执行转储整个内存。这样即使在几秒钟之内受到KASLR的保护，也仍然可以在系统上启动熔毁。

 

6 Evaluation

6 评估

In this section, we evaluate Meltdown and the performance of our proof-of-concept implementation. Section 6.1 discusses the information which Meltdown can leak, and Section 6.2 evaluates the performance of Meltdown, including countermeasures. Finally, we discuss limitations for AMD and ARM in Section 6.4.

在本节中，我们将评估熔毁和概念实现的性能。6.1节讨论熔毁可能泄漏的信息，6.2节评估熔毁的性能，包括对策。最后，我们在6.4节讨论AMD和ARM的局限性。

Table 1 shows a list of configurations on which we successfully reproduced Meltdown. For the evaluation of Meltdown, we used both laptops as well as desktop PCs with Intel Core CPUs. For the cloud setup, we tested Meltdown in virtual machines running on Intel Xeon CPUs hosted in the Amazon Elastic Compute Cloud as well as on DigitalOcean. Note that for ethical reasons we did not use Meltdown on addresses referring to physical memory of other tenants.

表1展示了我们成功重现熔毁的配置列表。对于熔毁的评估，我们使用了笔记本电脑以及带有Intel Core CPU的台式电脑。对于云服务器，我们测试了运行在Amazon Elastic Compute Cloud（ECS）和DigitalOcean Intel Xeon CPU上虚拟机中的熔毁。请注意，出于道德方面的原因，我们并没有在涉及其他租户物理内存的地址上使用熔毁。

Table 1: Experimental setups.

表1：实验配置。

6.1 Information Leakage and Environments

6.1信息泄漏和环境

We evaluated Meltdown on both Linux (cf. Section 6.1.1) and Windows 10 (cf. Section 6.1.3). On both operating systems, Meltdown can successfully leak kernel memory. Furthermore, we also evaluated the effect of the KAISER patches on Meltdown on Linux, to show that KAISER prevents the leakage of kernel memory (cf. Section 6.1.2). Finally, we discuss the information leakage when running inside containers such as Docker (cf. Section 6.1.4).

我们在Linux（参见6.1.1节）和Windows 10（参见6.1.3节）上评估了熔断攻击。在这两个操作系统上，熔断都可以成功泄漏内核内存。此外，我们还评估了KAISER补丁对Linux上的熔断漏洞的影响，表明KAISER可以防止内核内存的泄漏（参见6.1.2节）。最后，我们讨论在Docker等容器中运行时的信息泄漏（参见6.1.4节）。

 

6.1.1 Linux

6.1.1 Linux系统

We successfully evaluated Meltdown on multiple versions of the Linux kernel, from 2.6.32 to 4.13.0. On all these versions of the Linux kernel, the kernel address space is also mapped into the user address space. Thus, all kernel addresses are also mapped into the address space of user space applications, but any access is prevented due to the permission settings for these addresses. As Meltdown bypasses these permission settings, an attacker can leak the complete kernel memory if the virtual address of the kernel base is known. Since all major operating systems also map the entire physical memory into the kernel address space (cf. Section 2.2), all physical memory can also be read.

我们成功评估了熔断攻击在多个版本（从2.6.32到4.13.0）下对Linux内核的影响。在所有这些版本的Linux内核中，内核地址空间都映射到用户地址空间。因此所有的内核地址也映射到用户空间应用程序的地址空间，但是由于这些地址的权限设置，所有的访问都被阻止。当熔断试图绕过这些权限设置时，如果内核基准地址的虚拟地址已知，攻击者可以暴露整个内核内存。由于所有主要的操作系统也是将整个物理内存映射到内核地址空间（参见2.2节）的，所以所有的物理内存也可以被读取。

Before kernel 4.12, kernel address space layout randomization (KASLR) was not active by default [30]. If KASLR is active, Meltdown can still be used to find the kernel by searching through the address space (cf. Section 5.2). An attacker can also simply de-randomize the direct-physical map by iterating through the virtual address space. Without KASLR, the direct-physical map starts at address 0xffff 8800 0000 0000 and linearly maps the entire physical memory. On such systems, an attacker can use Meltdown to dump the entire physical memory, simply by reading from virtual addresses starting at 0xffff 8800 0000 0000.

在内核4.12之前，内核地址空间布局随机化（KASLR）在默认情况下是不启动的^[30]。如果KASLR处于激活状态，则通过搜索地址空间仍然可以使用熔断来查找内核地址（参见第5.2节）。攻击者也可以简单地通过遍历虚拟地址空间来将直接物理映射去随机化。 没有KASLR，直接物理映射从地址0xffff 8800 0000 0000开始，并线性映射整个物理内存。在这样的系统上，攻击者可以使用熔断来转储整个物理内存，只需简单的读取从0xffff 8800 0000 0000开始的虚拟地址即可。

On newer systems, where KASLR is active by default, the randomization of the direct-physical map is limited to 40 bit. It is even further limited due to the linearity of the mapping. Assuming that the target system has at least 8GB of physical memory, the attacker can test addresses in steps of 8 GB, resulting in a maximum of 128 memory locations to test. Starting from one discovered location, the attacker can again dump the entire physical memory.

在较新的系统中，默认情况下KASLR处于激活状态，直接物理映射的随机化被限制为40位。但由于映射的线性，它甚至受到更多限制。假设目标系统至少有8GB物理内存，攻击者可以以8GB的长度测试地址，最多可以测试128个内存位置。从一个被发现的正确位置开始，攻击者仍然可以再次转储整个物理内存。

Hence, for the evaluation, we can assume that the randomization is either disabled, or the offset was already retrieved in a pre-computation step.

因此，为了评估性能，我们可以假设随机化被禁用，或是已经在预算步骤中检索到偏移量。

 

6.1.2 Linux with KAISER Patch

6.1.2 Linux与KAISER补丁

The KAISER patch by Gruss et al. [8] implements a stronger isolation between kernel and user space. KAISER does not map any kernel memory in the user space, except for some parts required by the x86 architecture (e.g., interrupt handlers). Thus, there is no valid mapping to either kernel memory or physical memory (via the direct-physical map) in the user space, and such addresses can therefore not be resolved. Consequently, Meltdown cannot leak any kernel or physical memory except for the few memory locations which have to be mapped in user space.

Gruss等人的KAISER补丁^[8]实现了内核和用户空间之间更强的隔离。KAISER不会映射用户空间中的任何内核内存，除了x86架构所需的某些部分（例如中断处理程序）。因此，不论是内核内存还是物理内存（通过直接物理映射）在用户空间中都不存在有效的映射，所以这些地址不能被解析。因此，除了必须映射到用户空间的少数内存位置外，熔毁攻击不能泄漏任何内核或物理内存。

We verified that KAISER indeed prevents Meltdown, and there is no leakage of any kernel or physical memory.

我们证实KAISER确实可以防止熔毁，避免任何内核或物理内存的信息泄漏。

Furthermore, if KASLR is active, and the few remaining memory locations are randomized, finding these memory locations is not trivial due to their small size of several kilobytes. Section 7.2 discusses the implications of these mapped memory locations from a security perspective.

而且，如果KASLR处于激活状态，并且剩余的少量存储位置是随机的，由于这些存储位置的大小仅有几千字节，找到这些存储位置并不是毫无意义的。第7.2节从安全角度讨论了这些映射的内存位置的含义。

 

6.1.3 Microsoft Windows

6.1.3 微软Windows系统

We successfully evaluated Meltdown on an up-to-date Microsoft Windows 10 operating system. In line with the results on Linux (cf. Section 6.1.1), Meltdown also can leak arbitrary kernel memory on Windows. This is not surprising, since Meltdown does not exploit any software issues, but is caused by a hardware issue.

我们成功评估了最新的Microsoft Windows 10操作系统上的熔断漏洞。 根据Linux上的结果（参见6.1.1节），熔断也可以在Windows上泄漏任意内核内存。这并不奇怪，因为熔断不会利用任何软件问题，而是由硬件问题引起的。

In contrast to Linux, Windows does not have the concept of an identity mapping, which linearly maps the physical memory into the virtual address space. Instead, a large fraction of the physical memory is mapped in the paged pools, non-paged pools, and the system cache. Furthermore, Windows maps the kernel into the address space of every application too. Thus, Meltdown can read kernel memory which is mapped in the kernel address space, i.e., any part of the kernel which is not swapped out, and any page mapped in the paged and non-paged pool, and the system cache.

与Linux相比，Windows不具有将物理内存线性映射到虚拟地址空间的身份变换的概念。相反，很大一部分物理内存会映射到分页缓冲池，非分页缓冲池和系统缓存中。此外，Windows也将内核映射到每个应用程序的地址空间。因此，熔断可以读取内核地址空间中映射的内核存储，即任何部分都没有被交换的内核，分页和非分页池中映射的任何页面，以及系统缓存。

 

6.1.4 Containers

6.1.4 容器

We evaluated Meltdown running in containers sharing a kernel, including Docker, LXC, and OpenVZ, and found that the attack can be mounted without any restrictions. Running Meltdown inside a container allows to leak information not only from the underlying kernel, but also from all other containers running on the same physical host.

我们评估了在共享内核容器（包括Docker，LXC和OpenVZ）中运行的熔断漏洞，发现其可以毫无限制地发动攻击。在容器中运行熔断不仅会泄漏来自底层内核的信息，还会泄漏运行在同一物理主机上的所有其他容器的信息。

The commonality of most container solutions is that every container uses the same kernel, i.e., the kernel is shared among all containers. Thus, every container has a valid mapping of the entire physical memory through the direct-physical map of the shared kernel. Furthermore, Meltdown cannot be blocked in containers, as it uses only memory accesses. Especially with Intel TSX, only unprivileged instructions are executed without even trapping into the kernel.

大多数容器解决方案的共同之处在于每个容器使用相同的内核，即内核在所有容器之间共享。因此，通过对共享内核的直接物理映射，每个容器都具有整个物理内存的有效映射。此外，熔断在容器中不会被阻塞，因为它只访问内存。特别是对于Intel TSX，只有无特权的指令才会执行，甚至都不会陷入内核。

Thus, the isolation of containers sharing a kernel can be fully broken using Meltdown. This is especially critical for cheaper hosting providers where users are not separated through fully virtualized machines, but only through containers. We verified that our attack works in such a setup, by successfully leaking memory contents from a container of a different user under our control.

因此，在共享同一个内核的容器间的隔离将被熔断漏洞完全打破。对于便宜的托管服务提供商而言，这一缺陷尤为突出，因为用户不能通过完全虚拟化的机器来隔离，而只能通过容器。在这样的设置下，我们验证了攻击的结果：在刻意控制下，我们成功泄漏了来源于不同用户容器的内存内容。

 

6.2 Meltdown Performance

6.2 熔断的性能

To evaluate the performance of Meltdown, we leaked known values from kernel memory. This allows us to not only determine how fast an attacker can leak memory, but also the error rate, i.e., how many byte errors to expect. We achieved average reading rates of up to 503KB/s with an error rate as low as 0.02% when using exception suppression. For the performance evaluation, we focused on the Intel Core i7-6700K as it supports Intel TSX, to get a fair performance comparison between exception handling and exception suppression.

为了评估熔断的性能，我们将从内核内存泄露已知的值。这使我们不仅可以确定攻击者可以多快地泄漏内存，而且还可以确定错误率，即期望有多少字节的错误。当使用异常抑制的方法时，熔断的平均读取率高达503KB / s，且错误率低至0.02％。有关性能的评估，我们专注于英特尔酷睿i7-6700K，因为它支持英特尔TSX，在异常处理和异常抑制之间将会有公平的性能比较。

 

6.2.1 Exception Handling

6.2.1 异常处理

Exception handling is the more universal implementation, as it does not depend on any CPU extension and can thus be used without any restrictions. The only requirement for exception handling is operating system support to catch segmentation faults and continue operation afterwards. This is the case for all modern operating systems, even though the specific implementation differs between the operating systems. On Linux, we used signals, whereas, on Windows, we relied on the Structured Exception Handler.

异常处理是更通用的实现，因为它不依赖于任何CPU插件，因此可以没有任何限制地使用。异常处理的唯一要求是操作系统支持捕获分段错误并在之后继续操作。所有现代操作系统都是如此，即使它们的具体实现不同。在Linux上，我们使用信号量实现，而在Windows上，我们依靠结构化异常处理程序来实现。

With exception handling, we achieved average reading speeds of 123KB/s when leaking 12MB of kernel memory. Out of the 12MB kernel data, only 0.03%were read incorrectly. Thus, with an error rate of 0.03 %, the channel capacity is 122KB/s.

通过异常处理，当内核内存的泄露总量为12MB时，平均读取速度达到了123KB / s。在12MB内核数据中，读取错误率仅为0.03％。因此，当错误率为0.03％，信道容量为122KB / s。

 

6.2.2 Exception Suppression

6.2.2 异常抑制

Exception suppression can either be achieved using conditional branches or using Intel TSX. Conditional branches are covered in detail in Kocher et al. [19], hence we only evaluate Intel TSX for exception suppression. In contrast to exception handling, Intel TSX does not require operating system support, as it is an instruction-set extension. However, Intel TSX is a rather new extension and is thus only available on recent Intel CPUs, i.e., since the Broadwell microarchitecture.

异常抑制可以使用条件分支或Intel TSX来实现。条件分支实现已经在Kocher 等人的研究中^[19]，因此我们只评估英特尔TSX实现的异常抑制。与异常处理相比，英特尔TSX不需要操作系统支持，因为它是指令集扩展。但是，英特尔TSX是一个相当新的扩展，因此只能在最近的英特尔CPU上使用，也就是自Broadwell微架构以后的版本。

Again, we leaked 12MB of kernel memory to measure the performance. With exception suppression, we achieved average reading speeds of 503KB/s. Moreover, the error rate of 0.02% with exception suppression is even lower than with exception handling. Thus, the channel capacity we achieve with exception suppression is 502KB/s.

再次，我们泄漏了共12MB的内核内存来衡量性能。通过异常抑制，平均读取速度达503KB / s。此外，异常抑制的读取错误率为0.02％，比异常处理的错误率更低。因此，我们通过异常抑制实现的信道容量是502KB / s。

 

6.3 Meltdown in Practice

6.3 熔断的实践

Listing 3 shows a memory dump using Meltdown on an Intel Core i7-6700K running Ubuntu 16.10 with the Linux kernel 4.8.0. In this example, we can identify HTTP headers of a request to a web server running on the machine. The XX cases represent bytes where the side channel did not yield any results, i.e., no Flush+Reload hit. Additional repetitions of the attack may still be able to read these bytes.

清单3显示了在Ubuntu 16.10和Linux内核4.8.0的Intel Core i7-6700K上利用熔断漏洞进行内存转储。在这个例子中，我们可以识别运行在此机器上的Web服务器的HTTP请求头。XX情况代表那些旁路信道没有产生任何结果的字节，即未被Flush+Reload命中。但额外重复的攻击可能依旧能够读取这些字节。

Listing 3: Memory dump showing HTTP Headers on Ubuntu 16.10 on a Intel Core i7-6700K

清单3：在Intel Core i7-6700K的Ubuntu 16.10上的HTTP 头部的内存转储

 

Listing 4 shows a memory dump of Firefox 56 using Meltdown on the same machine. We can clearly identify some of the passwords that are stored in the internal password manager shown in Figure 6, i.e., Dolphin18, insta 0203, and secretpwd0. The attack also recovered a URL which appears to be related to a Firefox addon.

清单4显示了在同一台机器上利用熔断漏洞对Firefox 56的内存转储。我们可以清楚地识别存储在图6所示的内部密码管理器中的一些密码，即Dolphin18，insta 0203和secretpwd0。该攻击还恢复了一个似乎与Firefox插件相关的URL。

 

Listing 4: Memory dump of Firefox 56 on Ubuntu 16.10 on a Intel Core i7-6700K disclosing saved passwords (cf. Figure 6).

清单4：在Intel Core i7-6700K的Ubuntu 16.10上的Firefox 56的内存转储泄露了保存的密码（参见图6）。

Figure 6: Firefox 56 password manager showing the stored passwords that are leaked using Meltdown in Listing 4.

图6：Firefox 56密码管理器，上图的存储密码在清单4中被熔断攻击泄露。

 

6.4 Limitations on ARM and AMD

6.4 6.4 ARM和AMD的限制

We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

我们也尝试在几个ARM和AMD CPU上重现熔断bug。但是，利用第5节中的攻击，我们没能成功地将内核内存泄漏，无论是ARM还是AMD。原因可能是多方面的。首先，可能仅仅是简单的因为我们的实现太慢，更优化的版本可能会成功。例如，一个更粗浅的乱序执行信道可能会转变竞争状态而阻止了数据泄露。类似地，如果处理器缺乏某些特征，例如没有重新排序缓冲器，那么我们当前的实现可能不能泄漏数据。然而，对于ARM和AMD来说，第3节中所描述的玩具例子都是可靠的，这表明乱序执行一般都会发生，并且执行访问非法内存的指令。

 

7 Countermeasures

7 对策

In this section, we discuss countermeasures against the Meltdown attack. At first, as the issue is rooted in the hardware itself, we want to discuss possible microcode updates and general changes in the hardware design.

在本节中，我们将讨论抵御熔断攻击的对策。首先，由于问题根源于硬件本身，所以我们想讨论可能的微码更新和硬件设计中的一般变化。

 

7.1 Hardware

7.1 硬件

Meltdown bypasses the hardware-enforced isolation of security domains. There is no software vulnerability involved in Meltdown. Hence any software patch (e.g., KAISER [8]) will leave small amounts of memory exposed (cf. Section 7.2). There is no documentation whether such a fix requires the development of completely new hardware, or can be fixed using a microcode update.

熔断会绕过硬件强制隔离的安全域且没有软件方面的弱点。因此，任何软件补丁（例如KAISER ^[8]）都会暴露少量的内存（参见7.2节）。没有文档说明这样的修复是否需要开发全新的硬件，或者可以使用微码更新来修复。

As Meltdown exploits out-of-order execution, a trivial countermeasure would be to completely disable out-of-order execution. However, the performance impacts would be devastating, as the parallelism of modern CPUs could not be leveraged anymore. Thus, this is not a viable solution.

由于熔断利用乱序执行，一个几乎无用的对策就是完全禁止乱序执行。然而，这样做带来的性能影响将是毁灭性的，因为现代CPU的并行性不能再被利用。因此这不是一个可行的解决方案。

Meltdown is some form of race condition between the fetch of a memory address and the corresponding permission check for this address. Serializing the permission check and the register fetch can prevent Meltdown, as the memory address is never fetched if the permission check fails. However, this involves a significant overhead to every memory fetch, as the memory fetch has to stall until the permission check is completed.

熔断是获取内存地址和相应的地址权限检查之间的竞争条件的某种形式。序列化权限检查和注册获取可以防止熔毁，因为如果权限检查失败，将永远不会取得内存地址。但是，这对于每次内存读取都会带来很大的开销，因为在完成权限检查之前，必须阻塞内存读取。

A more realistic solution would be to introduce a hard split of user space and kernel space. This could be enabled optionally by modern kernels using a new hard-split bit in a CPU control register, e.g., CR4. If the hard-split bit is set, the kernel has to reside in the upper half of the address space, and the user space has to reside in the lower half of the address space. With this hard split, a memory fetch can immediately identify whether such a fetch of the destination would violate a security boundary, as the privilege level can be directly derived from the virtual address without any further lookups. We expect the performance impacts of such a solution to be minimal. Furthermore, the backwards compatibility is ensured, since the hard-split bit is not set by default and the kernel only sets it if it supports the hard-split feature.

更现实的解决方案是引入用户空间和内核空间的硬分割。这可以通过使用在CPU控制寄存器中启用一个新的硬分割位的现代内核来实现（例如CR4）。如果硬分割位被设置，内核必须保存在地址空间的上半部分，用户空间必须保存在地址空间的下半部分。通过这种硬分割，一次内存读取可以立即识别此次读取的目标是否会违反安全边界，因为特权级别可以直接从虚拟地址派生而无需进一步查找。我们评估这种解决方案对性能的影响是最小的。此外，必须确保向后兼容性，因为硬分割位没有被默认设置，并且内核只在它支持硬分割特征时才能设置它。

Note that these countermeasures only prevent Meltdown, and not the class of Spectre attacks described by Kocher et al. [19]. Likewise, several countermeasures presented by Kocher et al. [19] have no effect on Meltdown. We stress that it is important to deploy countermeasures against both attacks.

请注意，这些对策只能阻止熔断攻击，而不能抵御Kocher等人描述的幽灵攻击^[19]。同样，Kocher等人提出的一些对策^[19]对熔断无效。我们必须强调，对这两种攻击采取防御策略是非常重要的。

 

7.2 KAISER

7.2 KAISER

As hardware is not as easy to patch, there is a need for software workarounds until new hardware can be deployed. Gruss et al. [8] proposed KAISER, a kernel modification to not have the kernel mapped in the user space. This modification was intended to prevent side-channel attacks breaking KASLR [13, 9, 17]. However, it also prevents Meltdown, as it ensures that there is no valid mapping to kernel space or physical memory available in user space. KAISER will be available in the upcoming releases of the Linux kernel under the name kernel page-table isolation (KPTI) [25]. The patch will also be backported to older Linux kernel versions. A similar patch was also introduced in Microsoft Windows 10 Build 17035 [15]. Also, Mac OS X and iOS have similar features [22].

由于硬件不易修补，因此需要软件解决方法直到新版硬件被部署。Gruss等人^[8]提出了KAISER方法，一个内核修改，使得内核不再映射到用户空间。这种修改原是为了防止打破KASLR的旁路攻击^[13][9][17]。但是，它也可以防止熔断，因为它可以确保在用户空间中不会存在内核空间或物理内存的有效映射。 KAISER将搭载在即将发布的Linux内核版本中，并以内核页表隔离（KPTI）^[25]为名。该补丁也将被移植到较旧的Linux内核版本。微软Windows 10 Build 17035^[15]中也引入了类似的补丁程序。另外，Mac OS X和iOS也有类似的特性^[22]。

Although KAISER provides basic protection against Meltdown, it still has some limitations. Due to the design of the x86 architecture, several privileged memory locations are required to be mapped in user space [8]. This leaves a residual attack surface for Meltdown, i.e., these memory locations can still be read from user space. Even though these memory locations do not contain any secrets, such as credentials, they might still contain pointers. Leaking one pointer can be enough to again break KASLR, as the randomization can be calculated from the pointer value.

尽管KAISER提供了针对熔断的基本保护，但它仍然有一些限制。由于x86架构的设计，需要在用户空间映射数个特权内存位置^[8]。这为熔断留下了残留攻击漏洞，即，这些存储位置仍然可以从用户空间读取。即使这些内存位置不包含任何保密值（如凭据），它们仍可能包含指针。泄漏一个指针完全足以再次破坏KASLR，因为可以从指针值计算随机量。

Still, KAISER is the best short-time solution currently available and should therefore be deployed on all systems immediately. Even with Meltdown, KAISER can avoid having any kernel pointers on memory locations that are mapped in the user space which would leak information about the randomized offsets. This would require trampoline locations for every kernel pointer, i.e., the interrupt handler would not call into kernel code directly, but through a trampoline function. The trampoline function must only be mapped in the kernel. It must be randomized with a different offset than the remaining kernel. Consequently, an attacker can only leak pointers to the trampoline code, but not the randomized offsets of the remaining kernel. Such trampoline code is required for every kernel memory that still has to be mapped in user space and contains kernel addresses. This approach is a trade-off between performance and security which has to be assessed in future work.

不过，KAISER仍是目前可用的最佳临时解决方案，因此应立即部署在所有系统上。即使在熔断攻击的情况下，KAISER也可以保证映射在可能泄露有关随机偏移量信息的用户空间上的内存地址上不会持有任何内核指针。这将需要每个内核指针的跳板地址，即中断处理程序不会直接调用内核代码，而是通过跳板访问。跳板功能必须只能在内核中映射。它必须以不同于其余内核的偏移来随机化。因此，攻击者只能泄漏指向跳板代码的指针，而不能泄露剩余内核的随机偏移量。每个内核内存都需要使用这种跳板代码，这些代码仍然需要映射到用户空间并包含内核地址。但这是性能和安全性之间的折衷，必须在未来的工作中持续进行评估。

 

8 Discussion

8 讨论

Meltdown fundamentally changes our perspective on the security of hardware optimizations that manipulate the state of microarchitectural elements. The fact that hardware optimizations can change the state of microarchitectural elements, and thereby imperil secure soft-ware implementations, is known since more than 20 years [20]. Both industry and the scientific community so far accepted this as a necessary evil for efficient computing. Today it is considered a bug when a cryptographic algorithm is not protected against the microarchitectural leakage introduced by the hardware optimizations. Meltdown changes the situation entirely. Meltdown shifts the granularity from a comparably low spatial and temporal granularity, e.g., 64-bytes every few hundred cycles for cache attacks, to an arbitrary granularity, allowing an attacker to read every single bit. This is nothing any (cryptographic) algorithm can protect itself against. KAISER is a short-term software fix, but the problem we uncovered is much more significant.

熔断从根本上改变了我们对直接操纵微架构元件状态的硬件优化的安全性的观点。20多年来，人们都不认为，改变微架构元件状态的硬件优化会危害软件实现的安全性。到目前为止，工业界和科学界都认为这是高效计算所必需的。今天，当一个加密算法不能抵御由硬件优化引入的微体系结构泄漏时，它被认为是一个bug。是熔毁彻底改变了这种状况，它将粒度从相对较低的空间和时间粒度（例如，每隔几百个循环才能有64个字节用于缓存攻击）转换为任意的粒度，从而允许攻击者读取每一个比特。这使得没有什么（加密）算法可以保护并抵御熔毁攻击。KAISER是一个短期的软件修复程序，但我们发现的问题更为重要。

We expect several more performance optimizations in modern CPUs which affect the microarchitectural state in some way, not even necessarily through the cache. Thus, hardware which is designed to provide certain security guarantees, e.g., CPUs running untrusted code, require a redesign to avoid Meltdown- and Spectre-like attacks. Meltdown also shows that even error-free software, which is explicitly written to thwart side-channel attacks, is not secure if the design of the underlying hardware is not taken into account.

我们期望在现代CPU中进行更多的性能优化，以某种方式影响微架构状态，甚至不一定通过缓存。因此，被设计为提供某些安全保证的硬件（例如，运行不可信代码的CPU）需要重新设计以避免类似熔断和类似幽灵的攻击。熔断也向我们展示了，即使是那些为了防止旁路攻击而明确实现并且毫无漏洞的软件，如果它们设计并运行在没有将熔断考虑在内的硬件上，也不是安全的。

With the integration of KAISER into all major operating systems, an important step has already been done to prevent Meltdown. KAISER is also the first step of a paradigm change in operating systems. Instead of always mapping everything into the address space, mapping only the minimally required memory locations appears to be a first step in reducing the attack surface. However, it might not be enough, and an even stronger isolation may be required. In this case, we can trade flexibility for performance and security, by e.g., forcing a certain virtual memory layout for every operating system. As most modern operating system already use basically the same memory layout, this might be a promising approach.

通过将KAISER集成到所有主要操作系统中，抵御熔断攻击已经迈出了重要的一步。KAISER也是操作系统范式改变的第一步。不是总将所有的内容都映射到地址空间，而是只映射最少的所需的内存位置，这似乎是减少攻击面的第一步。但这可能是不够的，可能需要更强的隔离。在这种情况下，我们可以灵活的在性能和安全性之间权衡，例如，为每个操作系统强制一定的虚拟内存布局。由于大多数现代操作系统已经使用基本相同的内存布局，这可能是一个很有前途的方法。

Meltdown also heavily affects cloud providers, especially if the guests are not fully virtualized. For performance reasons, many hosting or cloud providers do not have an abstraction layer for virtual memory. In such environments, which typically use containers, such as Docker or OpenVZ, the kernel is shared among all guests. Thus, the isolation between guests can simply be circumvented with Meltdown, fully exposing the data of all other guests on the same host. For these providers, changing their infrastructure to full virtualization or using software workarounds such as KAISER would both increase the costs significantly.

熔断也严重影响云厂商，特别是如果用户没有完全虚拟化。出于性能原因，许多托管服务或云厂商没有虚拟内存的抽象层。在这种通常使用容器（如Docker或OpenVZ）的环境中，所有用户都共享内核。因此，用户之间的隔离可以简单地通过熔断来破坏，完全暴露同一主机上所有其他用户的数据。对于这些厂商而言，将其基础架构改为完全虚拟化或使用软件解决方案（如KAISER）会显着增加成本。

Even if Meltdown is fixed, Spectre [19] will remain an issue. Spectre [19] and Meltdown need different defenses. Specifically mitigating only one of them will leave the security of the entire system at risk. We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.

即使熔断已经修复，但幽灵^[19]仍然是一个难题。幽灵^[19]和熔断需要不同的防御措施。特别是仅忽视其中一个都会使整个系统的安全性面临风险。我们期望熔断和幽灵开辟一个新的研究领域：性能优化在多大程度上改变了微体系结构状态，这个状态如何转化为体系结构状态，以及如何防止这样的攻击。

 

9 Conclusion

9 总结

In this paper, we presented Meltdown, a novel software-based side-channel attack exploiting out-of-order execution on modern processors to read arbitrary kernel- and physical-memory locations from an unprivileged user space program. Without requiring any software vulnerability and independent of the operating system, Meltdown enables an adversary to read sensitive data of other processes or virtual machines in the cloud with up to 503KB/s, affecting millions of devices. We showed that the countermeasure KAISER [8], originally proposed to protect from side-channel attacks against KASLR, inadvertently impedes Meltdown as well. We stress that KAISER needs to be deployed on every operating system as a short-term workaround, until Meltdown is fixed in hardware, to prevent large-scale exploitation of Meltdown.

在本文中，我们介绍了熔断攻击，这是一种新型的基于软件的旁路攻击，利用现代处理器上的乱序执行从非特权用户空间程序中读取任意内核和物理内存位置。不需要任何软件漏洞，独立于操作系统，熔断使攻击者能够以高达503KB / s的速度读取其他进程或云虚拟机的敏感数据，影响数百万设备。我们发现，KAISER ^[8]，一个最初提出是为了防止对KASLR旁路攻击的对策无意中抵御了熔断攻击。我们强调需要在每个操作系统上安装KAISER补丁，作为一个短期的解决方案，直到熔断漏洞从硬件层面修复，以防止熔断漏洞的大规模利用。

 

Acknowledgment

感言

We would like to thank Anders Fogh for fruitful discussions at BlackHat USA 2016 and BlackHat Europe 2016, which ultimately led to the discovery of Meltdown. Fogh [5] already suspected that it might be possible to abuse speculative execution in order to read kernel memory in user mode but his experiments were not successful. We would also like to thank Jann Horn for comments on an early draft. Jann disclosed the issue to Intel in June. The subsequent activity around the KAISER patch was the reason we started investigating this issue. Furthermore, we would like Intel, ARM, Qualcomm, and Microsoft for feedback on an early draft.

我们要感谢Anders Fogh在2016年的BlackHat USA和2016年的BlackHat 上进行的卓有成效的讨论，最终助力了熔断的发现。Fogh^[5]已经怀疑，为了在用户模式下读取内核内存，推测执行可能会被滥用，但他的实验并不成功。我们还要感谢Jann Horn对早期草案的评论。Jann在六月向英特尔披露了这个问题。随后的KAISER补丁活动是我们开始调查这个问题的原因。此外，我们希望英特尔，ARM，高通和微软就早期草案提供反馈意见。

We would also like to thank Intel for awarding us with a bug bounty for the responsible disclosure process, and their professional handling of this issue through communicating a clear timeline and connecting all involved researchers. Furthermore, we would also thank ARM for their fast response upon disclosing the issue.

我们还要感谢英特尔公司为有效的披露程序给我们奖励的bug赏金，和他们在沟通明确的修复时间期限和联系相关研究人员上的专业处理。此外，我们也要感谢ARM在披露这个问题时作出的快速反应。

This work was supported in part by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 681402).

这项工作得到了欧洲研究理事会（ERC）在欧盟“地平线2020年”研究和创新计划（赠款协议No 681402）下的部分支持。

 

References

引用

[1] BENGER, N., VAN DE POL, J., SMART, N. P., AND YAROM, Y. “Ooh Aah... Just a Little Bit”: A small amount of side channel can go a long way. In CHES’14 (2014).

[2] CHENG, C.-C. The schemes and performances of dynamic branch predictors. Berkeley Wireless Research Center, Tech. Rep (2000).

[3] DEVIES, A. M. AMD Takes Computing to a New Horizon with RyzenTMProcessors, 2016.

[4] EDGE, J. Kernel address space layout randomization, 2013.

[5] FOGH, A. Negative Result: Reading Kernel Memory From User Mode, 2017.

[6] GRAS, B., RAZAVI, K., BOSMAN, E., BOS, H., AND GIUFFRIDA, C. ASLR on the Line: Practical Cache Attacks on the MMU. In NDSS (2017).

[7] GRUSS, D., LETTNER, J., SCHUSTER, F., OHRIMENKO, O., HALLER, I., AND COSTA, M. Strong and Efficient Cache Side- Channel Protection using Hardware Transactional Memory. In USENIX Security Symposium (2017).

[8] GRUSS, D., LIPP, M., SCHWARZ, M., FELLNER, R., MAURICE, C., AND MANGARD, S. KASLR is Dead: Long Live KASLR. In International Symposium on Engineering Secure Software and Systems (2017), Springer, pp. 161–176.

[9] GRUSS, D., MAURICE, C., FOGH, A., LIPP, M., AND MANGARD, S. Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR. In CCS (2016).

[10] GRUSS, D., MAURICE, C., WAGNER, K., AND MANGARD, S. Flush+Flush: A Fast and Stealthy Cache Attack. In DIMVA (2016).

[11] GRUSS, D., SPREITZER, R., AND MANGARD, S. Cache Template Attacks: Automating Attacks on Inclusive Last-Level Caches. In USENIX Security Symposium (2015).

[12] HENNESSY, J. L., AND PATTERSON, D. A. Computer architecture: a quantitative approach. Elsevier, 2011.

[13] HUND, R., WILLEMS, C., AND HOLZ, T. Practical Timing Side Channel Attacks against Kernel Space ASLR. In S&P (2013).

[14] INTEL. Intel R 64 and IA-32 Architectures Optimization Reference Manual, 2014.

[15] IONESCU, A. Windows 17035 Kernel ASLR/VA Isolation In Practice (like Linux KAISER)., 2017.

[16] IRAZOQUI, G., INCI, M. S., EISENBARTH, T., AND SUNAR, B. Wait a minute! A fast, Cross-VM attack on AES. In RAID’14 (2014).

[17] JANG, Y., LEE, S., AND KIM, T. Breaking Kernel Address Space Layout Randomization with Intel TSX. In CCS (2016).

[18] JIM´E NEZ, D. A., AND LIN, C. Dynamic branch prediction with perceptrons. In High-Performance Computer Architecture, 2001. HPCA. The Seventh International Symposium on (2001), IEEE, pp. 197–206.

[19] KOCHER, P., GENKIN, D., GRUSS, D., HAAS, W., HAMBURG, M., LIPP, M., MANGARD, S., PRESCHER, T., SCHWARZ, M., AND YAROM, Y. Spectre Attacks: Exploiting Speculative Execution.

[20] KOCHER, P. C. Timing Attacks on Implementations of Diffe-Hellman, RSA, DSS, and Other Systems. In CRYPTO (1996).

[21] LEE, B., MALISHEVSKY, A., BECK, D., SCHMID, A., AND LANDRY, E. Dynamic branch prediction. Oregon State University.

[22] LEVIN, J. Mac OS X and IOS Internals: To the Apple’s Core. John Wiley & Sons, 2012.

[23] LIPP, M., GRUSS, D., SPREITZER, R., MAURICE, C., AND MANGARD, S. ARMageddon: Cache Attacks on Mobile Devices. In USENIX Security Symposium (2016).

[24] LIU, F., YAROM, Y., GE, Q., HEISER, G., AND LEE, R. B. Last-Level Cache Side-Channel Attacks are Practical. In IEEE Symposium on Security and Privacy – SP (2015), IEEE Computer Society, pp. 605–622.

[25] LWN. The current state of kernel page-table isolation, Dec. 2017.

[26] MAURICE, C., WEBER, M., SCHWARZ, M., GINER, L., GRUSS, D., ALBERTO BOANO, C., MANGARD, S., AND R¨OMER, K. Hello from the Other Side: SSH over Robust Cache Covert Channels in the Cloud. In NDSS (2017).

[27] MOLNAR, I. x86: Enable KASLR by default, 2017. [28] OSVIK, D. A., SHAMIR, A., AND TROMER, E. Cache Attacks and Countermeasures: the Case of AES. In CT-RSA (2006).

[29] PERCIVAL, C. Cache missing for fun and profit. In Proceedings of BSDCan (2005).

[30] PHORONIX. Linux 4.12 To Enable KASLR By Default, 2017.

[31] SCHWARZ, M., LIPP, M., GRUSS, D., WEISER, S., MAURICE, C., SPREITZER, R., AND MANGARD, S. KeyDrown: Eliminating Software-Based Keystroke Timing Side-Channel Attacks. In NDSS’18 (2018).

[32] TERAN, E., WANG, Z., AND JIM´ENEZ, D. A. Perceptron learning for reuse prediction. In Microarchitecture (MICRO), 2016 49th Annual IEEE/ACM International Symposium on (2016), IEEE, pp. 1–12.

[33] TOMASULO, R. M. An efficient algorithm for exploiting multiple arithmetic units. IBM Journal of research and Development 11, 1 (1967), 25–33.

[34] VINTAN, L. N., AND IRIDON, M. Towards a high performance neural branch predictor. In Neural Networks, 1999. IJCNN’99. International Joint Conference on (1999), vol. 2, IEEE, pp. 868– 873.

[35] YAROM, Y., AND FALKNER, K. Flush+Reload: a High Resolution, Low Noise, L3 Cache Side-Channel Attack. In USENIX Security Symposium (2014).

[36] YEH, T.-Y., AND PATT, Y. N. Two-level adaptive training branch prediction. In Proceedings of the 24th annual international symposium on Microarchitecture (1991), ACM, pp. 51–61.

[37] ZHANG, Y., JUELS, A., REITER, M. K., AND RISTENPART, T. Cross-Tenant Side-Channel Attacks in PaaS Clouds. In CCS’14 (2014).