云計(jì)算環(huán)境中的虛擬機(jī)同駐安全問(wèn)題綜述

沈晴霓 李 卿

（北京大學(xué)軟件與微電子學(xué)院 北京大學(xué)網(wǎng)絡(luò)與軟件安全保障教育部重點(diǎn)實(shí)驗(yàn)室 北京 100871）

云計(jì)算環(huán)境中的虛擬機(jī)同駐安全問(wèn)題綜述

沈晴霓 李 卿

（北京大學(xué)軟件與微電子學(xué)院 北京大學(xué)網(wǎng)絡(luò)與軟件安全保障教育部重點(diǎn)實(shí)驗(yàn)室 北京 100871）

在云計(jì)算環(huán)境中，為了實(shí)現(xiàn)資源共享，不同租戶的虛擬機(jī)可能運(yùn)行在同一臺(tái)物理機(jī)器上，即虛擬機(jī)同駐，這將帶來(lái)新的安全問(wèn)題。為此，文章重點(diǎn)討論同駐虛擬機(jī)所面臨的一些新的安全威脅，包括資源干擾、隱蔽通道/側(cè)信道、拒絕服務(wù)與虛擬機(jī)負(fù)載監(jiān)聽(tīng)等，介紹現(xiàn)有虛擬機(jī)同駐探測(cè)方法，總結(jié)針對(duì)虛擬機(jī)同駐威脅的四種防御思路，并分析未來(lái)的研究趨勢(shì)。

云計(jì)算；虛擬化；虛擬機(jī)；同駐；安全

1 引 言

云計(jì)算具有資源配置動(dòng)態(tài)化、需求服務(wù)自助化、以網(wǎng)絡(luò)為中心、服務(wù)可計(jì)量化、資源池化和透明化等特點(diǎn)，不僅節(jié)省了應(yīng)用成本，提高了計(jì)算能力，而且還降低了能源的消耗。目前主流的基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）平臺(tái)包括：亞馬遜的彈性計(jì)算云（Elastic Compute Cloud，EC2）［1］、Google 的谷歌計(jì)算引擎［2］，微軟的 Azure［3］，Rackspace 的 Mosso［4］以及開源的 OpenStack［5］等，它們將底層的計(jì)算資源虛擬化，為上層的租戶提供強(qiáng)大的計(jì)算能力。

在云計(jì)算技術(shù)方面，研究者們最初關(guān)注的主要是虛擬機(jī)間高效通信問(wèn)題［6-7］，提出了XenLoop［8］、XenSocket［9］、Xway［10］、IVC［11］以及 MMNet［12］等一系列解決方案。但是，隨著云計(jì)算技術(shù)的發(fā)展，云計(jì)算安全問(wèn)題越來(lái)越引起人們重視［13-17］，特別是美國(guó)加州大學(xué)圣迭戈分校的Ristenpart 等［17］在 2009 年首次指出了云計(jì)算環(huán)境中虛擬機(jī)同駐安全問(wèn)題，即云服務(wù)供應(yīng)商為了有效利用物理資源，常將不同租戶的虛擬機(jī)分配給同一臺(tái)物理機(jī)器（稱為同駐）。這就導(dǎo)致攻擊者能夠有機(jī)會(huì)將自己的虛擬機(jī)與受害者的虛擬機(jī)同駐，從而威脅受害者虛擬機(jī)資源的機(jī)密性和可用性等。近年來(lái)，人們研究發(fā)現(xiàn)多種同駐安全威脅［18-24］，包括資源干擾、隱蔽通道/側(cè)信道、拒絕服務(wù)與虛擬機(jī)負(fù)載監(jiān)聽(tīng)等。例如：美國(guó)馬薩諸塞大學(xué)阿默斯特分校［18］對(duì)同駐虛擬機(jī)間的資源干擾進(jìn)行了細(xì)致的分析與實(shí)驗(yàn)；美國(guó)威斯康星大學(xué)麥迪遜分校［19］基于同駐虛擬機(jī)間的資源沖突問(wèn)題，提出了資源釋放攻擊；美國(guó)密歇根大學(xué)［20］對(duì)同駐虛擬機(jī)間的第二級(jí)高速緩存（L2 Cache）隱蔽通道/側(cè)信道問(wèn)題進(jìn)行了深入的分析；美國(guó)東北大學(xué)［21］對(duì)虛擬機(jī) VCPU 公平調(diào)度器的脆弱性進(jìn)行了分析，指出了針對(duì)同駐虛擬機(jī) VCPU 進(jìn)行的拒絕服務(wù)攻擊等。針對(duì)上述威脅，研究者們又陸續(xù)提出了一系列同駐探測(cè)方法和防御技術(shù)［22-26］。例如，美國(guó)俄勒岡大學(xué)［22］基于同駐虛擬機(jī)的網(wǎng)絡(luò)包時(shí)延問(wèn)題，提出了同駐水印探測(cè)技術(shù)；美國(guó)北卡羅來(lái)納大學(xué)和 RSA 實(shí)驗(yàn)室［23，24］分析了 L2 Cache問(wèn)題，提出了一種探測(cè)虛擬機(jī)同駐的工具——HomeAlone；微軟公司［27］基于最低級(jí)高速緩存的隱蔽通道/側(cè)信道問(wèn)題，提出了提高虛擬機(jī)資源隔離性的防御對(duì)策；美國(guó)孟菲斯大學(xué)［28］針對(duì)同駐虛擬機(jī)的網(wǎng)絡(luò)通信拒絕服務(wù)攻擊，提出了一種基于博弈論的防御機(jī)制。

2 虛擬機(jī)同駐安全威脅

同駐虛擬機(jī)的安全問(wèn)題是基于這樣一個(gè)假設(shè)：云平臺(tái)的 IaaS 基礎(chǔ)架構(gòu)和云服務(wù)供應(yīng)商都是可信的，而云服務(wù)的使用者（租戶）之間是互不信任的。攻擊者指的是利用云平臺(tái)進(jìn)行攻擊的惡意租戶，而受害者指的是利用云平臺(tái)提供的服務(wù)執(zhí)行某些機(jī)密性相關(guān)程序的正常租戶。像其他普通租戶一樣，攻擊者可以在云平臺(tái)中開啟并控制多個(gè)虛擬機(jī)實(shí)例，由于云服務(wù)供應(yīng)商對(duì)物理資源需要有效利用，可能會(huì)將攻擊者的實(shí)例與受害者實(shí)例分配到同一臺(tái)物理機(jī)器上，這樣攻擊者就可以利用共享的物理資源（如 CPU、內(nèi)存、磁盤和網(wǎng)絡(luò)等）竊取受害者的私密數(shù)據(jù)或者達(dá)到拒絕服務(wù)目的等。

虛擬機(jī)同駐威脅［17］如圖 1 所示，通常地，攻擊者首先針對(duì)受害者虛擬機(jī)所屬區(qū)域和類型，租用和啟動(dòng)大量同區(qū)域和同類型的虛擬機(jī)實(shí)例，然后再利用這些虛擬機(jī)實(shí)例，探測(cè)其中哪些實(shí)例與受害者虛擬機(jī)同駐，之后再通過(guò)這些同駐的實(shí)例對(duì)受害者虛擬機(jī)及其平臺(tái)實(shí)施攻擊。目前，虛擬機(jī)同駐可能帶來(lái)的安全威脅主要包括：（1）對(duì)受害者虛擬機(jī)資源的干擾，包含 CPU、磁盤和網(wǎng)絡(luò)資源的干擾；（2）利用虛擬機(jī)間共享資源（如 L2 Cache）構(gòu)造隱蔽通道/側(cè)信道，獲取受害者虛擬機(jī)上的機(jī)密信息［17，20，29］，例如 RSA/AES 密鑰；（3）對(duì)受害者虛擬機(jī)造成拒絕服務(wù)，利用網(wǎng)絡(luò)傳輸隊(duì)列（Transmit and Receive Queue，T/R Queue）［28］或VCPU 調(diào)度器的漏洞［20］等使受害者虛擬機(jī)的可用性降低；（4）資源釋放，利用同駐虛擬機(jī)間存在資源沖突問(wèn)題，使受害者虛擬機(jī)釋放資源［19］；（5）監(jiān)聽(tīng)并探測(cè)受害者虛擬機(jī)的負(fù)載狀況［17，22］。

2.1 同駐虛擬機(jī)間的資源干擾

圖1 虛擬機(jī)同駐威脅Fig. 1 Co-residency threats of virtual machine

盡管虛擬機(jī)監(jiān)控器（Virtual Machine Monitor，VMM）對(duì)虛擬機(jī)提供隔離性，但是當(dāng)資源爭(zhēng)用時(shí)仍然會(huì)導(dǎo)致相互干擾，影響性能［18，30，31］。美國(guó)馬薩諸塞大學(xué)阿默斯特分校的Barker 等［18］分別從 CPU、磁盤和網(wǎng)絡(luò)三種資源角度分析了在一個(gè)虛擬機(jī)上運(yùn)行的時(shí)間敏感型程序是否會(huì)受到同駐虛擬機(jī)上運(yùn)行的其他程序的干擾。基于 EC2 公有云平臺(tái)和實(shí)驗(yàn)環(huán)境云平臺(tái)上的實(shí)驗(yàn)與分析，他們得到結(jié)論：在虛擬機(jī)上運(yùn)行的時(shí)間敏感型程序確實(shí)會(huì)在一定程度上受到其同駐虛擬機(jī)上運(yùn)行程序的干擾，根據(jù)競(jìng)爭(zhēng)資源的不同，其受影響的程度也不同，其中受干擾最明顯的是磁盤資源——在同駐虛擬機(jī)的干擾下，磁盤密集型程序的運(yùn)行效率下跌幅度接近 75%。下面分別從 CPU、磁盤和網(wǎng)絡(luò)三種資源干擾角度分析。

2.1.1 CPU 資源

在同一臺(tái)物理機(jī)器上運(yùn)行的虛擬機(jī)共享 CPU資源。每個(gè)虛擬機(jī)創(chuàng)建時(shí)，VMM 都會(huì)為其分配一個(gè)或多個(gè)虛擬 CPU，即 VCPU，并且同時(shí)創(chuàng)建的虛擬機(jī)數(shù)量可以大于物理 CPU 核心的數(shù)量。VMM 支持靈活的 VCPU 分配方案，可以將VCPU 與物理 CPU 的任意一個(gè)核心進(jìn)行綁定，不同虛擬機(jī)的 VCPU 也可以共享同一個(gè)物理 CPU核心［32-35］。

針對(duì) CPU 資源的干擾，研究者［18］啟動(dòng)多個(gè)同駐的虛擬機(jī)實(shí)例，并在其中一個(gè)實(shí)例上運(yùn)行CPU 密集型測(cè)試程序：只執(zhí)行浮點(diǎn)數(shù)運(yùn)算的線程，不執(zhí)行輸入/輸出（Input/Outpit，I/O）操作，并且每 5 分鐘記錄一次測(cè)試程序的運(yùn)行時(shí)間。經(jīng)驗(yàn)證，測(cè)試程序的運(yùn)行時(shí)間分布較為分散，運(yùn)行時(shí)間出現(xiàn)較大的波動(dòng)，從而可以說(shuō)明 VMM 分配給該虛擬機(jī)的 CPU 資源發(fā)生了變化，而這正是由其他同駐虛擬機(jī)上的負(fù)載變化導(dǎo)致的。

2.1.2 磁盤資源

每個(gè)虛擬機(jī)都有一個(gè)虛擬的磁盤，這些虛擬的磁盤共享實(shí)際的物理磁盤，而且 VMM 控制著每個(gè)虛擬機(jī)對(duì)磁盤的 I/O 請(qǐng)求，但是目前的虛擬機(jī)技術(shù)（如 Xen）還不支持磁盤資源的精確分配［35］。因此，某個(gè)虛擬機(jī)如果過(guò)度或惡意使用磁盤操作，就會(huì)干擾與其同駐的虛擬機(jī)磁盤 I/O 操作。

針對(duì)磁盤資源的干擾，研究者［18，30］啟動(dòng)多個(gè)同駐的虛擬機(jī)實(shí)例，并在其中一個(gè)實(shí)例上運(yùn)行磁盤 I/O 密集型的測(cè)試程序，測(cè)試兩種情形：（1）測(cè)試程序流式讀取/寫入磁盤 5 MB 大小的文件；（2）測(cè)試程序隨機(jī)讀取/寫入一個(gè) 1 KB 大小的磁盤塊，每 5 分鐘記錄一次測(cè)試程序的運(yùn)行時(shí)間。經(jīng)驗(yàn)證，無(wú)論是流式的讀寫大規(guī)模磁盤數(shù)據(jù)，還是隨機(jī)的讀寫小塊數(shù)據(jù)，測(cè)試程序的執(zhí)行時(shí)間都呈現(xiàn)出分散的狀態(tài)，尤其以寫數(shù)據(jù)時(shí)最為明顯。

2.1.3 網(wǎng)絡(luò)資源

同駐的虛擬機(jī)也共享物理主機(jī)上的網(wǎng)絡(luò)資源，因?yàn)樗鼈兊木W(wǎng)絡(luò)通信都是經(jīng)由 VMM 管理的網(wǎng)橋連接到外部的物理網(wǎng)卡。VMM 提供一種網(wǎng)絡(luò)帶寬管理工具——tc，通過(guò)它可以控制每個(gè)虛擬機(jī)可用的最大網(wǎng)絡(luò)帶寬，嚴(yán)格限制每個(gè)虛擬機(jī)只能使用已分配的帶寬；也可以對(duì)帶寬進(jìn)行靈活設(shè)置，即一旦某個(gè)虛擬機(jī)需要的帶寬增加而其他虛擬機(jī)需要的帶寬較小時(shí)，可以將分配給其他虛擬機(jī)的帶寬再分配［32，35］。

針對(duì)網(wǎng)絡(luò)資源的干擾，研究者［18，31］在實(shí)驗(yàn)平臺(tái)中啟動(dòng)多個(gè)同駐虛擬機(jī)實(shí)例，其中一個(gè)部署游戲服務(wù)器，同時(shí)在外部運(yùn)行一個(gè)收集游戲服務(wù)器時(shí)延的應(yīng)用程序 qstat，這里的服務(wù)器時(shí)延只和網(wǎng)絡(luò)狀況有關(guān)，統(tǒng)計(jì)的是不同干擾條件下的平均網(wǎng)絡(luò)時(shí)延和超時(shí)丟包率，如表 1 所示。當(dāng)其他同駐虛擬機(jī)也在運(yùn)行網(wǎng)絡(luò)相關(guān)程序時(shí)，部署的游戲服務(wù)器的網(wǎng)絡(luò)時(shí)延明顯增加，同時(shí)也出現(xiàn)了一定的超時(shí)丟包率。其中 tc 工具采取的網(wǎng)絡(luò)帶寬控制策略不同也會(huì)對(duì)網(wǎng)絡(luò)時(shí)延和超時(shí)幾率有一定影響：當(dāng)采用嚴(yán)格的帶寬分配機(jī)制時(shí)，時(shí)延較低，但超時(shí)丟包率較高；當(dāng)采用靈活的帶寬分配機(jī)制時(shí)，超時(shí)丟包率較低，但時(shí)延較高。

表1 網(wǎng)絡(luò)資源干擾Table 1 Network Resource Interference

2.2 LLC 隱蔽通道/側(cè)信道

云平臺(tái)中隱蔽通道/側(cè)信道也發(fā)生在虛擬機(jī)同駐的條件下。Osvik 和 Shamir 等［36，37］在 2006年以 AES 為例，分析了利用高速緩存的隱蔽通道/側(cè)信道攻擊和對(duì)抗方案，這種通道在云平臺(tái)中依然存在，但是由于云平臺(tái)存在更復(fù)雜的影響因素，如 CPU 核心遷移、粗粒度的調(diào)度算法、兩級(jí)內(nèi)存映射以及其他虛擬機(jī)的干擾，使得該通道實(shí)現(xiàn)起來(lái)難度更大也更復(fù)雜。

美國(guó)加州大學(xué)圣迭戈分校的 Ristenpart 等［17］最早提出了云平臺(tái)中基于最低級(jí)高速緩存（Last Level Cache，LLC）的虛擬機(jī)間隱蔽通道/側(cè)信道。但他們只是簡(jiǎn)單討論了該隱蔽通道/側(cè)信道的構(gòu)造以及可能帶來(lái)的威脅，并沒(méi)有對(duì)其進(jìn)行詳細(xì)的分析。美國(guó)密歇根大學(xué)的 Xu 與 AT&T 研究實(shí)驗(yàn)室的 Joshi 等以 L2 Cache為例，詳細(xì)給出了其在云平臺(tái)下的實(shí)現(xiàn)方案［20］，測(cè)量了帶寬，并評(píng)估該通道可對(duì)云平臺(tái)造成實(shí)際危害。除了在 X86 架構(gòu)上的研究，德國(guó)弗勞恩霍夫研究所的 Wei? 等［29］也研究了基于嵌入式 ARM 架構(gòu)的虛擬化平臺(tái)中的Cache 隱蔽通道/側(cè)信道問(wèn)題。

2.2.1 通信方案

LLC 隱蔽通道的通信方案［17］：首先，將所有的 Cache Line 分為兩個(gè)子集合——集合 a 和集合 b。當(dāng)發(fā)送方發(fā)送 1 bit 數(shù)據(jù)時(shí)，發(fā)送方訪問(wèn)與某個(gè) Cache Line 子集合相映射的內(nèi)存地址，這樣將會(huì)使得與該子集合相關(guān)的接收方 Cache 內(nèi)容從Cache Line 中擠出，而與另一子集合相關(guān)的部分不變。然后，接收方分別訪問(wèn)與這兩個(gè)子集合相映射的內(nèi)存地址，通過(guò)比較訪問(wèn)時(shí)間的差別對(duì)發(fā)送的信息進(jìn)行解碼。如果訪問(wèn)子集合 a 的時(shí)間明顯大于訪問(wèn)子集合 b 的時(shí)間，則發(fā)送的是 1，否則發(fā)送的是 0。最初實(shí)測(cè)該通道的帶寬僅有 0.2 bps，這意味著要傳送一個(gè) 2 048 位的 RSA 私鑰（實(shí)際占用 1743 字節(jié)）需要花費(fèi) 20 個(gè)小時(shí)之久。Xu 等［21］改進(jìn)了通信方案，使其在實(shí)驗(yàn)環(huán)境下的理論帶寬可以達(dá)到 262.47 bps，這意味著傳輸一個(gè) 2 048 位的 RSA 私鑰僅需 53 秒。

2.2.2 應(yīng)用場(chǎng)景

在云平臺(tái)上，LLC 側(cè)信道有多種應(yīng)用場(chǎng)景。例如，利用 LLC 探測(cè)同駐虛擬機(jī)的網(wǎng)絡(luò)負(fù)載狀況［17］、基于 LLC 側(cè)信道探測(cè)同駐的虛擬機(jī)［23］、結(jié)合 LLC 側(cè)信道實(shí)現(xiàn) Keystroke Timing 攻擊［38］等。

前兩種將在 2.5 和 3.3 節(jié)中介紹，這里重點(diǎn)介紹利用 L2 Cache 側(cè)信道實(shí)現(xiàn)的 Keystroke timing 攻擊。該攻擊的基本思想如下：首先，攻擊者利用 L2 Cache 側(cè)信道技術(shù)，探測(cè)由同駐受害者鍵入 SSH 終端密碼等敏感信息而引起的Cache 變化；然后，攻擊者利用這些信息恢復(fù)出受害者鍵入的敏感信息。具體地，攻擊者首先申請(qǐng)一塊和 Cache 大小相同的內(nèi)存，并通過(guò)訪問(wèn)這個(gè)內(nèi)存填充 L2 Cache，之后不斷訪問(wèn)當(dāng)前物理機(jī)器的 Cache，當(dāng)同駐虛擬機(jī)上的受害者鍵入敏感信息到 shell 時(shí)，攻擊者就可以探測(cè)到自己訪問(wèn)Cache 的時(shí)間出現(xiàn)了變化，即探測(cè)到了 Keystroke timing。這樣攻擊者就可以利用已有的 Keystroke timing 攻擊技術(shù)恢復(fù)受害者鍵入的信息。該方案基于這樣一個(gè)假設(shè)：在一臺(tái)物理機(jī)器上，Cache負(fù)載上出現(xiàn)的某個(gè)峰值就意味著用戶向同駐虛擬機(jī)的 SSH 終端鍵入了一個(gè)單詞或者命令。

2.3 拒絕服務(wù)攻擊

虛擬機(jī)同駐安全威脅還包括基于共享資源的拒絕服務(wù)（Denial of Service，DoS）。由于在虛擬化環(huán)境下，運(yùn)行在同一臺(tái)物理機(jī)器上的虛擬機(jī)共享底層物理資源（如 CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等），若攻擊者試圖繞過(guò) VMM 的管理，就可以使得受害者虛擬機(jī)無(wú)法正常使用物理資源，破壞同駐虛擬機(jī)的可用性，達(dá)到拒絕服務(wù)攻擊目的。本文將討論針對(duì)網(wǎng)絡(luò)通信的拒絕服務(wù)攻擊［26］以及針對(duì) VCPU 的拒絕服務(wù)攻擊［21］。

2.3.1 網(wǎng)絡(luò)通信拒絕服務(wù)攻擊

美國(guó)孟菲斯大學(xué)的 Bedi 等［28］研究同駐虛擬機(jī)網(wǎng)絡(luò)資源的共享問(wèn)題，提出了一種通過(guò)阻塞網(wǎng)絡(luò)傳輸隊(duì)列達(dá)到拒絕服務(wù)攻擊的方案，并提出了一種基于博弈論（Game Theoretic）的防御機(jī)制。

圖2 描述了 Xen 的網(wǎng)絡(luò)架構(gòu)［35］，其上虛擬機(jī)在通過(guò)網(wǎng)卡（Network Interface Card，NIC）使用網(wǎng)絡(luò)時(shí)均共享同一個(gè) T/R Queue，而 T/R Queue則易受網(wǎng)絡(luò)阻塞的影響，會(huì)引發(fā)潛在的拒絕服務(wù)攻擊。具體方案如下［28］：攻擊者通過(guò)部署一系列與受害者同駐的惡意虛擬機(jī)耗盡物理機(jī)的網(wǎng)絡(luò)帶寬，這些惡意虛擬機(jī)不斷使用網(wǎng)絡(luò)發(fā)送無(wú)意義的網(wǎng)絡(luò)數(shù)據(jù)，由于受害者虛擬機(jī)與惡意虛擬機(jī)共享同一條 T/R Queue，受害者正常的網(wǎng)絡(luò)通信就會(huì)被占用，無(wú)法使用 T/R Queue 進(jìn)行通信。由于每一臺(tái)惡意的虛擬機(jī)占用的帶寬相對(duì)并不高，使得云服務(wù)供應(yīng)商很難檢測(cè)到這種網(wǎng)絡(luò)通信拒絕服務(wù)攻擊。

圖2 Xen 虛擬化網(wǎng)絡(luò)架構(gòu)Fig. 2 Virtualized network architecture of Xen

利用博弈論對(duì)該問(wèn)題進(jìn)行建模，可實(shí)現(xiàn)一種防御方案，該模型中有兩個(gè)角色：攻擊者和受害者。攻擊者的動(dòng)作集包括選擇實(shí)施攻擊的虛擬機(jī)數(shù)量以及每臺(tái)虛擬機(jī)攻擊時(shí)占用的網(wǎng)絡(luò)帶寬；受害者動(dòng)作集是設(shè)定防火墻的閾值來(lái)防止惡意虛擬機(jī)對(duì)網(wǎng)絡(luò)通信的阻塞。一旦某臺(tái)虛擬機(jī)使用的網(wǎng)絡(luò)帶寬超過(guò)閾值，特權(quán)虛擬機(jī)（Domain 0）就中斷其網(wǎng)絡(luò)通信，目的是使 Domain 0 能夠選取最優(yōu)閾值以中斷掉盡可能多的惡意虛擬機(jī)網(wǎng)絡(luò)帶寬，保護(hù)合法用戶對(duì)網(wǎng)絡(luò)帶寬的正常使用。

2.3.2 VCPU 拒絕服務(wù)攻擊

Xen 默認(rèn)采用基于額度的 VCPU 調(diào)度算法（Credit Scheduler）［32-34］。它可以應(yīng)用于對(duì)稱多處理器（Symmetric Multi Peocessor，SMP）系統(tǒng)中，也可以支持連續(xù)工作和斷續(xù)工作兩種模式。美國(guó)東北大學(xué)的 Zhou 等［21］分析了 Xen 的 Credit 調(diào)度算法，并發(fā)現(xiàn)了其存在的一個(gè)漏洞，利用此漏洞可構(gòu)造對(duì)同駐虛擬機(jī)的 VCPU 拒絕服務(wù)攻擊。

Credit 調(diào)度算法［32-34］是一種按比例公平共享的非搶占式調(diào)度算法。它將各個(gè) VCPU 分為 under 隊(duì)列和 over 隊(duì)列，只調(diào)度 under 隊(duì)列中的 VCPU。最開始，所有的 VCPU都在 under 隊(duì)列，每個(gè)虛擬機(jī)的初始 credit 為其對(duì)應(yīng)的 weight 值。每當(dāng)VCPU 被調(diào)度時(shí)，其對(duì)應(yīng)虛擬機(jī)的 credit 就會(huì)減少，當(dāng) credit 為負(fù)數(shù)時(shí)，它被放入 over 隊(duì)列。VCPU 每執(zhí)行一個(gè)調(diào)度周期（10 ms），credit 值都需要重新計(jì)算，并且一次最多可以運(yùn)行 3 個(gè)周期，即 30 ms。之后無(wú)論 credit 是否為正，都要讓出物理 CPU。同時(shí)，為了解決響應(yīng)延遲時(shí)間過(guò)長(zhǎng)的問(wèn)題，credit 調(diào)度算法加入了一個(gè) BOOST 狀態(tài)，處于 BOOST 態(tài)的虛擬機(jī) VCPU 具有最高的調(diào)度優(yōu)先級(jí)。

上述 Credit 算法存在兩個(gè)問(wèn)題［21］：（1）算法的粒度太粗。每 10 ms 調(diào)度一次，只在調(diào)度時(shí)進(jìn)行檢測(cè)，在運(yùn)行期間不做檢測(cè)。如果一個(gè) VCPU被調(diào)度上物理 CPU，在 10 ms 內(nèi)時(shí)放棄運(yùn)行（被I/O 阻塞或其他原因），則在 10 ms 結(jié)束時(shí)調(diào)度器沒(méi)有檢測(cè)到該 VCPU，不會(huì)減少其額度。（2）Credit 調(diào)度器無(wú)法區(qū)別正在運(yùn)行的 VCPU 是主動(dòng)讓出物理 CPU 還是被 I/O 阻塞，在這個(gè) VCPU被喚醒時(shí)，都會(huì)被設(shè)置 BOOST 標(biāo)志，獲得最高調(diào)度優(yōu)先級(jí)。圖 3 為利用上述問(wèn)題的拒絕服務(wù)攻擊流程。其中惡意虛擬機(jī)運(yùn)行一個(gè) VCPU 攻擊程序，該程序一旦被調(diào)度上物理 CPU，在運(yùn)行10－ε ms 后調(diào)用 Halt（）函數(shù)使自己運(yùn)行 idle 進(jìn)程，主動(dòng)讓出物理 CPU，使調(diào)度器調(diào)度其他同駐虛擬機(jī)的 VCPU 在物理 CPU 上運(yùn)行。在該運(yùn)行周期快結(jié)束之前主動(dòng)喚醒攻擊程序，由 Xen 置 BOOST 位而獲得最高調(diào)度優(yōu)先級(jí)，下一個(gè)調(diào)度時(shí)刻將再次被調(diào)度上物理 CPU，而且不會(huì)被減少額度。如此反復(fù)，攻擊程序所在的 VCPU 可以一直獲得最高調(diào)度優(yōu)先級(jí)，在每個(gè)運(yùn)行周期都運(yùn)行 10－ε ms，而物理機(jī)器上其他所有虛擬機(jī)只能分享剩下的 ε ms，便實(shí)現(xiàn)了對(duì)同駐虛擬機(jī)進(jìn)行VCPU 拒絕服務(wù)攻擊。

圖3 VCPU 拒絕服務(wù)攻擊Fig. 3 Scheme of VCPU DoS attack

2.4 資源釋放攻擊

來(lái)自美國(guó)威斯康星大學(xué)麥迪遜分校的Varadarajan 等［19］在分析同駐虛擬機(jī)資源沖突的基礎(chǔ)上，提出了一種新的攻擊類型，即資源釋放攻擊（Resource-Freeing Attack），通過(guò)改變受害者虛擬機(jī)上的資源使用狀況后釋放其資源給同駐攻擊者的虛擬機(jī)使用。該方案在實(shí)驗(yàn)環(huán)境下提升了攻擊程序 60% 的性能，在亞馬遜 EC2 環(huán)境中也獲得 13% 性能提升。

2.4.1 攻擊原理

資源釋放攻擊［19］要求：（1）使得受害者虛擬機(jī)對(duì)某個(gè)資源的使用達(dá)到瓶頸；（2）改變受害者的資源使用狀況，使得受害者的絕大部分處理時(shí)間都花費(fèi)在瓶頸資源上，無(wú)法使用其他資源。

同駐虛擬機(jī)間資源的爭(zhēng)用和干擾是實(shí)現(xiàn)資源釋放攻擊的基礎(chǔ)。在同一個(gè)物理機(jī)器上可能會(huì)造成資源爭(zhēng)用的資源有如下幾類：CPU、Cache、磁盤、內(nèi)存以及網(wǎng)絡(luò)。經(jīng)實(shí)驗(yàn)發(fā)現(xiàn)，磁盤資源和LLC 在發(fā)生競(jìng)爭(zhēng)時(shí)受到的干擾較為明顯。其中，LLC 資源在同駐虛擬機(jī)運(yùn)行網(wǎng)絡(luò)密集型程序時(shí)受到的干擾最大，所以資源釋放攻擊選取的攻擊程序?yàn)長(zhǎng)LC 密集型應(yīng)用程序，而受害者為運(yùn)行網(wǎng)絡(luò)密集型應(yīng)用程序的虛擬機(jī)。資源釋放攻擊通過(guò)修改受害者資源使用情況，使其處于處理網(wǎng)絡(luò)請(qǐng)求的瓶頸狀態(tài)，從而提升 LLC 密集型攻擊程序的性能。

2.4.2 攻擊過(guò)程

圖4 中的 beneficiary 指在攻擊虛擬機(jī)上運(yùn)行的 LLC 密集型程序；victim 指在受害者虛擬機(jī)上運(yùn)行的 Apache Web Server；load generator 指處于物理節(jié)點(diǎn)外，向受害者虛擬機(jī)發(fā)送靜態(tài)網(wǎng)頁(yè)請(qǐng)求的代理終端；helper 指處于物理節(jié)點(diǎn)外，向受害者虛擬機(jī)發(fā)送公共網(wǎng)關(guān)接口（Common Gateway Interface，CGI）腳本請(qǐng)求的代理終端。由于受害者虛擬機(jī)在處理靜態(tài)網(wǎng)頁(yè)請(qǐng)求時(shí)搶占了beneficiary 與 victim 共享的 LLC，使得 beneficiary程序執(zhí)行時(shí)間顯著增加，程序性能下降。因此，攻擊者通過(guò)使用外部程序 helper 向受害者虛擬機(jī)發(fā)送 CGI 腳本請(qǐng)求，使受害者處理 CGI 請(qǐng)求時(shí)使用的 CPU 資源達(dá)到瓶頸狀態(tài)，導(dǎo)致其所能響應(yīng)的、由 load generator 產(chǎn)生的正常網(wǎng)頁(yè)請(qǐng)求效率顯著下降，從而減少了對(duì)物理機(jī)器上 LLC 資源的使用。由于受害者虛擬機(jī)資源使用狀況的轉(zhuǎn)移，攻擊程序 beneficiary 的性能就得以提高。

圖4 資源釋放攻擊Fig. 4 Scheme of resource-freeing attack

2.5 同駐虛擬機(jī)負(fù)載探測(cè)

同駐虛擬機(jī)的負(fù)載探測(cè)也存在著一些安全隱患，如可以估算受害者虛擬機(jī)中網(wǎng)頁(yè)服務(wù)器的訪問(wèn)用戶量或探測(cè)哪一個(gè)頁(yè)面被頻繁訪問(wèn)［17］。通常這些信息是私密的，如果攻擊者與受害者存在商業(yè)競(jìng)爭(zhēng)關(guān)系，那么泄露這些信息將會(huì)造成嚴(yán)重危害。目前虛擬機(jī)負(fù)載探測(cè)方法主要有兩種：基于Cache 側(cè)信道的負(fù)載探測(cè)［17，20］和通過(guò)網(wǎng)絡(luò) TCP 會(huì)話的負(fù)載探測(cè)［22］。

2.5.1 基于 Cache 側(cè)信道的探測(cè)

利用 2.2 節(jié) Cache 側(cè)信道，可以探測(cè)同駐虛擬機(jī)的負(fù)載狀況。它通過(guò)測(cè)量自己訪問(wèn) Cache 映射地址的時(shí)間估算出同駐虛擬機(jī)的 HTTP 通信帶寬，具體方法為［17，20］：建立兩臺(tái)同駐虛擬機(jī)，在一臺(tái)攻擊者虛擬機(jī)上執(zhí)行 Cache 測(cè)量程序，在另一臺(tái)受害者虛擬機(jī)上運(yùn)行一個(gè) Web Server；外部用戶向 Web Server 發(fā)送不同速率的 HTTP 請(qǐng)求，分別為每分鐘 0 次、50 次、100 次、200 次等。實(shí)驗(yàn)表明：攻擊者虛擬機(jī)上測(cè)量到的 Cache 映射地址的訪問(wèn)時(shí)間與 HTTP 發(fā)送請(qǐng)求頻率有明顯的關(guān)系，這樣便可以估算出受害者虛擬機(jī)的網(wǎng)絡(luò)負(fù)載狀況。

2.5.2 通過(guò)網(wǎng)絡(luò) TCP 會(huì)話的探測(cè)

通過(guò)網(wǎng)絡(luò) TCP 會(huì)話的同駐水印技術(shù)［22］（見(jiàn)3.3 節(jié)），可以利用外部應(yīng)用程序和受害者 Web Server 之間 TCP 會(huì)話的通信量來(lái)估算其負(fù)載狀況。具體方法如下：首先，攻擊者利用同駐水印技術(shù)確認(rèn)自己的虛擬機(jī)與受害者虛擬機(jī)運(yùn)行在同一個(gè)物理平臺(tái)上；然后，攻擊者自己也運(yùn)行 Web Server，并在平臺(tái)外部開啟一個(gè)應(yīng)用程序，這個(gè)應(yīng)用程序同時(shí)與攻擊者和受害者虛擬機(jī)初始化一個(gè) TCP 會(huì)話，外部程序通過(guò)測(cè)量 TCP 會(huì)話流，能夠得到其分別與攻擊者和受害者通信帶寬的比例，設(shè)為 R。除非這兩臺(tái)虛擬機(jī)自身負(fù)載出現(xiàn)變化，物理平臺(tái)上其他虛擬機(jī)的負(fù)載變化并不會(huì)影響 R，因?yàn)槠渌摂M機(jī)對(duì)這兩個(gè)虛擬機(jī)的影響效果是等同的；網(wǎng)絡(luò)阻塞的影響也可以忽略，因?yàn)楣粽吆褪芎φ吖蚕硗痪W(wǎng)絡(luò)路徑，R 保持不變。這樣，由于攻擊者的負(fù)載由攻擊者控制并保持恒定，比例 R 的波動(dòng)就表明受害者虛擬機(jī)上的負(fù)載出現(xiàn)了變化。

3 虛擬機(jī)同駐探測(cè)技術(shù)

云平臺(tái)中的虛擬機(jī)同駐探測(cè)，既可以指攻擊者通過(guò)已知的探測(cè)方法確認(rèn)自己的虛擬機(jī)與受害者虛擬機(jī)在同一個(gè)物理平臺(tái)上運(yùn)行，也可以指某租戶通過(guò)已知的探測(cè)手段確認(rèn)是否與其他租戶的虛擬機(jī)在同一臺(tái)物理機(jī)器上運(yùn)行。虛擬機(jī)同駐探測(cè)技術(shù)主要有三種：（1）基于網(wǎng)絡(luò)信息的同駐探測(cè)技術(shù)［17］；（2）同駐水印技術(shù)（Co-Residency Watermarking ）［22］；（3）利用 L2 Cache 的 HomeAlone［23］。

3.1 基于網(wǎng)絡(luò)信息的同駐探測(cè)技術(shù)

通過(guò)網(wǎng)絡(luò)信息探測(cè)技術(shù)［17］，如果兩個(gè)虛擬機(jī)具有相同的 Domain 0 的 IP 地址，或具有很短的網(wǎng)絡(luò)包往返時(shí)間（Round-Trip Times，RTTs），或具有數(shù)字上接近的內(nèi)部 IP 地址，則可說(shuō)明這兩個(gè)虛擬機(jī)是同駐的。

對(duì)于方法（1），在 Xen 中，每個(gè) Guest 虛擬機(jī)在進(jìn)行網(wǎng)絡(luò)通信時(shí)的第一跳地址是 Domain 0 的 IP 地址，攻擊者可以據(jù)此確定當(dāng)前物理平臺(tái)上 Domain 0 的 IP 地址。此外，攻擊者可以利用外部的一臺(tái)虛擬機(jī)向受害者虛擬機(jī)發(fā)送一個(gè) TCP SYN 追蹤路由，并探測(cè)最后一跳的 IP 地址，通過(guò)它即可獲得受害者虛擬機(jī)所在物理平臺(tái)上Domain 0 的 IP 地址。若后者與前者 IP 地址相同，就說(shuō)明這兩個(gè)虛擬機(jī)實(shí)例可能是同駐的。

對(duì)于方法（2），運(yùn)行在同一物理平臺(tái)上的一個(gè)虛擬機(jī)向另一個(gè)虛擬機(jī)發(fā)送網(wǎng)絡(luò)包時(shí)，由于不需云平臺(tái)路由，只需物理機(jī)內(nèi)部路由，所以網(wǎng)絡(luò)包的 RTTs 相比非同駐情況短很多。因此，攻擊者可以通過(guò)向不同的虛擬機(jī)多次發(fā)送網(wǎng)絡(luò)包，并記錄每次探測(cè)的平均包往返時(shí)間，其中平均包往返時(shí)間最短的那個(gè)虛擬機(jī)就很有可能是與攻擊者同駐。

對(duì)于方法（3），由于每個(gè)虛擬機(jī)實(shí)例創(chuàng)建時(shí)都會(huì)根據(jù)如下算法分配到一個(gè)內(nèi)部 IP 地址：具有相同 Domain 0 IP 地址的虛擬機(jī)實(shí)例的內(nèi)部 IP地址按照一定線性遞增順序進(jìn)行分配。由于具有相同 Domain 0 IP 地址的虛擬機(jī)是同駐的，這樣在數(shù)字上較為接近的內(nèi)部 IP 地址的虛擬機(jī)可能是同駐的。

實(shí)際上，為了提高準(zhǔn)確率，通常綜合利用以上三種方法：先利用方法（3）比較兩個(gè)虛擬機(jī)實(shí)例的內(nèi)部 IP 地址，若 IP地址數(shù)字接近，再利用方法（1）確定虛擬機(jī)的 Domain 0 IP 地址，若相同，則說(shuō)明兩個(gè)虛擬機(jī)同駐。為了增加探測(cè)的準(zhǔn)確性，還可以進(jìn)一步利用方法（2）測(cè)量虛擬機(jī)間的網(wǎng)絡(luò)包往返時(shí)間。

3.2 同駐水印技術(shù)

在實(shí)際云平臺(tái)中，云服務(wù)供應(yīng)商可以通過(guò)多種方法阻止攻擊者利用網(wǎng)絡(luò)信息進(jìn)行同駐探測(cè)，如設(shè)置 Domain 0 對(duì)外部發(fā)起的路由追蹤不作應(yīng)答，在創(chuàng)建虛擬機(jī)實(shí)例時(shí)隨機(jī)地分配內(nèi)部 IP 地址，利用虛擬 LAN 隔離不同的租戶等。這樣就不得不去尋找更為有效的同駐探測(cè)方法，美國(guó)俄勒岡大學(xué) Bates 等［22］利用同駐虛擬機(jī)共用網(wǎng)卡的特性提出了一種更為有效的同駐探測(cè)方案——同駐水印技術(shù)。它是基于物理網(wǎng)卡多路復(fù)用帶來(lái)的網(wǎng)絡(luò)包延時(shí)問(wèn)題［39］提出的。具體地，進(jìn)行探測(cè)的虛擬機(jī)周期性地向目標(biāo)虛擬機(jī)的網(wǎng)絡(luò)包中注入水印標(biāo)記，干擾其正常網(wǎng)絡(luò)數(shù)據(jù)包的發(fā)送，之后通過(guò)測(cè)量收集目標(biāo)虛擬機(jī)的網(wǎng)絡(luò)包通信狀況，判斷自己是否與目標(biāo)虛擬機(jī)同駐。

假定 SERVER 是在云平臺(tái)中一個(gè)物理機(jī)器上運(yùn)行的虛擬機(jī)實(shí)例，F(xiàn)LOODER 是攻擊者為了同駐探測(cè)而創(chuàng)建的虛擬機(jī)實(shí)例，CLIENT 是在云平臺(tái)外運(yùn)行、與 FLOODER 串通好的代理終端。則探測(cè)方法如下：首先，CLIENT 與已知 IP 的SERVER 建立一個(gè) TCP 會(huì)話。接著，CLIENT 周期性地向 FLOODER 發(fā)送信號(hào)，F(xiàn)LOODER 接收到信號(hào)后去占用物理機(jī)器網(wǎng)卡，并向外發(fā)送無(wú)意義的 UDP 包。若 FLOODER 與 SERVER 是同駐的，由于它們對(duì)同一物理主機(jī)網(wǎng)卡的多路復(fù)用，就會(huì)對(duì)正常的 CLIENT-SERVER 網(wǎng)絡(luò)通信數(shù)據(jù)流帶來(lái)一定延時(shí)，這個(gè)延時(shí)即同駐水印。最后，通過(guò)收集 CLIENT-SERVER 每個(gè)時(shí)間間隔的網(wǎng)絡(luò)包數(shù)量，分析有水印時(shí)間間隔和無(wú)水印時(shí)間間隔收到網(wǎng)絡(luò)包的數(shù)量分布，可以判斷 FLOODER 與SERVER 是否同駐。

3.3 HomeAlone 技術(shù)

如 2.3 節(jié)所述，LLC 隱蔽通道/側(cè)信道應(yīng)用于秘密傳遞信息。但是，美國(guó)北卡羅來(lái)納大學(xué)和RSA 實(shí)驗(yàn)室的 Zhang 等［23，24］則將它用作防御方案，即租戶使用 HomeAlone［23］工具驗(yàn)證云服務(wù)提供商是否遵循了 SLA 協(xié)議，租戶是否獨(dú)占了某個(gè)物理平臺(tái)上的資源，而沒(méi)有讓其他租戶虛擬機(jī)與其同駐。

HomeAlone 通過(guò)讓租戶在其獨(dú)占物理機(jī)器上創(chuàng)建一些友好虛擬機(jī)實(shí)例（friendly VMs），并約定在某個(gè)時(shí)間周期內(nèi)，它們均不使用選定的Cache 區(qū)域映射地址，并測(cè)量該周期內(nèi) Cache 映射地址的訪問(wèn)時(shí)間，若發(fā)現(xiàn) Cache 使用狀況發(fā)生變化，則認(rèn)為有不期望的虛擬機(jī)（foe VM）與租戶的虛擬機(jī)發(fā)生同駐。該技術(shù)實(shí)現(xiàn)的難點(diǎn)在于準(zhǔn)確地區(qū)分 friendly VMs 與同駐 foe VMs 的 Cache 行為，以及保證 friendly VMs 性能不會(huì)降低。

HomeAlone 架構(gòu)如圖 5 所示，由三個(gè)子部件構(gòu)成：運(yùn)行在用戶態(tài)的 coordinator、運(yùn)行在內(nèi)核態(tài)的 address remapper 和 co-residency detector。HomeAlone 工具安裝在每個(gè) friendly VMs 中，僅需修改 friendly VMs 內(nèi)核，無(wú)需對(duì) hypervisor 修改或云服務(wù)供應(yīng)商支持。探測(cè)周期開始時(shí)，第一個(gè) coordinator（稱為 initiator）首先啟動(dòng)，并確定某個(gè)染色的 Cache 集（即在探測(cè)周期所有friendly VMs 都要減少訪問(wèn)的 Cache 區(qū)域），并將這條命令發(fā)送給其他 friendly VM 的 coordinator。其他coordinator 接收到命令后會(huì)調(diào)用 address remapper空出相應(yīng)的 Cache 集，并盡量少訪問(wèn)這個(gè)區(qū)域。一旦 address remapper 完成了 Cache 集的空出操作，coordinator 就向 initiator 發(fā)送確認(rèn)信息。Initiator 收到所有 coordinator 發(fā)回的確認(rèn)信息后創(chuàng)建一個(gè) token，并隨機(jī)選擇一個(gè) friendly VM，將這個(gè) token 發(fā)送給它。該 friendly VM（稱為token holder）調(diào)用 co-residency detector 進(jìn)行 Cache訪問(wèn)狀況的測(cè)量，Token holder 收集測(cè)量結(jié)果 r，并將 token 和 r 發(fā)送給另一個(gè) friendly VM，如此執(zhí)行 n 次之后，最后那個(gè)虛擬機(jī)對(duì)收集的結(jié)果進(jìn)行分析，并對(duì)物理平臺(tái)上是否存在同駐的 foe 虛擬機(jī)做出判斷。

圖5 HomeAlone 架構(gòu)Fig. 5 Architecture of HomeAlone

4 虛擬機(jī)同駐防御技術(shù)

虛擬機(jī)同駐可能破壞云平臺(tái)中數(shù)據(jù)的機(jī)密性和資源的可用性，會(huì)產(chǎn)生極大安全威脅問(wèn)題。為了有效應(yīng)對(duì)這類安全問(wèn)題，本節(jié)將從四個(gè)方面討論同駐防御技術(shù)：（1）加入安全機(jī)制防御云平臺(tái)中的 LLC 隱蔽通道/側(cè)信道；（2）采用斷續(xù)工作型調(diào)度策略增強(qiáng)同駐虛擬機(jī)之間的隔離性；（3）借鑒多核心處理器芯片系統(tǒng)（CMPs）實(shí)現(xiàn)防干擾的進(jìn)程調(diào)度算法；（4）硬件協(xié)同防御技術(shù)。

4.1 防御同駐虛擬機(jī)間隱蔽通道/側(cè)信道

2.3 節(jié)的分析已經(jīng)證明，云平臺(tái)中的 LLC 隱蔽通道/側(cè)信道會(huì)破壞多租戶虛擬機(jī)之間的隔離性。微軟公司的 Raj 等［27］針對(duì) Hyper-V［40］提出了兩種防御 LLC 隱蔽通道/側(cè)信道的資源管理方案：基于 Cache 的處理器分配策略以及基于Cache 的內(nèi)存頁(yè)染色技術(shù)。

4.1.1 基于 Cache 的處理器分配策略

SMP（Symmetric Multi-Processing）通常是在 package 層共享 LLC，而且許多云計(jì)算平臺(tái)的服務(wù)器都配置有多個(gè) package。這樣，可以利用 SMP 特性對(duì)虛擬機(jī)分配處理器核心，使它們互相不共享 Cache。具體做法如下：首先，根據(jù)LLC 的共享情況，將物理機(jī)上的處理器核心進(jìn)行分組，所有共享同一 LLC 的處理器核心放入一組；然后，分配算法在為某個(gè)虛擬機(jī)分配物理CPU 時(shí)，會(huì)從還未分配給任何其同駐虛擬機(jī)的組中選擇一個(gè)處理器核心進(jìn)行分配，并且這個(gè)組中的其他處理器核心也只允許分配給這個(gè)虛擬機(jī)的其他 VCPU。

通過(guò)該方案，同駐的虛擬機(jī)不再共享 LLC，也就不會(huì)存在 LLC 隱蔽通道/側(cè)信道的安全問(wèn)題。但是這種方案也存在一個(gè)致命的缺陷，即物理平臺(tái)的 CPU 資源并沒(méi)有得到充分利用。比如一個(gè)虛擬機(jī)申請(qǐng)的 VCPU 小于某個(gè)組中的處理器核心數(shù)量時(shí)，那些未分配的處理器核心將永遠(yuǎn)得不到使用。

4.1.2 基于 Cache 的內(nèi)存頁(yè)染色技術(shù)

內(nèi)存頁(yè)染色技術(shù)［42，43］是一種軟件方法，它通過(guò)控制應(yīng)用程序使用的物理內(nèi)存來(lái)間接保證同駐虛擬機(jī)不共享 Cache 集。內(nèi)存頁(yè)染色的顏色數(shù)量通常是由 Cache Line 的大小乘以 Cache 集的數(shù)量再除以內(nèi)存頁(yè)大小計(jì)算得到。在虛擬化環(huán)境中，hypervisor 對(duì)虛擬機(jī)內(nèi)存頁(yè)面的分配會(huì)影響虛擬機(jī)中應(yīng)用程序?qū)?Cache 的使用?；?Cache 的內(nèi)存頁(yè)染色技術(shù)，通過(guò)隔離內(nèi)存頁(yè)的顏色集來(lái)隔離共享 LLC 處理器核心對(duì) Cache 的使用。具體來(lái)說(shuō)就是修改并控制 virtual-to-physical 內(nèi)存映射表，隔離同一個(gè)物理平臺(tái)上不同虛擬機(jī)對(duì)內(nèi)存頁(yè)的訪問(wèn)（一個(gè)虛擬機(jī)只能訪問(wèn)某一種顏色的內(nèi)存頁(yè)），并間接隔離虛擬機(jī)對(duì) Cache 集的使用。

該方法并不會(huì)造成 CPU 資源的浪費(fèi)，但有可能會(huì)引起內(nèi)存資源的浪費(fèi)以及虛擬機(jī)性能的下降。比如一臺(tái)虛擬機(jī)并沒(méi)有完全使用分配給它的某一種顏色的內(nèi)存頁(yè)，屬于該顏色的其他內(nèi)存頁(yè)也不會(huì)再分配給其他的虛擬機(jī)，那么這些內(nèi)存頁(yè)面就會(huì)一直得不到使用。另外，一臺(tái)虛擬機(jī)的行為可能與 Cache 集的分布不符，該方案可能會(huì)使該虛擬機(jī)性能下降。

4.2 防同駐的斷續(xù)工作型調(diào)度策略

在虛擬化技術(shù)中，資源的調(diào)度策略［32］共分為兩種：一種是連續(xù)工作型調(diào)度策略；另一種是斷續(xù)工作型調(diào)度策略。其中連續(xù)工作型調(diào)度策略指的是 VMM 在分配物理資源時(shí)盡量做到對(duì)物理資源的充分利用。當(dāng)某個(gè)虛擬機(jī)對(duì)物理資源的使用超過(guò)分配給它的量時(shí)，調(diào)度器將已經(jīng)分配給其他相對(duì)空閑的虛擬機(jī)資源調(diào)度給這個(gè)虛擬機(jī)使用。斷續(xù)工作型調(diào)度策略指的是 VMM 在分配物理資源時(shí)支持精確的資源分配。調(diào)度器通過(guò)給每個(gè)虛擬機(jī)設(shè)置閾值限制其對(duì)資源的使用，即使某個(gè)虛擬機(jī)相對(duì)空閑，調(diào)度器也不會(huì)將屬于該虛擬機(jī)的資源調(diào)度給另外一個(gè)繁忙的虛擬機(jī)使用。

在防御同駐虛擬機(jī)導(dǎo)致網(wǎng)絡(luò)通信拒絕服務(wù)攻擊時(shí)［28］，可通過(guò)設(shè)置網(wǎng)絡(luò)防火墻限制每個(gè)虛擬機(jī)實(shí)例使用帶寬，一旦某個(gè)虛擬機(jī)網(wǎng)絡(luò)帶寬超過(guò)設(shè)定的閾值，VMM 就中斷該虛擬機(jī)的網(wǎng)絡(luò)通信，阻止攻擊者對(duì)同駐虛擬機(jī)的拒絕服務(wù)攻擊。在防御資源釋放攻擊時(shí)［19］，若采用斷續(xù)工作型的物理資源分配方案，受害者虛擬機(jī)對(duì)某個(gè)資源的使用就不會(huì)達(dá)到瓶頸狀態(tài)，這樣攻擊者便不能將受害者的 CPU 時(shí)間集中于處理該瓶頸資源并實(shí)施資源釋放攻擊。由此可見(jiàn)，采用斷續(xù)工作型調(diào)度策略可以明顯提高同駐虛擬機(jī)間的隔離性，削弱同駐威脅。但是，由于它嚴(yán)格限制虛擬機(jī)對(duì)物理資源的使用，必然存在某些資源未充分利用的缺陷。在開放云平臺(tái)的虛擬機(jī)資源分配過(guò)程中，人們正在研究可以防止同駐攻擊的安全調(diào)度策略［44-46］。

4.3 防同駐與 CMP 進(jìn)程隔離技術(shù)

針對(duì) CMP 上多道程序運(yùn)行的隔離性和性能提高的調(diào)度算法研究［47，48］對(duì)減少虛擬機(jī)同駐威脅提供了參考。美國(guó)西蒙弗雷澤大學(xué)的 Fedorova 和哈佛大學(xué) Seltzer 等［47］提出了一種新的 Cache-Fair調(diào)度算法，保證每個(gè)程序公平分配 Cache，幾乎消除了同駐程序間性能干擾，提高了多道程序運(yùn)行的隔離性。美國(guó)康奈爾大學(xué)的 Bhadauria 和瑞典查爾姆斯理工大學(xué)的 McKee［48］分析了 CMP 系統(tǒng)中多道程序資源使用的沖突問(wèn)題，結(jié)合性能提升，設(shè)計(jì)了三種協(xié)同調(diào)度算法：HOLISYN、Greedy 和 Oracle 等，使用統(tǒng)計(jì)方法及處理器性能計(jì)數(shù)器來(lái)探測(cè)沖突資源的使用情況，并嘗試在不同的時(shí)刻調(diào)度它們，提高了 CMPs 系統(tǒng)上程序的總吞吐量。

4.4 硬件協(xié)同防同駐技術(shù)

除了在軟件層防御同駐，還可以從硬件設(shè)計(jì)層做防御［49，50］，這也是未來(lái)的重要方向。如前所述，LLC 隱蔽通道/側(cè)信道問(wèn)題［17，20］是由同一個(gè)package 中的處理器核心共享 Cache 造成的，除了利用內(nèi)存頁(yè)染色技術(shù)和處理器分配策略之外，也可以從 CPU 設(shè)計(jì)角度考慮消除該隱蔽通道/側(cè)信道。例如重新設(shè)計(jì) CPU 架構(gòu)，使其嚴(yán)格地控制虛擬機(jī)對(duì) Cache 的使用，徹底消除 LLC 隱蔽通道/側(cè)信道。再譬如，利用同駐水印探測(cè)虛擬機(jī)同駐的方案［22］是基于物理網(wǎng)卡多路復(fù)用帶來(lái)的網(wǎng)絡(luò)包延時(shí)提出，可以考慮重新設(shè)計(jì)物理網(wǎng)卡，使其支持虛擬化技術(shù)中多個(gè)虛擬機(jī)對(duì)網(wǎng)卡的多路復(fù)用，為同駐的虛擬機(jī)間提供良好的網(wǎng)絡(luò)隔離性。

5 未來(lái)研究趨勢(shì)

通過(guò)分析總結(jié)云計(jì)算環(huán)境中的虛擬機(jī)同駐安全問(wèn)題研究現(xiàn)狀以及當(dāng)前研究方向所存在的問(wèn)題，可以將未來(lái)的研究趨勢(shì)概括為三大方向：

（1）針對(duì)云計(jì)算環(huán)境中的虛擬機(jī)同駐威脅研究，將在高帶寬、低干擾的隱蔽通道/側(cè)信道攻擊以及更加隱蔽、潛伏時(shí)間更長(zhǎng)的拒絕服務(wù)攻擊等方面進(jìn)一步深入研究；

（2）結(jié)合 IaaS 云服務(wù)采用的不同類型虛擬化實(shí)現(xiàn)技術(shù)（如 Xen，KVM，DOCER 等）開展研究，建立準(zhǔn)確率高、用戶可自主驗(yàn)證或者可委托可信第三方驗(yàn)證的虛擬機(jī)同駐探測(cè)技術(shù)；

（3）虛擬機(jī)同駐安全隱患已經(jīng)成為云服務(wù)發(fā)展亟待解決的關(guān)鍵問(wèn)題，業(yè)界與學(xué)術(shù)界期望能夠從防同駐的資源調(diào)度和負(fù)載均衡策略、多核進(jìn)程隔離技術(shù)以及硬件協(xié)同設(shè)計(jì)等角度來(lái)提升云服務(wù)的可信性。因此，深入研究解決同駐安全問(wèn)題的軟、硬件結(jié)合技術(shù)是未來(lái)的重要發(fā)展方向。

6 總 結(jié)

隨著云計(jì)算技術(shù)的發(fā)展與應(yīng)用，多租戶虛擬機(jī)之間的同駐安全威脅日益突出，成為云計(jì)算環(huán)境中不容忽視、亟待解決的問(wèn)題。為此，本文總結(jié)并分析了近年來(lái)業(yè)界和學(xué)術(shù)界對(duì)虛擬機(jī)同駐安全問(wèn)題的研究，包括虛擬機(jī)同駐所面臨的多種安全威脅、虛擬機(jī)同駐探測(cè)技術(shù)以及虛擬機(jī)同駐威脅防御方案，并探討了未來(lái)研究趨勢(shì)。

［1］ Amazon Elastic Compute Cloud （EC2） ［EB/OL］. ［2015-03-25］. http：//aws.amazon.com/ec2/.

［2］ Google Compute Engine （GCE） ［EB/OL］. 2013-06-03 ［2015-05-28］. http：//www.freehao123.com/tag/googlecompute-engine/.

［3］ Microsoft Azure Services Platform ［EB/OL］. 2014-02-10 ［2015-06-01］. http：//www.microsoft.com/azure/ default.mspx.

［4］ Rackspace Mosso ［EB/OL］. ［2014-06-20］. http：//www. mosso.com/.

［5］ OpenStack ［EB/OL］. ［2015-06-01］. http：//www. openstack.org/.

［6］ Gebhardt C， Tomlinson A. Challenges for inter virtual machine communication ［R］. RHUL-MA-2010-12，England： University of London， 2010.

［7］ Wang J. Survey of state-of-the-art in inter-VM communication mechanisms ［J］. Research Proficiency Report， 2009： 1-25.

［8］ Wang J， Wright KL， GopalanK. XenLoop： a transparent high performance inter-VM network loopback ［J］. Cluster Computing， 2009， 12（2）： 141-152.

［9］ Zhang X， McIntosh S， Rohatgi P， et al. XenSocket：a high-throughput interdomain transport for virtual machines ［M］ // Middleware 2007. Springer Berlin Heidelberg， 2007： 184-203.

［10］ Kim K， Kim CY， Jung SI， et al. Inter-domain socket communications supporting high performance and full binary compatibility on Xen ［C］ // Proceedings of the Fourth ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments，2008：11-20.

［11］ Huang W， Koop MQ， Gao Q， et al. Virtual machine aware communication libraries for high performance computing ［C］ // Proceedings of the 2007 ACM/IEEE Conference on Supercomputing， 2007： 1-12.

［12］ Radhakrishnan P， Srinivasan K. MMNet： an effcient inter-VM communication mechanism ［C］ // Proceedings of Xen Summit， 2008： 1-3.

［13］ Vaquero L， Rodero-Merino L， Morán D. Locking the sky：a survey on IaaS cloud security ［J］. Computing， 2011，91（1）： 93-118.

［14］ Wei JP， Zhang XL， Ammons G， et al. Managing security of virtual machine images in a cloud environment ［C］ // Proceedings of the 2009 ACM Workshop on Cloud Computing Security， 2009： 91-96.

［15］ 俞能海， 郝卓， 徐甲甲， 等. 云安全研究進(jìn)展綜述 ［J］. 電子學(xué)報(bào)， 2013， 41（2）： 371-381.

［16］ 馮登國(guó)， 張敏， 張妍， 等. 云計(jì)算安全研究 ［J］. 軟件學(xué)報(bào)， 2011， 22（1）： 71-83.

［17］ Ristenpart T， Tromer E， Shacham H， et al. Hey， you， get off of my cloud： exploring information leakage in thirdparty compute clouds ［C］ //Proceedings of the 16th ACM Conference on Computer and Communications Security， 2009： 199-212.

［18］ Barker S， Shenoy PJ. Empirical evaluation of latencysensitive application performance in the cloud ［C］ // Proceedings of the First Annual ACM SIGMM Conference on Multimedia Systems， 2010： 35-46.

［19］ Varadarajan V， Kooburat T， Farley B， et al. Resourcefreeing attacks： improve your cloud performance （at your neighbor's expense） ［C］ // Proceedings of the 2012 ACM Conference on Computer and Communications Security，2012： 281-292.

［20］ Xu YJ， Bailey M， Jahanian F， et al. An exploration of L2 cache covert channels in virtualized environments ［C］ // Proceedings of the 3rd ACM Workshop on Cloud Computing Security Workshop， 2011： 29-40.

［21］ Zhou FF， Goel M， Desnoyers P， et al. Scheduler vulnerabilities and coordinated attacks in cloud computing ［C］ // 2011 10th IEEE International Symposium on Networking Computing and Applications，2011： 123-130.

［22］ Bates A， Mood B， Pletcher J， et al. Detecting co-residency with active traffic analysis techniques ［C］ // Proceedings of the 2012 ACM Workshop on Cloud Computing Security Workshop， 2012： 1-12.

［23］ Zhang YQ， Juels A， Oprea A， et al. HomeAlone： coresidency detection in the cloud via side-channel analysis ［C］ // 2011 IEEE Symposium on Security and Privacy，2011： 313-328.

［24］ Zhang YQ， Juels A， Reiter MK， et al. Cross-VM side channels and their use to extract private keys ［C］ // Proceedings of the 2012 ACM Conference on Computer and Communications Security， 2012： 305-316.

［25］ Godfrey M， Zulkernine M. A server-side solution to cache-based side-channel attacks in the cloud ［C］ // 2013 IEEE Sixth International Conference on Cloud Computing， 2013： 163-170.

［26］ 余思， 桂小林， 張學(xué)軍， 等. 云環(huán)境中基于 cache 共享的虛擬機(jī)同駐檢測(cè)方法 ［J］. 計(jì)算機(jī)研究與發(fā)展， 2013，50（12）： 2651-2660.

［27］ Raj H， Nathuji R， Singh A， et al. Resource management for isolation enhanced cloud services ［C］ // Proceedings of the 2009 ACM Workshop on Cloud Computing Security， 2009： 77-84.

［28］ Bedi HS， Shiva S. Securing cloud infrastructure against co-resident DoS attacks using game theoretic defense mechanisms ［C］ // Proceedings of the International Conference on Advances in Computing Communications and Informatics， 2012： 463-469.

［29］ Wei? M， Heinz B， Stumpf F. A cache timing attack on AES in virtualization environments ［M］ // Financial Cryptography and Data Security. Springer Berlin Heidelberg， 2012： 314-328.

［30］ Pu X， Liu L， Mei YD， et al. Understanding performance interference of I/O workload in virtualized cloud environments ［C］ // 2010 IEEE 3rd International Conference on Cloud Computing， 2010： 51-58.

［31］ Wang GH， Ng TSE. The impact of virtualization on network performance of amazon EC2 data center ［C］ // 2010 Proceedings IEEE on INFOCOM， 2010： 1-9.

［32］ Chisnall D. The Definitive Guide to the Xen Hypervisor ［M］. Boston： Prentice Hall PTR， 2007.

［33］ 石磊， 鄒德清， 金海. Xen 虛擬化技術(shù) ［M］. 武漢： 華中科技大學(xué)出版社， 2009.

［34］ 沈晴霓， 卿斯?jié)h. 操作系統(tǒng)安全設(shè)計(jì) ［M］. 北京： 機(jī)械工業(yè)出版社， 2013.

［35］ Barham P， Dragovic B， Fraser K， et al. Xen and the art of virtualization ［J］. ACM SIGOPS Operating Systems Review， 2003， 37（5）： 164-177.

［36］ Osvik DA， Shamir A， Tromer E. Cache attacks and countermeasures： the case of AES ［M］ // Topics in Cryptology-CT-RSA 2006. Springer Berlin Heidelberg，2006： 1-20.

［37］ Tromer E， Osvik DA， Shamir A. Efficient cache attacks on AES and countermeasures ［J］. Journal of Cryptology，2010， 23（1）： 37-71.

［38］ Song DX， Wagner D， Tian XQ. Timing analysis of keystrokes and SSH timing attacks ［C］ // The 10th USENIX Security Symposium， 2001： 337-352.

［39］ Whiteaker J， Schneider F， Teixeira R. Explaining packet delays under virtualization ［J］. ACM SIGCOMM Computer Communication Review， 2011， 41（1）： 38-44.

［40］ Hyper-V overview ［EB/OL］. 2015-03-31 ［2015-06-12］. https：//technet.microsoft.com/en-us/library/hh831531. aspx.

［41］ 王于丁， 楊家海， 徐聰， 等. 云計(jì)算訪問(wèn)控制技術(shù)研究綜述 ［J］. 軟件學(xué)報(bào)， 2015， 26（5）： 1129-1150.

［42］ Kessler RE， Hill MD. Page placement algorithms for large real-indexed caches ［J］. ACM Transactions on Copmuter Systems， 1992， 10（4）： 338-359.

［43］ Page D. Partitioned cache architecture as a side-channel defence mechanism ［J］. IACR Cryptology ePrint Archive， 2005： 280.

［44］ Varadarajan V， Ristenpart T， Swift M. Schedulerbased defenses against cross-VM side-channels ［C］ // Proceedings of the 23rd USENIX Security Symposium，2014： 687-702.

［45］ Azar Y， Kamara S， Menache I， et al. Co-location-resistant clouds ［C］ // Proceedings of the 6th ACM Workshop on Cloud Computing Security， 2014： 9-20.

［46］ Han Y， Chan J， Alpcan T， et al. Virtual machine allocation policies against co-resident attacks in cloud computing ［C］ // 2014 IEEE International Conference on Communications， 2014： 786-792.

［47］ Fedorova A， Seltzer M， Smith MD. Improving performance isolation on chip multiprocessors via an operating system scheduler ［C］ // Peoceedings of the 16th International Conference on Parallel Architecture and Compilation Techniques， 2007： 25-38.

［48］ Bhadauria M， McKee SA. An approach to resourceaware co-scheduling for CMPs ［C］ // Proceedings of the 24th ACM International Conference on Supercomputing. ACM， 2010： 189-199.

［49］ Pattuk E， Kantarcioglu M， Lin ZQ， et al. Preventing cryptographic key leakage in cloud virtual machines ［C］ // Proceedings of the 23rd USENIX Security Symposium，2014： 703-718.

［50］ Godfrey M， Zulkernine M. Preventing cache-based side-channel attacks in a cloud environment ［J］. IEEE Transactions on Cloud Computing， 2014， 2（4）： 395-408.

Review on Co-residency Security Issues of Virtual Machines in Cloud Computing

SHEN Qingni LI Qing
（ MoE Key Lab of Network and Software Assurance of Peking University， School of Software and Microelectronics， Peking University，Beijing 100871， China ）

In cloud computing， in order to achieve resource sharing， virtual machines （VMs） of different tenants might be scheduled to run on the same physical machine， namely VMs co-residency， which would bring many new security issues. Therefore， security threats due to VMs co-residency， including resources interference， covert or side channel， denial of service and virtual machine load monitoring were reviewed in this paper. Besides， existing detection methods of co-residency were introduced， four kinds of defense about VMs co-residency were summarized and further trends were also pointed out.

cloud computing； virtualization； virtual machine； co-residency； security

TP 309

A

2015-06-22

2015-07-29

國(guó)家自然科學(xué)基金（61073156，61232005）；國(guó)家高技術(shù)研究發(fā)展計(jì)劃（2015AA016009）；深圳市科技計(jì)劃（JSGG20140516162852628）

沈晴霓（通訊作者），博士，教授，研究方向?yàn)椴僮飨到y(tǒng)與虛擬化安全、云計(jì)算與大數(shù)據(jù)安全、可信計(jì)算，E-mail：qingnishen@ ss.pku.edu.cn；李卿，碩士，研究方向?yàn)樵朴?jì)算安全。