歡迎光臨
每天分享高質量文章

宇宙最強,meltdown論文中英文對照版(三)


本文由郭健郭大俠翻譯,將分為三次連載完成,這是第三部分。郭大俠是蝸窩科技(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的影響以及我們POCproof-of-concept)實現的性能。6.1節討論了meltdown可能泄漏的信息,6.2節評估了meltdown的性能和對策。最後在6.4節中,我們討論了在AMDARM處理器上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 CloudDigitalOcean的虛擬機,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)。

1Linux

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.324.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節)。攻擊者也可以通過遍歷虛擬地址空間的方法來找到物理記憶體直接映射的信息。沒有KASLRLinux內核會在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節從安全的角度討論了映射這一小段記憶體的含義。

3Windows

沒有興趣瞭解,略過。

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,包括DockerLXC,和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的確是起作用的,我們可以成功地從其他用戶容器中盜取記憶體信息。

2meltdown性能

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%。因此信道容量是122kBs

2)異常抑制

Intel處理器相關,忽略之。

3Meltdown實戰

這個小節展示了幾個具體的meltdown攻擊效果,忽略之。

4AMDARM處理器上的限制

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.

我們還試圖在幾款ARMAMD CPU上重現meltdown漏洞。然而無論是在ARM上還是在AMD處理器上,我們都沒有成功地使用第5章中描述的攻擊方法來盜取到內核記憶體。造成這種情況的原因是多方面的。首先,我們的實現可能太慢,一個更優化的版本可能會成功。例如,一個更淺的亂序執行流水線可能會讓資料泄漏變得更困難一些。類似地,如果處理器缺少某些特性,例如沒有重新排序緩衝區(re-order buffer),那麼我們當前的代碼實現可能根據無法造成泄漏資料。不過,對於ARMAMD處理器來說,第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也沒有效果。我們這裡再次強調一下:針對這兩種攻擊部署相關的對策是非常重要的。

2KAISER

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內核中,名字改成了KPTIkernel page-table isolation[ 25 ],同時該補丁也將移植到舊的Linux內核版本。微軟Windows 10也提供了類似的補丁[ 15 ]。另外,Mac OS XiOS也有類似的功能[ 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 ]。但是到目前為止,工業界和科學界都認為這是高效計算所必需面對的一個問題,你不得不接受它。現在,當一個加密演算法不能保護微架構狀態的泄露(由於硬體優化而引入),我們認為這是一個軟體bugMeltdown徹底改變了現狀。原來的攻擊在空間和時間粒度上是相對較小,例如,快取攻擊的空間粒度是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設計者就需要重新設計以避免meltdownspectre的攻擊。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也嚴重影響了雲服務提供商,特別是在客戶機沒有完全虛擬化的場景中。出於性能方面的原因,許多雲服務提供商沒有虛擬記憶體的抽象層。在這樣的環境中(通常是使用容器,如DockerOpenVZ),內核在所有的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]仍然是一個問題。Spectremeltdown需要不同的防禦策略。只是解決其中一個並不能解決整個系統的安全問題。我們期待meltdownspectre可以打開一個新的研究領域,讓大家一起探討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漏洞,普通用戶空間程式可以以503KBs的速度讀其他行程或虛擬機的敏感資料,這影響了數以百萬計的設備。我們發現針對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 FoghBlackHat USA 2016BlackHat Europe 2016上富有成果的討論,這些討論最終導致meltdown的發現。Anders Fogh [5 ]已經懷疑利用推測執行可以在用戶樣式下讀取內核資料,但他的實驗並不成功。我們也要感謝Jann Horn對早期草稿的意見。Jann Horn6月份向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

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).

赞(0)

分享創造快樂