沈晴霓 李 卿

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

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

沈晴霓 李 卿

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

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

云計算；虛擬化；虛擬機；同駐；安全

1 引 言

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

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

2 虛擬機同駐安全威脅

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

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

2.1 同駐虛擬機間的資源干擾

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

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

2.1.1 CPU 資源

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

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

2.1.2 磁盤資源

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

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

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

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

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

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

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

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

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

2.2.1 通信方案

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

2.2.2 應(yīng)用場景

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

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

2.3 拒絕服務(wù)攻擊

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

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

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

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

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

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

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

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

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

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

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

2.4 資源釋放攻擊

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

2.4.1 攻擊原理

資源釋放攻擊［19］要求：（1）使得受害者虛擬機對某個資源的使用達到瓶頸；（2）改變受害者的資源使用狀況，使得受害者的絕大部分處理時間都花費在瓶頸資源上，無法使用其他資源。

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

2.4.2 攻擊過程

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

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

2.5 同駐虛擬機負載探測

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

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

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

2.5.2 通過網(wǎng)絡(luò) TCP 會話的探測

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

3 虛擬機同駐探測技術(shù)

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

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

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

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

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

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

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

3.2 同駐水印技術(shù)

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

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

3.3 HomeAlone 技術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 未來研究趨勢

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

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

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

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

6 總 結(jié)

隨著云計算技術(shù)的發(fā)展與應(yīng)用，多租戶虛擬機之間的同駐安全威脅日益突出，成為云計算環(huán)境中不容忽視、亟待解決的問題。為此，本文總結(jié)并分析了近年來業(yè)界和學(xué)術(shù)界對虛擬機同駐安全問題的研究，包括虛擬機同駐所面臨的多種安全威脅、虛擬機同駐探測技術(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］. 電子學(xué)報， 2013， 41（2）： 371-381.

［16］ 馮登國， 張敏， 張妍， 等. 云計算安全研究 ［J］. 軟件學(xué)報， 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］. 計算機研究與發(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è)計 ［M］. 北京： 機械工業(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］ 王于丁， 楊家海， 徐聰， 等. 云計算訪問控制技術(shù)研究綜述 ［J］. 軟件學(xué)報， 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

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

沈晴霓（通訊作者），博士，教授，研究方向為操作系統(tǒng)與虛擬化安全、云計算與大數(shù)據(jù)安全、可信計算，E-mail：qingnishen@ ss.pku.edu.cn；李卿，碩士，研究方向為云計算安全。