面向云平臺非可信Hypervisor的保護機制綜述*

顧佳男，鄭蓓蕾，翁楚良

華東師范大學 數(shù)據(jù)科學與工程學院，上海 200062

1 引言

近年來，隨著人工智能、物聯(lián)網(wǎng)等新興領域的成熟，以及多核/眾核、GPGPU（general-purpose computing on graphics processing units）、NVM（non-volatile memory）存儲介質(zhì)、RDMA（remote direct memory access）等新型硬件的發(fā)展，多租戶云平臺的作用也在這個大數(shù)據(jù)時代展現(xiàn)得淋漓盡致。多租戶云平臺針對用戶的服務由原先的應用托管、內(nèi)容交付、電子商務、網(wǎng)絡托管等，加入了海量數(shù)據(jù)存儲、計算等重要的大數(shù)據(jù)應用場景。以虛擬化技術為基礎搭建的多租戶云平臺，例如亞馬遜的EC2[1]、微軟的Azure[2]，相比于自主構建的純硬件環(huán)境，在計算資源和存儲資源的廉價性、實用性以及擴展性等方面有著諸多的優(yōu)勢。這些優(yōu)勢使得各類多租戶云平臺在越來越多的大數(shù)據(jù)應用領域顯得有競爭力。如果將數(shù)據(jù)比喻成當今互聯(lián)網(wǎng)行業(yè)的一個重要能源，那么云平臺就是驅動這個能源的重要發(fā)動機之一。

Hypervisor是虛擬化技術中最重要的軟件層次，也是多租戶云平臺底層能夠有效和安全地驅動數(shù)據(jù)能源的關鍵組件之一。在系統(tǒng)虛擬化技術中，Hypervisor扮演著為客戶虛擬機映射真實物理資源的角色，同時它也需要為不同客戶虛擬機之間的物理資源實現(xiàn)共享和隔離。因此，Hypervisor的功能與效率直接決定系統(tǒng)虛擬化技術的功能與效率，它的安全和可靠更是虛擬化技術的基礎?，F(xiàn)有很多工作[3-19]就是基于可信Hypervisor來構建針對客戶虛擬機的保護機制，以保證其內(nèi)核和上層應用的安全。

但是，和操作系統(tǒng)內(nèi)核一樣，Hypervisor也面臨著來自漏洞和惡意攻擊的威脅。一個完整的Hypervisor就如同操作系統(tǒng)內(nèi)核一般，其代碼量也是很龐大的。例如一切以精簡出發(fā)設計的開源虛擬化技術Xen[20]，其4.8版本的Hypervisor也由 近30萬行的代碼構成，更不用說代碼量更龐大的KVM（kernel-based virtual machine）[21]、VMware[22]等其他虛擬化技術。另外，NVD（National Vulnerability Database）[23]數(shù)據(jù)庫中存有很多針對Xen、KVM和VMware等虛擬化技術的漏洞報告，而文獻[24-25]也全面綜述了Hypervisor中存在的安全問題。因此，Hypervisor的龐大攻擊面以及其在虛擬化技術中的核心地位，使得任意可行的攻擊[26-28]對整個多租戶云平臺的安全造成極大的威脅。

綜上所述，設計和實現(xiàn)面向云平臺非可信Hypervisor的保護機制迫在眉睫?，F(xiàn)有一系列的研究工作運用不同的思想和方法來構建面向云平臺非可信Hypervisor的保護機制。本文將對這些研究工作進行梳理，并分析該領域存在的問題和挑戰(zhàn)以及研究趨勢，從而為未來虛擬化技術在多租戶云平臺中安全運用的研究提供有價值的參考。與現(xiàn)有綜述[29]不同的是，本文從面向云平臺非可信Hypervisor的保護機制的構建角度出發(fā)，分別深入梳理和分析現(xiàn)有的完整性檢測機制、防御機制以及針對非可信Hypervisor的虛擬機隔離機制。

2 面向云平臺非可信Hypervisor的保護機制的可行性和分類

本章將介紹構建面向云平臺非可信Hypervisor的保護機制的可行性與挑戰(zhàn)，并對現(xiàn)有保護機制的構建進行分類。

2.1 可行性與挑戰(zhàn)

典型虛擬化技術中的Hypervisor運行在Ring0層級，同時它擁有最高執(zhí)行權限。而Hypervisor的保護機制運行的不同層級選擇都會面臨相應挑戰(zhàn)，這些挑戰(zhàn)也是決定保護機制是否有效的重要因素。

一般來說，在計算機系統(tǒng)中，處在越低層級的管理系統(tǒng)意味著可以對運行在它上層的應用或是系統(tǒng)有著更多的控制權，即執(zhí)行權限越高。不同的執(zhí)行權限分別對應CPU（central processing unit）執(zhí)行的Ring0、Ring1、Ring2、Ring3權限。因此，按照這樣的思路，保護機制如果有Ring0的執(zhí)行權限，而Hypervisor保有Ring0權限或者置于Ring1權限，此時擁有Ring0權限的保護機制則可以針對Hypervisor來全面地執(zhí)行保護操作。但是，若將保護機制置于Ring0權限，無論Hypervisor是置于Ring0權限或是Ring1權限，其本身對虛擬化系統(tǒng)帶來的修改相對于添加一個上層應用來說是比較大的。那么是否能將保護機制直接置于Ring1權限或者Ring3權限，而對Hypervisor不進行任何修改呢？文獻[30]論述了此思路的可行性。其基本原理在于，在系統(tǒng)虛擬化中，Hypervisor的存在對上層應用并不是完全透明的。系統(tǒng)虛擬化與裸機之間是會表現(xiàn)出邏輯差異、資源差異和時間差異的，并且這些差異能夠被上層應用間接感知。通過對底層的感知，上層的保護機制可以做到對Hypervisor的檢測和有針對性的防御。而上層的保護機制是否有效的關鍵問題在于，其是否能正確理解在Hypervisor中的惡意攻擊的基本邏輯和實際影響。

下面列出面向云平臺非可信Hypervisor的保護機制所面臨的挑戰(zhàn)：

第一，語義鴻溝。底層或者上層的保護機制在實際運行中會遇到難以理解Hypervisor所做的映射、調(diào)度、隔離等任務操作的問題。

第二，避免引入新的攻擊面。保護機制的加入要注意不能過度地“入侵”Hypervisor的運行，以避免新攻擊面的引入。

第三，確保保護機制本身的完整性。如果惡意Hypervisor感知到保護機制的存在，它可能有很多方式去繞過或者瓦解保護機制。例如，篡改保護機制的內(nèi)存、控制流以及任何有效跳轉。保護機制需要保證其本身的完整性，使得其運行的過程中不受到惡意Hypervisor的影響。

第四，確保保護機制輸入和輸出的可信度。任何惡意的Hypervisor都有可能偽造保護機制的輸入或者輸出，以達到欺騙保護機制的目的。在這種情況下，即使保護機制本身運行正常，如果其檢測或者防御的輸入和輸出沒有足夠的可信度，那么一切努力都將付之東流。

2.2 分類

如圖1所示，根據(jù)面向云平臺非可信Hypervisor的保護機制的研究現(xiàn)狀，可將不同類型和側重的保護機制進行如下分類。第一類是構建Hypervisor完整性檢測機制，其構建方法有：基于快照、基于事件和基于遠程驗證。這類保護機制旨在檢測Hypervisor運行中是否存在破壞其完整性的攻擊或漏洞。第二類是構建Hypervisor防御機制，其構建角度有：針對Hypervisor的控制流、指令仿真和精簡可信計算基（trusted computing base，TCB）。這類保護機制旨在提高Hypervisor自身抵御攻擊和漏洞的能力。第三類是構建針對非可信Hypervisor的虛擬機隔離機制，其構建方法有：基于嵌套虛擬化和基于加密技術，其中加密技術又分為基于軟件和基于硬件的加密技術。這類保護機制旨在保證即使面對惡意的Hypervisor，客戶虛擬機依然能夠保有隱私和完整性。

Fig.1 Classification of protection mechanisms for untrusted Hypervisor in cloud圖1 面向云平臺非可信Hypervisor的保護機制的分類

3 Hypervisor完整性檢測機制

本章將梳理針對非可信Hypervisor的完整性檢測機制，其中包括基于快照、基于事件以及基于遠程驗證的完整性檢測機制。

3.1 基于快照的檢測

基于快照的檢測是最常用的完整性衡量方式。完整性檢測機制通過分析其截獲的Hypervisor在內(nèi)存中的快照，來查找惡意攻擊的痕跡或者漏洞。

HyperCheck[31]借助x86的SMM（system management mode）來構建基于快照的完整性檢測機制以實現(xiàn)針對非可信Hypervisor的保護。在SMM中，CPU的運行會切換到一個單獨的SMRAM（system management random access memory）存儲器中的地址空間，并且當前運行的代碼的所有硬件上下文也都保存在SMRAM存儲器中。處于SMM模式中的CPU可以透明地執(zhí)行SMRAM存儲器中的代碼。SMRAM存儲器可以充當可信的存儲空間，因為它無法被任何其他設備訪問。因此，只要SMRAM存儲器被正確設置后鎖定，即使是Hypervisor也不能干擾SMRAM存儲器中程序的執(zhí)行。借助SMM的上述特性，Hyper-Check針對Hypervisor的靜態(tài)數(shù)據(jù)結構是否被攻擊進行檢測。HyperCheck具體由三部分組成：物理內(nèi)存獲取模塊、分析模塊和CPU寄存器檢查模塊。物理內(nèi)存獲取模塊由網(wǎng)卡設備實現(xiàn)，而網(wǎng)卡的驅動程序和CPU寄存器檢查模塊一起放入可信的SMRAM中。CPU寄存器檢查模塊讀取CPU寄存器并驗證其完整性。分析模塊是獨立于系統(tǒng)的安全模塊。物理內(nèi)存獲取模塊通過網(wǎng)卡與分析模塊交互，分析模塊檢查網(wǎng)卡發(fā)來的物理內(nèi)存的內(nèi)容并驗證其是否安全。

上述HyperCheck的完整性檢測本身是由Hypervisor觸發(fā)的。檢測觸發(fā)的不透明性很有可能留下攻擊隱患，例如擦洗攻擊可以在HyperCheck觸發(fā)檢測之前隱藏自己的痕跡。HyperSentry[32]也用到了SMM來構建基于快照的完整性檢測機制，并且還用到了IPMI（intelligent platform management interface）技術[33]進一步構建隱秘信道來實現(xiàn)檢測的觸發(fā)。IPMI是一種面向服務器的平臺管理接口，它直接實現(xiàn)在硬件和固件中。IPMI的關鍵特性在于其管理功能獨立于主處理器、BIOS（basic input output system）和任何系統(tǒng)軟件。因此，基于IPMI構建的信道可以避免任何惡意Hypervisor等最高權限代碼的感知。IPMI能通過直接串接或局域網(wǎng)等方式向遠程端計算機提交信息。系統(tǒng)管理員能使用IPMI消息去向目標機器發(fā)出請求。HyperSentry正是利用IPMI技術的上述特性構建了隱秘通道，如此一來避免了非可信Hypervisor對檢測觸發(fā)的感知，進一步提高了完整性檢測機制的保護效果。具體來說，HyperSentry將完整性檢測代碼駐留在SMM的SMRAM存儲器中，SMRAM存儲器提供其基本代碼所需的保護。HyperSentry的隱秘通道使用IPMI和目標平臺主板上的基板管理控制器遠程觸發(fā)硬件SMI（system management interrupt）中斷，從而觸發(fā)SMM中對Hypervisor的代碼、數(shù)據(jù)和CPU狀態(tài)的完整性檢測。

但是，HyperSentry和HyperCheck中運用的SMM，其安全性不能被視為理所當然，因為SMM的處理程序可以被惡意攻擊篡改[34-35]。

Copilot[36]使用專用的PCI（peripheral component interconnect）設備，即EBSA（Intel StrongARM SA-110/21285 evaluation board）[37]來監(jiān)控系統(tǒng)運行時內(nèi)存快照的完整性。EBSA具有完整的總線主控功能，并支持與主機存儲器的DMA（direct memory access）通信。在EBSA的獨立模式下，Copilot將其配置為拒絕來自主機處理器的所有配置讀取和寫入，從而使其執(zhí)行路徑不受主機上的攻擊者的影響。在完整性檢測中，一方面通過哈希主機的內(nèi)核，Copilot可以檢測任何對主機內(nèi)核現(xiàn)有指令的惡意修改。另一方面，Copilot監(jiān)視惡意攻擊可能添加跳轉指令的位置或可能導致現(xiàn)有主機內(nèi)核執(zhí)行外部程序的函數(shù)指針。盡管Copilot利用了PCI設備的特性，既可不被惡意修改也可不被主機系統(tǒng)檢測到它的存在，但是它有兩個主要缺點：首先，PCI設備上運行的代碼與正在運行的系統(tǒng)之間存在語義鴻溝，即PCI設備不能訪問CPU狀態(tài)，例如CR3寄存器的狀態(tài)。而對CPU狀態(tài)的訪問對于細粒度的完整性檢測過程是必不可少的。其次，現(xiàn)有的攻擊[38]可以防止Copilot正確地訪問物理存儲器，使得PCI設備看到的物理內(nèi)存與CPU看到的不同，因此被篡改的物理內(nèi)存區(qū)域將被隱藏于檢測之外。

3.2 基于事件的檢測

在3.1節(jié)中討論的HyperSentry、HyperCheck和Copilot的完整性保護機制所采用的方法都是基于快照的檢測方法。但是，基于快照的檢測通常存在固有的弱點。主要是因為它們只檢查在一定間隔內(nèi)收集的快照，而忽略了間隔中的變化。攻擊者恰恰可以利用檢查間隔這一關鍵限制，即在此檢測間隔之內(nèi)完成攻擊并恢復攻擊前的Hypervisor狀態(tài)，仿佛沒有攻擊過一樣。這類攻擊稱為擦洗攻擊，HyperSentry利用IPMI技術構建的檢測通道使得攻擊者無法預測完整性保護機制的檢測間隔，這種方法在一定程度上緩解了擦洗攻擊的威脅。但是，還存在一種攻擊稱為瞬態(tài)攻擊[39]，它屬于擦洗攻擊的變種，能在極其短的時間內(nèi)完成攻擊。現(xiàn)有一些針對非可信Hypervisor的基于事件的完整性檢測工作[40-43]，可以很好地解決瞬態(tài)攻擊的問題。

MGUARD[41]利用FB-DIMM（fully buffered dual in-line memory module）硬件[44]實現(xiàn)了一種基于事件捕獲的完整性檢測機制。MGUARD的完整性檢測包括檢查對DRAM（dynamic random access memory）存儲器中的內(nèi)核和關鍵數(shù)據(jù)結構的未授權更改。其基本原理是，當內(nèi)核被編譯并加載到內(nèi)存中，內(nèi)核控制數(shù)據(jù)（例如系統(tǒng)調(diào)用表）往往是靜態(tài)的，對內(nèi)核控制數(shù)據(jù)的任何動態(tài)修改都被視為惡意。MGUARD通過檢查捕獲的DRAM頁面狀態(tài)和DRAM頁面數(shù)據(jù)來實現(xiàn)檢測。此外，F(xiàn)B-DIMM中包括一個串行接口，可以將捕獲的數(shù)據(jù)傳輸?shù)郊械奈恢?，以進一步詳細分析捕獲的數(shù)據(jù)來檢測攻擊的存在。MGUARD在系統(tǒng)啟動時就連續(xù)地監(jiān)視任何對物理DRAM存儲器的訪問。利用FB-DIMM硬件，MGUARD透明地對系統(tǒng)進行完整性檢測，除了物理攻擊以外，它沒有其他的攻擊面。

Vigilare[42]提出了一種基于事件監(jiān)聽的完整性檢測機制。其完整性監(jiān)控系統(tǒng)構建在位于主機系統(tǒng)外部的單獨硬件的獨立系統(tǒng)中，它監(jiān)聽主機系統(tǒng)的總線上的流量以監(jiān)視主機系統(tǒng)的操作。Vigilare可以對幾乎所有系統(tǒng)事件的流量進行安全監(jiān)控，因為I/O設備、內(nèi)存和處理器之間的所有處理器指令和數(shù)據(jù)傳輸都必須通過系統(tǒng)總線。并且Vigilare本身完全獨立于主機系統(tǒng)，能夠抵御來自主機中的任何潛在危害或攻擊。具體來說，Vigilare系統(tǒng)構建在基于ARM的SoC（system on a chip）上運行的Linux內(nèi)核中。它主要由兩部分組成：Snooper和Verifier。Snooper是一個硬件組件，它收集流量并將其傳輸?shù)絍erifier。Verifier是一個精簡的計算機系統(tǒng)，經(jīng)過優(yōu)化可以分析數(shù)據(jù)，以確定主機系統(tǒng)的完整性。因為Vigilare的系統(tǒng)不依賴于主機系統(tǒng)，所以主機系統(tǒng)的完整性不會影響Vigilare系統(tǒng)的完整性，并且主機系統(tǒng)無法以任何方式訪問Vigilare系統(tǒng)的內(nèi)存。

ED-monitor[43]構建了與Hypervisor同地址空間的基于事件驅動的Hypervisor完整性檢測機制。EDmonitor的基于事件驅動方法與Vigilare基于事件監(jiān)聽的方法本質(zhì)上是一樣的，但是實現(xiàn)方法上有所區(qū)別。Vigilare是基于監(jiān)聽總線上的事件來判斷是否有破壞完整性的攻擊，而ED-monitor是通過在Hypervisor中加入鉤子（hook）來觸發(fā)檢測[4]。前者需要獨立的硬件系統(tǒng)來保證完整性保護機制本身的安全性，而后者需要依靠特定的軟件技術來自我防御。這里特定的軟件技術就是ASR（address space randomization）和IPR（instrumentation-based privilege restriction）。ED-monitor將ASR和IPR技術結合來保護其自身的安全。具體來說，ASR是一種用于保護代碼和數(shù)據(jù)免受駐留在同一地址空間中的惡意程序影響的輕量級方法。它使代碼和數(shù)據(jù)隨機化，以確保它們的位置在虛擬地址空間中是不可預測的，從而防止惡意程序破壞它們。但是，現(xiàn)有的ASR技術不足以隱藏針對非可信Hypervisor的完整性保護機制，因為惡意的Hypervisor還可以執(zhí)行特權指令來繞過ASR或者找出保護機制的隨機化位置。例如，Hypervisor可以操縱MMU（memory management unit）配置以將Hypervisor的完整性保護機制重新映射到已知地址并借此繞過ASR。為了使基于ASR的保護機制對惡意的Hypervisor有效，ED-monitor限制了Hypervisor直接執(zhí)行最高權限操作的能力。它利用IPR來消除Hypervisor代碼中的所有特權指令，以便限制Hypervisor必須向ED-monitor請求才能去執(zhí)行特權指令。通過這種方式，ED-monitor可以攔截并驗證Hypervisor中的特權操作（特權指令執(zhí)行、內(nèi)存管理單元的配置、中斷處理等）。另外，為了實現(xiàn)基于事件驅動的檢測手段，ED-monitor在發(fā)生指定的Hypervisor事件時調(diào)用完整性檢測程序。ED-monitor利用hook捕獲指定的Hypervisor事件。這些hook可以是插入Hypervisor代碼中任意位置的代碼hook（即跳轉指令），或是調(diào)用表中的數(shù)據(jù)hook。當Hypervisor的執(zhí)行到達hook時，hook便會將控制流傳輸?shù)紼Dmonitor來觸發(fā)完整性檢測。

3.3 基于遠程驗證的檢測

Pioneer[45]提出了一個在不可信系統(tǒng)中構建遠程驗證可執(zhí)行文件完整性的方法，并且其不需要特定的硬件或者是軟件技術來支持。通過Pioneer可以實現(xiàn)基于軟件的遠程代碼驗證。其允許驗證者從一個可信實體出發(fā)，驗證在另一個非可信實體上運行的軟件堆棧的完整性。驗證者和被驗證平臺通常是不同的物理計算設備。被驗證平臺上的驗證代理對平臺的軟件堆棧進行完整性測量，并將其測量結果發(fā)送給驗證者。一方面，Pioneer在不可信系統(tǒng)中動態(tài)建立可信計算庫，稱為動態(tài)信任基。動態(tài)信任基中包含的所有代碼都可保證未被修改。動態(tài)信任基一旦建立，它就會測量可執(zhí)行文件的完整性?？蓤?zhí)行文件將在動態(tài)信任基的執(zhí)行環(huán)境中執(zhí)行。另一方面，驗證者的代碼由三部分組成：校驗和代碼、哈希函數(shù)和發(fā)送函數(shù)。校驗和代碼計算整個驗證函數(shù)的校驗和，其需要在可屏蔽中斷的最高權限級別執(zhí)行，因此Pioneer需要最高執(zhí)行權限。Pioneer使用哈希函數(shù)（secure Hash algorithm 1，SHA-1）來進行對可執(zhí)行文件的完整性測量。發(fā)送函數(shù)通過通信鏈路將校驗和結果與完整性測量結果返回給調(diào)度程序。在驗證過程中，驗證者使用輪詢-響應協(xié)議來獲得不可信平臺上可驗證代碼執(zhí)行的保證。該協(xié)議有兩個步驟：首先，調(diào)度程序獲得在不受信任的平臺上存在動態(tài)信任基的保證；其次，調(diào)度程序使用動態(tài)信任基來獲得可驗證代碼執(zhí)行的保證。

Pioneer提出的遠程驗證方法可以用來保護Hypervisor的完整性檢測機制的安全，即Pioneer可以用來對完整性檢測機制本身的完整性進行實時驗證。進一步的，Pioneer還可以用作構建任意安全應用程序的基本原語。

3.4 小結

在Hypervisor的完整性檢測機制中，本章分別分析了基于快照、基于事件和基于遠程驗證的三種構建方法。基于快照的完整性檢測相較于基于事件更為通用和直接，但是其安全性較弱。因為快照的捕獲需要時間驅動，這就容易留下攻擊窗口，例如擦洗攻擊和瞬時攻擊?；谑录耐暾詸z測避免了留下時間窗口，更為可靠和安全，但是其對事件的針對性較強，實現(xiàn)方式也更為復雜，因為保護機制需要先識別Hypervisor中的特定事件才能觸發(fā)監(jiān)聽。基于遠程驗證的完整性檢測則是通過建立動態(tài)的可信來觸發(fā)完整性檢測。這種方法在實現(xiàn)上比較靈活，可以作為任意安全程序的構建基礎。但在安全性方面，其需要依靠一個可信的主機來保證驗證結果的可靠性，因此可信主機需要避免被攻擊。在構建上述完整性檢測機制的過程中，首先，依靠軟件的方式在現(xiàn)實中比起依賴于特殊硬件更為實際和通用，例如ED-monitor中的ASR和IPR只需安裝并開啟即可。其次，特殊硬件的選擇要注意其本身的限制，避免引入新的威脅，例如本章所提的HyperSentry中的SMM和Copilot中的PCI設備分別存在的問題。

4 Hypervisor防御機制

第3章分析了針對非可信Hypervisor的完整性檢測方法，采用檢測的手段有一個局限性，即它是屬于被動防御，不能預防攻擊的出現(xiàn)。本章將梳理針對非可信Hypervisor的主動防御工作，即旨在建立可信的Hypervisor。其中包括針對Hypervisor的控制流、指令仿真以及精簡TCB的防御機制。

4.1 針對Hypervisor控制流的防御

Hypersafe[46]構造了旨在保證Hypervisor的運行時控制流完整性的保護機制。運行時的控制流完整性包括靜態(tài)控制流和動態(tài)控制流的完整性，其中靜態(tài)控制流的完整性由Hypervisor的代碼和靜態(tài)控制數(shù)據(jù)決定，而動態(tài)控制流的完整性由運行時的動態(tài)控制數(shù)據(jù)決定。Hypersafe使用不可旁路的內(nèi)存鎖定技術和受限制的指針索引技術來構建防御機制，使得攻擊者無法對Hypervisor的控制流的完整性作出破壞操作。具體來說，不可旁路的內(nèi)存鎖定技術保證了Hypervisor的代碼和靜態(tài)控制數(shù)據(jù)的安全，它本質(zhì)上是基于x86系統(tǒng)的內(nèi)存保護機制實現(xiàn)的，即對頁表的W⊕X位設置寫保護。而為了對頁表進行正常的更新操作，Hypersafe利用WP位的硬件功能（即CPU控制寄存器CR0中的寫保護位）構造了一種安全的方法來臨時繞過寫保護，并且這種繞過的方法不會被惡意濫用。受限制的指針索引技術保證了Hypervisor運行時執(zhí)行路徑符合控制流完整性，即保護動態(tài)控制數(shù)據(jù)的安全。它將每個動態(tài)控制數(shù)據(jù)替換為目標表的受限索引。目標表包含Hypervisor的控制流程圖允許的所有間接控制轉移指令的合法位置?；谀繕吮?，Hypersafe可以替換Hypervisor中所有運行時的動態(tài)控制數(shù)據(jù)。

4.2 針對Hypervisor指令仿真的防御

FWinst[47]針對Hypervisor的指令仿真進行了保護工作。理想情況下，Hypervisor只需要仿真指令集的小部分。但是，在x86架構上，可能需要Hypervisor仿真大多數(shù)指令[48-49]，包括仿真以下五方面中除敏感指令外的其他指令：端口I/O、內(nèi)存映射I/O、影子頁表、實模式、遷移。仿真大多數(shù)x86指令很復雜，且容易出錯。x86仿真器中存在很多漏洞，例如CVE2016-9756、CVE2017-2584、CVE2015-0239和CVE2017-2583[23]。另外，文獻[48]證明了任何指令都可以被強制模仿，這種新的攻擊媒介允許攻擊者有機會利用任何指令中的漏洞實施攻擊。

FWinst通過限制和縮小Hypervisor指令仿真的有效攻擊面來防御針對指令仿真的攻擊。要仿真的合法指令子集取決于調(diào)用仿真器的仿真上下文。如果仿真器僅接受每個上下文中的合法指令集，則針對指令的攻擊面就會縮小，因為攻擊者無法利用當前上下文中不合法的指令中的漏洞。具體來說，F(xiàn)Winst識別五個上下文：端口I/O上下文、內(nèi)存映射I/O上下文、影子頁表上下文、實模式上下文和遷移上下文。并且給出每個上下文的合法指令的列表。為了縮小攻擊面，F(xiàn)Winst使用Hypervisor的配置確定哪個上下文有效。當調(diào)用Hypervisor來仿真指令時，F(xiàn)Winst會檢查當前上下文是否有效。如果FWinst認為當前上下文無效，則不會允許任何指令的仿真，反之則將合法指令傳遞給仿真器。

FWinst針對指令仿真中的漏洞和攻擊進行了一定的限制和防御，但是FWinst目前的工作只針對Linux4.8版本中的KVM，在其他虛擬化技術中是否有效還有待驗證。

4.3 構建Hypervisor的精簡TCB

Hypervisor是具有廣泛攻擊面的大型代碼庫，本文引言中已經(jīng)提到了這一點。在Hypervisor代碼庫中，其設計和實現(xiàn)的組件相當復雜，包括復雜的內(nèi)存虛擬化和客戶虛擬機的指令仿真等。這些組件占據(jù)其代碼庫的一半，并且通常是各種可利用漏洞的存在之處。在4.1節(jié)和4.2節(jié)中提到的Hypersafe和FWinst都是有針對性地對Hypervisor構建防御，但Hypervisor的龐大攻擊面這一特性依然存在。根據(jù)TCB的可驗證原理，更小的代碼量通常意味著更可信[50]。因此，有一些研究工作[51-58]針對如何重構Hypervisor，實現(xiàn)既能保留其功能，又能精簡其代碼量的目的。精簡后的Hypervisor便可以是TCB的一部分，并且其代碼的正確性易被驗證。驗證Hypervisor精簡TCB的方法有很多，例如seL4[59]和Verve[60]。其中，seL4提供了驗證微內(nèi)核是否存在特定類型的軟件漏洞的方法，Verve可以用來驗證軟件堆棧中Hypervisor的每條指令的類型和內(nèi)存安全。另外，文獻[61]提出了一種快速驗證Hypervisor可擴展部分安全性的方法，也可以用來提高精簡Hypervisor在功能擴展時的安全。下面舉例梳理重構Hypervisor的研究工作。

NOVA[54]借助微內(nèi)核的思想將Hypervisor的功能細粒度地分解為micro-Hypervisor、根分區(qū)管理器、用戶層的Hypervisor、設備驅動程序和其他系統(tǒng)服務設備。其中micro-Hypervisor運行在CPU的最高權限，而其余功能模塊都運行在用戶層。NOVA遵循最小權限原則，它實現(xiàn)的micro-Hypervisor作為TCB，其代碼量要比原本的Hypervisor少一個數(shù)量級。但NOVA存在的一個問題是，客戶虛擬機某些正常功能可能涉及到很多CPU模式的切換，造成性能損失。

Dichotomy[58]基于Hypervisor即服務的思想，將傳統(tǒng)的Hypervisor分為hyperplexor和featurevisor兩部分。其中hyperplexor為核心部分，它是一個小型、安全且穩(wěn)定的Hypervisor，僅用于管理物理硬件的調(diào)度和為featurevisor提供支持。而featurevisor是一種輕度修改的Hypervisor，它在用戶層運行，即在hyperplexor之上運行，負責面向客戶虛擬機的具體服務和管理。每個客戶虛擬機可以根據(jù)所需的服務分配不同的featurevisor。另外，Dichotomy還提出了短暫虛擬化的概念，即featurevisor可以靈活地暫時將客戶虛擬機的管理轉移給hyperplexor，以此減少上下層切換的開銷。

與NOVA和Dichotomy類似的，DeHype[53]也將Hypervisor分解。它將Hypervisor的特權指令代碼的最小子集定義為OS（operating systems）擴展，稱為HypeLet，而將其他的大多數(shù)Hypervisor代碼放在用戶模式下執(zhí)行。當用戶模式下的Hypervisor發(fā)出特權指令請求時，它需要通過系統(tǒng)調(diào)用方式進入特權模式執(zhí)行HypeLet中的相關指令。用戶模式運行的Hypervisor基本上作為用戶庫運行，提供與HypeLet交互的必要功能。而HypeLet是當前虛擬機管理程序代碼庫添加的唯一特權組件。DeHype是針對KVM的研究工作，其原型中HypeLet只包含兩萬多代碼行并且僅定義了10個系統(tǒng)調(diào)用，但其是否適用于其他虛擬化方案還有待驗證。

NoHype[51]與上述工作的思想不同，它認為Hypervisor并不是虛擬化管理工作必不可少的一部分，因此它直接將客戶虛擬機之間的物理資源進行預分配和隔離，而不再需要Hypervisor。具體來說，它依靠硬件的虛擬化特性[62]，嚴格地劃分客戶虛擬機之間的物理資源，使得客戶虛擬機只需要在啟動時與一個臨時的Hypervisor交互，而在其運行期間不再需要與Hypervisor交互。NoHype去掉了傳統(tǒng)意義上的Hypervisor管理層，因此大大減少了其TCB的存在。但是，NoHype對沒有硬件支持物理隔離的環(huán)境并不友好，另外其仍然需要對客戶虛擬機的操作系統(tǒng)內(nèi)核進行微小修改，增加了開發(fā)難度。

上述研究對Hypervisor進行重新設計采用的方法不盡相同，但卻殊途同歸。不同方法有各自的優(yōu)勢和劣勢，研究人員需要根據(jù)不同的場景選擇不同的方式。而如何構建一個完備而又通用的方法，使得Hypervisor的TCB既精簡且易于驗證，同時性能減損，是留給研究人員繼續(xù)攻克的問題。

4.4 小結

在Hypervisor的防御機制中，本章梳理了針對控制流、指令仿真和精簡TCB的構建方法。三者比較而言，一方面，前兩者相比于精簡TCB的構建更為實用，可直接被現(xiàn)有實際的Hypervisor所采用，而4.3節(jié)所提的精簡TCB的方法需要對原有Hypervisor進行不同程度的重構。簡單直接的重構需要劃分Hypervisor的功能模塊，例如NOVA，而復雜的重構需要直接去除Hypervisor層，例如NoHype。另一方面，構建Hypervisor的精簡TCB在安全性方面更為全面和可靠。Hypersafe和FWinst都是有側重的防御工作，兩者需要結合才能提供較全面的防御。而精簡TCB的構建因為其本身安全性的易于驗證，可以提供更直接的全面防御。

5 針對非可信Hypervisor的虛擬機隔離機制

第3、第4章分別分析了Hypervisor的完整性檢測機制和防御機制的研究工作。這些工作也都各有側重和優(yōu)缺點，因此在實際中可能還是會有繞過檢測和防御的攻擊方法。本章將梳理致力于隔離惡意Hypervisor和客戶虛擬機的研究工作。其中包括基于嵌套虛擬化技術和基于加密技術的隔離機制。

5.1 基于嵌套虛擬化

CloudVisor[63]致力于限制和隔離任何非可信的Hypervisor對上層客戶虛擬機的資源（CPU、內(nèi)存和I/O設備）的非法操作。它利用嵌套虛擬化技術[64-65]，將Hypervisor置于Ring1權限，而其本身運行在Ring0權限，如此一來CloudVisor中保護操作的執(zhí)行便對任何惡意的Hypervisor來說都是透明的，并且其擁有更高的權限。具體來說，在CPU方面，CloudVisor為Hypervisor和客戶虛擬機之間所有控制轉移進行必要的轉換和保護。而在內(nèi)存方面，CloudVisor跟蹤Hypervisor維護的每個頁和每個頁表的所有權（即擴展頁表），并且不允許Hypervisor直接覆蓋擴展頁表，它會在Hypervisor頁表的更新時檢查頁面的所有權是否與頁表的所有權匹配，如果不匹配則加密頁面內(nèi)容。最后在I/O設備方面，為了保護虛擬磁盤，CloudVisor在客戶虛擬機的每次磁盤I/O訪問期間透明地加密和解密數(shù)據(jù)。它使用信息摘要哈希算法（message-digest algorithm，MD5）和Merkle樹[66]來確保磁盤數(shù)據(jù)的完整性。另外，它通過維護每個客戶虛擬機的I/O訪問權限表來防止來自Hypervisor的DMA攻擊。

5.2 基于加密技術

利用加密的手段來保護客戶虛擬機免受非可信Hypervisor的入侵是一種有效的辦法，因為惡意Hypervisor無法對加密的數(shù)據(jù)進行攻擊。本節(jié)將分別分析基于軟件和基于硬件的加密技術。

5.2.1 基于軟件的加密

文獻[67]提出了由AISE（address independent seed encryption）內(nèi)存加密算法和BMT（Bonsai Merkle tree）哈希樹算法組成的軟件加密技術。AISE+BMT的加密方法需要信任CPU，因為它依靠CPU運行時對密文元數(shù)據(jù)的處理邏輯來實現(xiàn)加密。

在AISE中，處理器不會直接加密數(shù)據(jù)塊（Cache數(shù)據(jù)塊），而是通過加密數(shù)據(jù)塊的種子（seed）來產(chǎn)生一個偽隨機數(shù)，然后將這個偽隨機數(shù)與數(shù)據(jù)塊的明文進行異或后產(chǎn)生數(shù)據(jù)塊的密文。數(shù)據(jù)塊的seed是地址獨立的，并且每加密一次都會發(fā)生改變，其具體由三部分組成：LPID（logical per-page ID）、計數(shù)器和偏移。LPID對于每個物理內(nèi)存頁面都是唯一的。LPID的值在初始化時分配，與頁面地址無關。計數(shù)器和頁面偏移量是針對每個Cache數(shù)據(jù)塊的值。當計數(shù)器溢出，相應的頁面將會被分配新的LPID并重新加密。BMT哈希樹用來對AISE中的Cache數(shù)據(jù)塊的seed進行完整性保護，它會將seed的密文的哈希值更新到一棵哈希樹中，該哈希樹的根節(jié)點保存在CPU中。當處理器將seed的密文從內(nèi)存加載到Cache時，處理器會先從BMT獲取其對應的哈希值，然后將其與當前加載的密文數(shù)據(jù)計算所得的哈希值進行比較，以確定當前獲取的seed的完整性。

在性能方面，AISE+BMT的加密方法引入的開銷較低。首先，加密和解密操作是針對數(shù)據(jù)的seed而不是具體的數(shù)據(jù)，因此可以與存儲器的加載和存儲操作并行化來提升性能。其次，由于seed中的計數(shù)器很小，因此其緩存的命中率非常高。再者，BMT可以很大程度上減少內(nèi)存和緩存中哈希的大小。

SecureME[68]和HyperCoffer[69]都是運用了AISE+BMT的方法來加密客戶虛擬機數(shù)據(jù)的保護機制，但是兩者適用的場景有所不同。SecureME利用了Hypervisor來實現(xiàn)其保護機制，并將Hypervisor列為了TCB的一部分，因此它的保護機制無法隔離來自惡意Hypervisor的攻擊。而HyperCoffer只信任客戶虛擬機的OS內(nèi)核。在HyperCoffer中，客戶虛擬機中的所有數(shù)據(jù)都受到保護，包括CPU上下文中的數(shù)據(jù)、Cache數(shù)據(jù)、內(nèi)存和I/O數(shù)據(jù)。因此，在面對非可信Hypervisor時，HyperCoffer能真正對客戶虛擬機的安全進行基于加密的隔離保護。

5.2.2 基于硬件的加密

Fidelius[70]使用其改進的AMD的SEV（secure encrypted virtualization）技術[71]實現(xiàn)了對客戶虛擬機數(shù)據(jù)的加密和保護。與5.2.1小節(jié)中AISE+BMT的軟件加密方法的比較而言，F(xiàn)idelius使用的SEV更具優(yōu)勢。首先，SEV是在主流處理器的固件中實現(xiàn)的，硬件的支持使其更可靠，并且它可以在實際運用中得到更廣泛的支持。其次，SEV授予客戶虛擬機以頁粒度方式控制加密粒度的能力，因此它更靈活，可以適應更復雜的加密場景。

SEV是集成在AMD-V技術中的內(nèi)存加密技術，它專門針對虛擬化的場景。SEV實現(xiàn)在獨立的SoC固件中，并與容納在CPU中的存儲器控制器協(xié)同工作。所有密鑰都由獨立的安全處理器管理，并安裝到內(nèi)存控制器中，以支持片上的AES（advanced encryption standard）加密引擎。但是，在面向非可信Hypervisor時，只使用SEV的保護并不充分[72-73]。首先，SEV未加密VMCB（virtual machine control block），因此其完整性在當前SEV中不受保護。其次，物理內(nèi)存映射仍由Hypervisor控制，即使啟用了SEV的一種特殊模式SEV-ES（secure encrypted virtualizationencrypted state），暴露物理頁表可能導致客戶虛擬機受到攻擊威脅。再者，啟用密鑰共享的客戶虛擬機無法阻止Hypervisor將密鑰暴露給其他惡意的客戶虛擬機。最后，SEV不支持DMA在加密數(shù)據(jù)上操作，因此客戶虛擬機的I/O數(shù)據(jù)是沒有加密的。

為了既有效地利用SEV加密技術，又能避免其在面對非可信Hypervisor時暴露的缺陷，F(xiàn)idelius結合SEV技術進行了如下改進。首先，F(xiàn)idelius分離Hypervisor對硬件資源的管理功能與提供服務功能。Hypervisor仍然為客戶虛擬機提供服務，但是具體的資源管理交由Fidelius驗證和管理。這樣就避免了惡意Hypervisor對VMCB和SEV密鑰等資源的濫用。其次，構造針對物理頁表的不可旁路的內(nèi)存隔離保護。Fidelius利用文獻[74-75]中的方法獲得與Hypervisor相同的執(zhí)行權限，并通過4.1節(jié)中Hypersafe的不可旁路的內(nèi)存鎖定將物理頁表與Hypervisor保持分離。Hypervisor對物理頁表只讀，而Fidelius參與正常的物理頁表操作并基于頁面信息表來驗證物理頁表的更新。最后，通過改進SEV的發(fā)送和接收接口，F(xiàn)idelius可以加密客戶虛擬機的磁盤I/O數(shù)據(jù)。

但是，F(xiàn)idelius信任客戶虛擬機內(nèi)核，無法隔離來自客戶虛擬機內(nèi)核的攻擊。如果需要在完全不可信的環(huán)境中只保護客戶虛擬機的應用程序，那么真正完全有效的方法是既不信任Hypervisor，也不信任客戶虛擬機內(nèi)核，做到只針對應用程序的加密級別。Intel的SGX（software guard extensions）技術[76]就可以用來實現(xiàn)此場景的需求，例如Haven[77]對SGX的運用。文獻[78]將業(yè)界的Intel的SGX和AMD的SEV進行了詳細的對比。SGX技術擁有和SEV一樣的來自主流處理器的廣泛支持的特點。但是不同于SEV，SGX技術無法用來加密整個虛擬機，它只支持應用層面的加密。利用SGX技術可以將受保護的應用程序與外界任意軟件隔離，構建僅和CPU之間可信的通道。

5.3 小結

在針對非可信Hypervisor的虛擬機隔離機制中，本章梳理了基于嵌套虛擬化和基于加密技術的構建方法。利用嵌套虛擬化可以從執(zhí)行權限方面隔離Hypervisor，而基于軟件和基于硬件的加密技術將客戶虛擬機的數(shù)據(jù)安全地與Hypervisor隔離。本質(zhì)上它們都旨在使得惡意的Hypervisor無法肆意地破壞客戶虛擬機，從而保護了客戶虛擬機的安全。兩者比較而言，嵌套虛擬化對原有虛擬化系統(tǒng)的改動比較大，不過這種方法的隔離構建更為有效和徹底，例如CloudVisor將Hypervisor置于Ring1權限，全面地限制了Hypervisor作惡的能力。而加密技術在實現(xiàn)上更為簡單，例如Fidelius方法可以直接在現(xiàn)有支持AMD的SEV技術的機器中實現(xiàn)。另外，在加密技術中，具體加密方法的選擇與運用，還需要研究者結合加密技術支持情況和受保護的對象是虛擬機或是應用程序等條件來權衡。

6 未來研究趨勢

性能和安全，在系統(tǒng)領域一直是互相影響的兩方面。一方面，安全機制的存在不可避免地會引入額外的開銷，導致性能降低；另一方面，在追求極致性能的研究路上又可能留下安全漏洞。現(xiàn)有工作[11，79]同時考慮了系統(tǒng)安全性和效率，分別針對客戶虛擬機在安全性方面和隔離性方面存在的問題，構建了相應的保護機制，在保留高性能的同時提高了多租戶云平臺的可靠性。在未來面向云平臺非可信Hypervisor的保護機制研究趨勢中，結合性能和安全的考慮，本章給出以下三方面的探討。

首先，可以構建基于硬件技術的保護機制。縱觀虛擬化的發(fā)展，早先的虛擬化技術是沒有硬件特性的技術支持的，因此其性能并不樂觀。在Intel和AMD分別推出Intel-VT和AMD-V后，處理器對虛擬化的支持極大改善了虛擬化的性能。同樣的，在安全方面，Intel的SGX和AMD的SEV也都從硬件層面對虛擬化技術提供保護的支持。一般來說，基于硬件實現(xiàn)的保護機制在性能方面要優(yōu)于純軟件實現(xiàn)保護機制。因此，利用硬件技術來構建保護機制將會一直是一個重要的研究方向。特定硬件能提供的特性也不僅僅在于性能，更有獨立于主機系統(tǒng)或執(zhí)行模式等安全特性，即硬件本身可以成為TCB的一部分。本文所提到的完整性檢測機制、防御機制和隔離機制的研究工作中，也都有利用硬件技術構造保護機制的影子。但是，在這個方向中也存在著幾點重要考慮因素。一是硬件本身也可能存在漏洞和異常；二是其通用程度。前者是基于硬件的保護機制是否能正確運作的基礎，而后者決定了其是否能夠在實際中更廣泛地運用。

其次，可以構建分布式保護機制來動態(tài)地建立安全。在多租戶云平臺中，惡意的Hypervisor往往只局限于少數(shù)服務器中。攻擊者對云平臺的布局一般是未知的，因此攻擊在各個主機之間是獨立發(fā)生的。同時攻擊多個服務器并使它們作惡，其難度要比只攻擊單臺服務器大很多。因此，可以基于大多數(shù)云平臺服務器安全的前提，來構建面向云平臺非可信Hypervisor的保護機制，以保護少數(shù)非可信的云平臺服務器。分布式保護機制本質(zhì)上可以借鑒分布式共識協(xié)議在很多應用場景的核心思想。最典型的便是區(qū)塊鏈技術中，聯(lián)盟鏈里用到的解決拜占庭問題的PBFT（practical Byzantine fault tolerance）共識協(xié)議[80]。利用多數(shù)派安全的特征，集群可以動態(tài)地從其中找出主可信節(jié)點，并且可以不斷更換主可信節(jié)點來進一步提高安全性。當然，分布式的引入可能會帶來性能消耗，因此性能止損是構建分布式保護機制的關鍵挑戰(zhàn)之一。

再者，可以構建基于機器學習的保護機制。近年來，人工智能等新興應用領域在多租戶云平臺的底層基礎支持下，滲入到了各行各業(yè)中，也被運用得越來越廣泛。但反過來，人工智能中的技術，例如機器學習，其本身處理數(shù)據(jù)的方式也能夠促進云平臺的安全構建。機器學習可以用來分析現(xiàn)有攻擊的特征，包括其對虛擬化系統(tǒng)帶來的硬件和軟件上影響的特征信息。在對這些特征信息捕獲、分析和建模后，構建的保護機制便可以高效地進行檢測、防御和隔離工作，甚至可以預知潛在攻擊的威脅。舉例來說，硬件性能計數(shù)器和系統(tǒng)日志是構建保護機制很好的信息來源和載體。一方面，硬件性能計數(shù)器可以用來分析惡意攻擊程序運行時觸發(fā)的硬件事件，包括Cache、分支預測和CPU周期等方面的硬件事件?，F(xiàn)有研究工作[81-83]基于硬件性能計數(shù)器中的信息，運用機器學習算法實現(xiàn)了對側信道攻擊的實時檢測。研究工作[84]也利用硬件性能計數(shù)器中的信息構建了針對內(nèi)核控制流攻擊的檢測機制。另一方面，系統(tǒng)日志中記錄了系統(tǒng)運行中所有重要的狀態(tài)和事件，是理解系統(tǒng)是否正確運行的寶貴資源。并且，系統(tǒng)日志非常像自然語言，因為其是由遵循嚴格邏輯和控制流的程序生成的。研究工作[85]即基于大量系統(tǒng)日志信息，構建了檢測系統(tǒng)異常和攻擊的機器學習模型。目前，機器學習在系統(tǒng)安全方面的研究工作尚且不多，這也是留給研究人員的很好機會。

7 總結

Hypervisor在虛擬化軟件層中扮演著至關重要的角色，但它和其他軟件層一樣受到漏洞和攻擊的威脅。為此，需要構建面向云平臺非可信Hypervisor的保護機制來提高虛擬化安全性。保護機制的構建可以從完整性檢測、主動防御和虛擬機隔離機制這三方面出發(fā)。在完整性檢測方面，檢測機制需正確捕獲Hypervisor運行的異常。其實現(xiàn)方式直接決定了檢測局限性所在。構建完備的檢測機制需要結合檢測目標，選擇合適的檢測手段，確保檢測的有效性和檢測機制本身的安全性。在主動防御方面，防御機制旨在提高Hypervisor運行的安全性。構建有效的防御機制需要結合Hypervisor的攻擊面，充分考慮潛在的威脅，并致力于避免防御機制被繞過和攻擊。在虛擬機隔離方面，隔離機制應針對非可信Hypervisor，結合具體的隔離目標和現(xiàn)有的隔離技術，構建惡意攻擊無法入侵的屏障。最后，未來的研究工作可以從基于硬件保護、機器學習和分布式保護這三方面出發(fā)，綜合考慮性能與安全，構建實用的面向云平臺非可信Hypervisor的保護機制。