本文由郭健郭大侠翻译，将分为三次连载完成，这是第三部分。郭大侠是蜗窝科技（http://www.wowotech.net/）的创始人，倡导"慢下来，享受技术"的健康理念，侠之大者，为国为民。

前文：

宇宙最强，meltdown论文中英文对照版(一)

宇宙最强，meltdown论文中英文对照版(二)

六、评估（Evaluation）

In this section, we evaluate Meltdown and the performance of ourproof-of-concept implementation 2. Section 6.1 discusses the information whichMeltdown can leak, and Section 6.2 evaluates the performance of Meltdown, includingcountermeasures. Finally, we discuss limitations for AMD and ARM in Section6.4.

在本章中，我们将评估meltdown的影响以及我们POC（proof-of-concept）实现的性能。6.1节讨论了meltdown可能泄漏的信息，6.2节评估了meltdown的性能和对策。最后在6.4节中，我们讨论了在AMD和ARM处理器上meltdown的局限性。

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

在上面列表显示的系统中，我们都成功地利用meltdown漏洞进行了攻击。我们在使用英特尔CPU的笔记本电脑和台式机上进行了meltdown的评估。对于云服务器，我们测试Amazon Elastic Compute Cloud和DigitalOcean的虚拟机，CPU是英特尔的Xeon处理器。出于道德的原因，我们没有使用meltdown去获取真实用户物理内存地址上的数据。

1、各种环境下的信息泄露（Information Leakage and Environments）

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

我们在Linux（参见第6.1.1）和Windows 10（参见第6.1.3）这两个操作系统上评估了meltdown漏洞，结果表明它们都可以成功地泄漏内核信息。此外，我们还测试了KAISER补丁在Linux上的效果，结果表明KAISER补丁可以防止内核信息泄漏（参见第6.1.2）。最后，我们讨论了在容器环境下（例如Docker）的信息泄漏（参见第6.1.4）。

（1）Linux

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

我们成功地对多个版本的Linux内核（从2.6.32到4.13.0）进行了Meltdown评估。在Linux内核的所有这些版本中，内核地址空间都映射到了用户进程地址空间中。但由于权限设置，任何来自用户空间的内核数据访问都被阻止。Meltdown可以绕过这些权限设置，并且只要攻击者知道内核虚拟地址，都可以发起攻击，从而泄露内核数据。由于所有主要操作系统都将整个物理内存映射到内核地址空间（参见第2.2节），因此利用meltdown漏洞可以读取所有物理内存的数据。

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

在4.12内核之前，内核地址空间布局随机化（KASLR）不是默认启用的^{[ 30 ]}。如果启动KASLR这个特性，meltdown仍然可以用来找到内核的映射位置（这是通过搜索地址空间的方法，具体参见5.2节）。攻击者也可以通过遍历虚拟地址空间的方法来找到物理内存直接映射的信息。没有KASLR，Linux内核会在0xffff 8800 0000 0000开始的线性地址区域内映射整个物理内存。在这样的系统中，攻击者可以用meltdown轻松dump整个物理内存，因为攻击者已经清楚的知道物理内存的虚拟地址是从0xffff 8800 0000 0000开始的。

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

在新的linux系统中，KASLR是默认启动的，因此物理内存的虚拟地址并非从0xffff 8800 0000 0000开始，而是需要累加一个40-bit的随机偏移。由于物理内存的映射是线性的，KASLR阻挡meltdown攻击的效果进一步受到限制。假设目标系统有8GB内存，攻击者可以按照8 GB的步长来破解40-bit的随机偏移，最多128次尝试就可以推出这个随机偏移。一旦攻破了随机偏移值，攻击者可以再次dump整个物理内存。

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

因此，在本节的meltdown评估中，我们可以假设KASLR是禁用的，或者随机偏移量已经在预先计算出来了。

（2）打了KAISER补丁的Linux系统（Linux with KAISER patch）

The KAISER patch by Gruss et al. [8] implements a stronger isolationbetween kernel and user space.

KAISER does not map any kernel memory in the user space, except for someparts required by the x86 architecture (e.g., interrupt handlers). Thus, thereis no valid mapping to either kernel memory or physical memory (via thedirect-physical map) in the user space, and such addresses can therefore not beresolved. Consequently, Meltdown cannot leak any kernel or physical memory exceptfor the few memory locations which have to be mapped in user space.

Gruss发布的KAISER补丁^{[ 8 ]}实现了内核和用户空间之间更强的隔离。KAISER根本不把内核地址空间映射到用户进程空间中去。除了x86架构所需的某些部分代码之外（如中断处理程序），在用户空间中根本看不到物理内存的直接映射，也看不到内核地址空间的任何信息。没有有效的映射，因此用户空间根本不能解析这些地址。因此，除了少数必须在用户空间中映射的物理内存或者内核地址外，meltdown不能泄漏任何数据。

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

我们验证了KAISER确实解决了meltdown漏洞，没有任何内核或物理内存数据的泄漏。

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

此外，如果启用了KASLR，虽然有部分内核地址空间的映射是用户态可见的，但是这些内核地址的位置是随机的，而且由于这段内存区域只有几KB，发现这些内存位置不是一件简单的事情。7.2节从安全的角度讨论了映射这一小段内存的含义。

（3）Windows

没有兴趣了解，略过。

（4）容器

We evaluated Meltdown running in containers sharing a kernel, includingDocker, LXC, and OpenVZ, and found that the attack can be mounted without anyrestrictions. Running Meltdown inside a container allows to leak information notonly from the underlying kernel, but also from all other containers running onthe same physical host.

我们评估了容器环境下（共享一个内核）的meltdown，包括Docker，LXC，和OpenVZ，结果发现meltdown可以没有任何限制发起攻击。在容器中运行执行meltdown攻击不仅可以泄漏底层内核信息，还可以泄漏同一物理主机上其他容器上的信息。

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

大多数容器解决方案都是使用相同的内核，即内核是在所有容器中共享的。因此，每个容器中都有对整个物理内存的直接映射。由于只涉及内存访问，在容器中并不能阻止meltdown攻击。特别是在使用英特尔TSX特性的情况下，攻击根本不需要陷入内核执行，只有非特权指令的执行。

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

因此，共享内核的容器隔离可以轻松地被meltdown攻破。对于那些提供廉价主机托管服务的提供商来说，这个问题更严重，因为在那种情况下，用户不能通过完全虚拟化的物理机器进行隔离，而只能通过容器进行隔离。我们验证了在这样的环境中，meltdown的确是起作用的，我们可以成功地从其他用户容器中盗取内存信息。

2、meltdown性能

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

为了评估meltdown的性能，我们事先在准备攻击的内核内存中设定了指定的数值。这使我们不仅能够确定攻击者盗取内存数据的速度，而且还可以确定错误率（即有多少字节的错误）。在使用异常抑制（需要TSX支持）的情况下，我们实现了503kB / s的数据泄露速度，而错误率低于0.02%。对于性能评估，我们集中在英特尔的Core i7-6700k处理器，因为它支持TSX。这样我们可以在一个公平环境中（同一个CPU）比较异常处理和异常抑制两种方法下meltdown的性能。

For all tests, we use Flush+Reload as a covert channel to leak the memoryas described in Section 5. We evaluated the performance of both exceptionhandling and exception suppression (cf. Section 4.1). For exception handling, weused signal handlers, and if the CPU supported it, we also used exceptionsuppression using Intel TSX. An extensive evaluation of exception suppressionusing conditional branches was done by Kocher et al. [19] and is thus omittedin this paper for the sake of brevity.

对于所有的测试，我们使用Flush+Reload作为一个隐蔽通道来泄漏内存信息，具体可以参考第5章的描述。我们评估了异常处理和异常抑制这两种方法下meltdown的性能（参见第4.1节）。对于异常处理，我们设置信号处理函数。如果CPU支持，我们也可以利用英特尔TSX来完成异常抑制。使用条件分支来完成异常抑制的评估是由Kocher等人完成的^{[ 19 ]}。为了简洁起见，本文省略了这部分的内容。

（1）异常处理

Exception handling is the more universal implementation, as it does notdepend on any CPU extension and can thus be used without any restrictions. Theonly requirement for exception handling is operating system support to catchsegmentation faults and continue operation afterwards. This is the case for allmodern operating systems, even though the specific implementation differsbetween the operating systems. On Linux, we used signals, whereas, on Windows,we relied on the Structured Exception Handler.

异常处理的方法更通用一些，因为它不依赖于任何CPU扩展特性，从而可以不受任何限制地在各种处理器上使用。异常处理的唯一要求是操作系统支持捕捉segmentation fault并继续操作。基本上所有现代操作系统都支持这个特性，不过具体的实现会有所不同。在Linux上，我们使用信号，而在Windows上，我们依赖Structured Exception Handler。

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

在使用异常处理的情况下，我们实现了以123kB / s的平均速度完成了12MB内核数据的泄漏。在12MB的内核数据中，错误率只有0.03%。因此信道容量是122kB／s。

（2）异常抑制

和Intel处理器相关，忽略之。

3、Meltdown实战

这个小节展示了几个具体的meltdown攻击效果，忽略之。

4、AMD和ARM处理器上的限制

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 attackdescribed in Section 5, neither on ARM nor on AMD. The reasons for this can bemanifold. First of all, our implementation might simply be too slow and a moreoptimized version might succeed. For instance, a more shallow out-of-orderexecution pipeline could tip the race condition towards against the dataleakage. 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 bothARM and AMD, the toy example as described in Section 3 works reliably,indicating that out-of-order execution generally occurs and instructions pastillegal memory accesses are also performed.

我们还试图在几款ARM和AMD CPU上重现meltdown漏洞。然而无论是在ARM上还是在AMD处理器上，我们都没有成功地使用第5章中描述的攻击方法来盗取到内核内存。造成这种情况的原因是多方面的。首先，我们的实现可能太慢，一个更优化的版本可能会成功。例如，一个更浅的乱序执行流水线可能会让数据泄漏变得更困难一些。类似地，如果处理器缺少某些特性，例如没有重新排序缓冲区（re-order buffer），那么我们当前的代码实现可能根据无法造成泄漏数据。不过，对于ARM和AMD处理器来说，第3章中描述的简单示例仍然可以可靠的工作，这表明在那些CPU上也发生了乱序执行，即非法内存访问的指令之后的指令也提前被执行。

七、对策

In this section, we discuss countermeasures against the Meltdown attack.At first, as the issue is rooted in the hardware itself, we want to discusspossible microcode updates and general changes in the hardware design. Second,we want to discuss the KAISER countermeasure that has been developed tomitigate side-channel attacks against KASLR which inadvertently also protectsagainst Meltdown.

在这一章中，我们讨论了如何应对meltdown攻击。由于这个issue本身是源于硬件设计，因此我们首先讨论如何通过更新硬件设计来修复这个漏洞。其次，我们讨论如何用KAISER来减轻meltdown，虽然KAISER最初的设计是为了防止KASLR侧信道攻击的。

1、硬件策略

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

Meltdown并不涉及软件漏洞，它是直接绕过硬件隔离机制。因此，任何软件补丁（例如，KAISER^[8]）都会暴露出少量的内存区域（参见第7.2节）。是否需要开发全新的硬件或使用微码更新来修复meltdown，没有文件说明这一点。

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

由于meltdown利用了乱序执行，一个简单的对策就是完全禁用乱序执行。不过这对性能的影响将是毁灭性的，因为我们将无法再利用现代CPU的并行性了。因此，这个解决方案不可行。

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

Meltdown是“获取内存地址数据”和“权限检查”之间的一种竞态条件（race condition）。严格在获取地址数据之前进行权限检查可以防止meltdown，即在不能通过权限检查时候，CPU根本没有办法把受保护的内存数据加载到寄存器。然而，这给每一个内存访问增加了很大的开销，因为在完成权限检查之前，内存访问的动作只能stall。

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

一个更现实的解决方案是从硬件层面区分用户空间和内核空间。这可以通过CPU寄存器（例如cr4）的一个bit（称之hard-split bit）来开启。如果该bit设置为1，则内核地址必须在地址空间的上半部分，而用户空间必须位于地址空间的下半部分。有了这种硬件机制，违反权限的内存读取可以被立刻识别，这是因为所需特权级别可以直接从虚拟地址推导出来而不需要任何进一步的查找。我们认为这种解决方案对性能的影响是最小的。此外，向后兼容性也得到保证，因为默认情况下我们不设置hard-split bit，而内核仅在硬件支持的时候才设置它。

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

请注意，这些对策只能防止meltdown，对Kocher等人发现的幽灵攻击无效^{[ 19 ]}。同样，由Kocher等人提出的解决spectre漏洞^{[ 19 ]}的对策，对meltdown也没有效果。我们这里再次强调一下：针对这两种攻击部署相关的对策是非常重要的。

2、KAISER

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

硬件修复漏洞没有那么快，因此我们还是要到在新的硬件可以部署之前，提供软件绕过的方案。Gruss等人^{[ 8 ]}建议了KAISER方案，该方案对内核进行修改，以便在用户进程地址空间中根本看不到内核地址的映射。这个补丁是为了防止侧信道攻击方法攻破KASLR ^{[ 13, 9, 17 ]}。然而，因为它确保了在用户空间没有有效的内核空间映射或物理内存映射，因此KAISER也能解决meltdown问题。KAISER将会出现在即将发布的Linux内核中，名字改成了KPTI（kernel page-table isolation）^{[ 25 ]}，同时该补丁也将移植到旧的Linux内核版本。微软Windows 10也提供了类似的补丁^{[ 15 ]}。另外，Mac OS X和iOS也有类似的功能^{[ 22 ]}。

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

虽然KAISER提供了基本的保护以防止meltdown，但它仍然有一些局限性。由于x86架构的设计，需要在用户空间中映射一小段内核地址空间^{[ 8 ]}，因此这些内存位置仍然可以从用户空间读取，这为meltdown攻击留下伏笔。即使这些内存位置不包含任何机密数据，它们仍然可能包含指针。其实一个指针的数据就足够攻破KASLR，因为随机偏移可以根据指针的值推导出来。

Still, KAISER is the best short-time solution currently available andshould therefore be deployed on all systems immediately. Even with Meltdown,KAISER can avoid having any kernel pointers on memory locations that are mappedin 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 callinto kernel code directly, but through a trampoline function. The trampoline functionmust only be mapped in the kernel. It must be randomized with a differentoffset than the remaining kernel. Consequently, an attacker can only leakpointers to the trampoline code, but not the randomized offsets of theremaining kernel. Such trampoline code is required for every kernel memory thatstill has to be mapped in user space and contains kernel addresses. Thisapproach is a trade-off between performance and security which has to beassessed in future work.

不过，KAISER仍然是目前最好的短期解决方案，并且应该立即部署到所有系统上。即便是CPU存在meltdown漏洞，KAISER补丁避免了在用户空间映射的内存位置上保存内核的指针，这样可以避免泄露随机偏移的信息。为了达到这个目标，我们需要为每一个内核指针建立trampoline code，例如：中断处理程序不会直接调用内核代码，而是通过trampoline函数。trampoline函数只会映射到内核空间，但是和其余部分的内核应该在不同的随机偏移上。因此，攻击者只能获取trampoline code的内核地址，而不能破解剩余内核的随机偏移。每一个进程地址空间仍然映射了trampoline code这段内存，而这段内存中也包括了内核的地址，存在一定的风险，但是这种方法是性能和安全性之间进行平衡，也是我们必须在今后的工作进一步研究的课题。

八、讨论

Meltdown fundamentally changes our perspective on the security of hardwareoptimizations that manipulate the state of microarchitectural elements. Thefact that hardware optimizations can change the state of microarchitectural elements,and thereby imperil secure soft-ware implementations, is known since more than20 years [20]. Both industry and the scientific community so far accepted thisas a necessary evil for efficient computing. Today it is considered a bug whena cryptographic algorithm is not protected against the microarchitectural leakageintroduced by the hardware optimizations. Meltdown changes the situationentirely. Meltdown shifts the granularity from a comparably low spatial andtemporal 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 moresignificant.

通过调整CPU微架构状态，CPU设计者可以优化硬件的性能，由此引入的安全问题并没有引起足够的重视，Meltdown从根本上改变了这一点，即CPU设计者必须直面安全问题。20多年以来，CPU设计者很清楚的知道这样一个事实：硬件优化可以改变CPU微架构的状态，从而给安全软件的实现带来风险^{[ 20 ]}。但是到目前为止，工业界和科学界都认为这是高效计算所必需面对的一个问题，你不得不接受它。现在，当一个加密算法不能保护微架构状态的泄露（由于硬件优化而引入），我们认为这是一个软件bug。Meltdown彻底改变了现状。原来的攻击在空间和时间粒度上是相对较小，例如，缓存攻击的空间粒度是64个字节，时间粒度是大概几百个周期。有了meltdown，空间和时间粒度可以任意指定，允许攻击者读取每一个比特位，这不是什么（加密）算法可以保护了的。KAISER是一个短期的软件解决方案，但我们揭示的问题更为重要（即不能为了性能而忽略安全性）。

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

我们期待更多的性能优化出现在现代CPU上，这些优化可能以某种方式影响微架构的状态（未必一定是影响缓存状态，可能是其他的CPU微架构单元）。不过只要CPU硬件的设计需求中包含了安全性，那么CPU设计者就需要重新设计以避免meltdown和spectre的攻击。Meltdown还表明：即便是软件没有bug，而且也小心的设计以避免侧信道攻击，如果不仔细思考底层硬件的安全性，那么它也是不安全的。

With the integration of KAISER into all major operating systems, animportant step has already been done to prevent Meltdown. KAISER is also thefirst step of a paradigm change in operating systems. Instead of always mappingeverything into the address space, mapping only the minimally required memorylocations 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 thiscase, we can trade flexibility for performance and security, by e.g., forcing acertain virtual memory layout for every operating system. As most modernoperating system already use basically the same memory layout, this might be apromising approach.

随着KAISER集成到目前所有的主流操作系统中，我们在防止meltdown上已经迈出了重要的一步。KAISER也改变了操作系统中地址映射的设计思路。原来我们总是将所有地址（包括内核和用户）映射到整个进程地址空间，现在，在用户态执行的时候只是映射必要的地址空间。这的确是减少攻击范围。然而，这可能是不够的，我们可能需要更强烈的隔离。在这种情况下，我们需要在性能和安全性上进行平衡，例如，强制每个操作系统符合特定的虚拟内存布局。由于大多数现代操作系统使用了基本相同的内存布局，这可能是一种很有前途的方法。

Meltdown also heavily affects cloud providers, especially if the guestsare not fully virtualized. For performance reasons, many hosting or cloudproviders do not have an abstraction layer for virtual memory. In suchenvironments, which typically use containers, such as Docker or OpenVZ, thekernel is shared among all guests. Thus, the isolation between guests cansimply be circumvented with Meltdown, fully exposing the data of all otherguests on the same host. For these providers, changing their infrastructure tofull virtualization or using software workarounds such as KAISER would both increasethe costs significantly.

Meltdown也严重影响了云服务提供商，特别是在客户机没有完全虚拟化的场景中。出于性能方面的原因，许多云服务提供商没有虚拟内存的抽象层。在这样的环境中（通常是使用容器，如Docker或OpenVZ），内核在所有的guest os中共享。因此，虽然存在guest os之间的隔离，但是我们可以利用Meltdown，将其他guest os的数据（在同一个主机）暴露出来。对于这些供应商，改变他们的基础设施，变成全虚拟化或使用软件解决方法（如KAISER）都会增加成本。

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

即使meltdown被修复了，spectre^{[ 19]}仍然是一个问题。Spectre和meltdown需要不同的防御策略。只是解决其中一个并不能解决整个系统的安全问题。我们期待meltdown和spectre可以打开一个新的研究领域，让大家一起探讨CPU设计的相关问题，包括改变微架构的状态如何可以优化CPU性能，微架构状态如何转化为CPU体系结构状态，以及如何阻止这样的攻击。

九、结论

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

在本文中，我们描述了一个新型的CPU漏洞meltdown，一种利用现代处理器上的乱序执行特性，通过侧信道攻击读取任意内核地址和物理内存数据的方法。不需要利用软件漏洞，也和具体操作系统无关，利用Meltdown漏洞，普通用户空间程序可以以503KB／s的速度读其他进程或虚拟机的敏感数据，这影响了数以百万计的设备。我们发现针对meltdown的对策是KAISER ^{[ 8 ]}，KAISER最初是为了防止侧信道攻击KASLR而引入的，但是无意中也可以防止meltdown漏洞。我们建议：一个短期的解决办法是在每一个操作系统上都部署KAISER，直到解决meltdown issue的硬件出现。

十、致谢

We would like to thank Anders Fogh for fruitful discussions at BlackHatUSA 2016 and BlackHat Europe 2016, which ultimately led to the discovery ofMeltdown. Fogh [5] already suspected that it might be possible to abusespeculative execution in order to read kernel memory in user mode but hisexperiments were not successful. We would also like to thank Jann Horn forcomments on an early draft. Jann disclosed the issue to Intel in June. Thesubsequent activity around the KAISER patch was the reason we startedinvestigating this issue. Furthermore, we would like Intel, ARM, Qualcomm, and Microsoftfor feedback on an early draft.

我们感谢Anders Fogh在BlackHat USA 2016和BlackHat Europe 2016上富有成果的讨论，这些讨论最终导致meltdown的发现。Anders Fogh ^{[5 ]}已经怀疑利用推测执行可以在用户模式下读取内核数据，但他的实验并不成功。我们也要感谢Jann Horn对早期草稿的意见。Jann Horn在6月份向Intel透漏了这个问题。随后围绕KAISER补丁的后续活动也使得我们开始调查这个问题。此外，我们也欣赏英特尔、ARM、高通和微软在早期草案阶段给予的反馈。

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

我们也要感谢英特尔公司，在发现meltdown漏洞之后对我们进行了奖励，并且负责的披露整个过程，感谢他们专业的处理了这个问题（给出一个明确的时间表进行充分沟通，并联系了所有相关的研究人员）。此外，我们还感谢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）根据欧盟Horizon 2020科研创新计划（编号：681402）对本项工作有一定的支持。

参考文献：

[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 performancesof dynamic

branch predictors. Berkeley Wireless Research Center, Tech. Rep

(2000).

[3] DEVIES, A. M. AMD Takes Computing to a NewHorizon with

RyzenTMProcessors, 2016.

[4] EDGE, J. Kernel address space layoutrandomization, 2013.

[5] FOGH, A. Negative Result: Reading KernelMemory 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 InternationalSymposium 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. IntelR 64 and IA-32 ArchitecturesOptimization Reference

Manual, 2014.

[15] IONESCU, A. Windows 17035 Kernel ASLR/VAIsolation 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: ExploitingSpeculative Execution.

[20] KOCHER, P. C. Timing Attacks onImplementations 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 theApple’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 USENIXSecurity 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: SSHover 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 ByDefault, 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 forexploiting 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).