知識星球
前文：
六、評估（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 of Meltdown. 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).
