基于多處理器虛擬化的云計算應用的安全研究

【摘要】目前，云計算應用的安全都是通過在虛擬機監控器中添加軟件層來對云計算應用進行保護的，然而此種云計算應用保護技術在需要保護的云計算應用非常密集時，云計算應用的執行效率就會非常低，而且單一的保護模塊一旦出現故障，云計算應用就會得不到保護。針對這一問題，提出一種基于多處理器虛擬化的云計算應用安全保護模型，該文運用了硬件輔助虛擬化的技術，將云計算應用安全保護系統直接控制部分硬件資源，作為與VMM對等協作的獨立系統運行，同時構造出多個獨立的保護系統用于負載平衡及故障替換。通過測試表明，該模型在很大程度上滿足了云計算應用安全保護密集的需求。

【關鍵詞】云計算虛擬化云計算應用安全多處理器對等協作

云計算作為未來IT業主要趨勢之一，正迅速在企業級應用中普及。它體現了“網絡就是計算機”的思想。將大量可規模化計算資源、存儲資源與軟件資源鏈接在一起，形成巨大的共享虛擬IT資源池，通過對于大規模資源的高效靈活調度為遠程計算機用戶提供按需動態擴容和收縮的計算服務，同時也為云服務提供商提供了巨大的資源優化調度空間，用規模化的效應最大程度地降低了成本。云計算是將資源以網絡服務的形式提供給用戶，將用戶從復雜繁瑣的IT軟硬件維護中解放出來，而且，遠程用戶可以隨時隨地或得服務，打破了時間和地域的限制。

出于對數據安全的考慮，云計算出現了四種子模型，即為私有云，公共云，社團云以及混合云。私有云是對企業內部IT資源的虛擬化和自動化管理，是企業內部計算資源的整合，面向內部用戶，云的規模由內部資源的總量決定，而且所有數據仍舊由企業自己管理，這種云規模比較有限，只能享受部分云計算的優勢。公共云是云計算的設計最終模型，公共云也稱為第三方云，有著更大的靈活性和成本優勢。企業可以將計算和存儲外包給云服務提供商，不需自己購買設備和投入專業人員來做云系統維護，而且還能在計算需求變化時靈活地增減云資源的租用。但是，將計算和存儲外包給云服務商，就意味著將數據也外包給了第三方—云服務提供商，這樣數據的私密性就得不到保證了，這是與私有云的最大區別，也是現在大部分云計算應用局限于私有云的原因，然而公共云是云計算的最終模型。社團云是幾個有共同應用需求的組織共同組建的半公共云，它比私有云有更大的資源優化空間，比公共云有更小的風險。混合云是私有云和公共云的混合，即用戶將私密性數據和業務運行在私有云中，將非私密性數據和業務運行在公共云中。這四類云中，公共云是云計算的設計初衷，也有著最大的靈活性和成本優勢，本文主要目標是研究分析公共云中云計算應用的安全。

用戶數據在云服務器端有兩種存儲形式，靜態存儲和動態計算。靜態數據以存儲為目的，不需要參與運算，只是利用云的存儲功能，因此靜態數據能夠用密碼學加密技術進行保護。動態數據可能存在于內存、網絡或緩存等介質中，參與運算。動態數據在參與運算時需要還原成明文形式，現在還沒有技術能讓數據在加密的狀態下進行運算，因而私密數據在云端至少有一部分時間是以明文形式存在的。在這段以明文形式存在的時間里動態數據就有可能泄露，因為云計算服務是通過因特網提供給用戶的，云服務是始終在線的，因而來自網絡的攻擊可能通過用戶虛擬機的網絡接口進行入侵，攻破用戶虛擬機的操作系統，進而訪問用戶進程所占的內存空間。

現有的云計算應用的安全機制都是基于虛擬機技術之上的，通過在虛擬機監控器中添加軟件層來對云計算應用進行保護。比如已經實現了的chaos系統[5-7]。然而此種云計算應用保護技術已經在一定程度上影響了計算密集型的應用的執行效率[9]。所以在需要保護的云計算應用非常密集的云平臺上，就嚴重影響云計算應用的執行效率了，而且單一的云計算應用保護模塊一旦出現故障，云計算應用就得不到保護了。

本文提出并實現了一種基于多處理器虛擬化的云計算應用安全模型，此模型運用了硬件輔助虛擬化的技術，將云計算應用安全保護系統直接控制部分硬件資源，作為與VMM對等協作的獨立系統運行，同時構造出多個獨立的保護系統用于負載平衡及故障替換。

一、安全保護模型的系統結構描述

集成在虛擬機監控器中的保護技術遠遠不能滿足云計算應用保護密集型的云計算平臺，本系統采用硬件劃分方式，使云計算應用的保護模塊直接控制部分硬件資源，將其從虛擬機監控器中移植出來轉換為具備特權的CAPPM，與VMM形成對等協作的結構。控制主體有兩部分組成，VMM和CAPPM。VMM負責虛擬化，CAPPM負責保護云計算應用，存在多個CAPPM，每個CAPPM控制一個AP，VMM控制BSP和其余AP。如圖1所示。

將云計算應用保護模塊從虛擬機監控器中移植出來轉換為與VMM對等協作的獨立系統，一方面大大增強了對云計算應用保護密集的云平臺的云計算應用保護的響應速度，另一方面，一旦某個保護系統出現故障，其他保護系統可以繼續提供保護而且多個CAPPM可以進行負載均衡。

二、模型實現的關鍵細節

整個模型實現的關鍵細節包括：硬件資源劃分，VMM初始化，CAPPM構造，VMM-CAPPM通信。

2.1硬件資源劃分

為了實現VMM和CAPPM之間的協作，首先要對兩個系統進行隔離，包括硬件資源的隔離和地址空間的隔離，避免兩者在硬件控制上產生沖突，同時需要考慮采用適當的共享措施保證VMM和CAPPM之間的交互。

硬件資源可分為獨占性資源和可共享資源，不同資源的分配原則也不同，獨占性資源需要明確指定其唯一的控制主體，不允許存在交叉的控制現象，可共享資源需要對資源進行細粒度分區，指派給多個控制主體，但需要保證同步。VMM和CAPPM之間的硬件劃分如表1所示。

2.1.1處理器劃分與實現

處理器的劃分應該根據不同主體的負載情況，VMM負責為上層虛擬機提供運行環境，需要協調多個虛擬機對處理器的共享使用，而且，虛擬機之間的通信是很少的，因此處理器越多，虛擬機之間的并行度越高，云平臺上的客戶虛擬機執行效率就越高，也就越接近單機上的真實物理計算環境，而CAPPM只提供對云計算應用的安全保護功能，并且保護模塊對處理器的要求也不是很高，所以每個CAPPM控制一個處理器，VMM控制其余的所有處理器。

系統中的多處理器信息在開機后由BIOS檢測并存放在特定的物理內存空間中，根據多處理器啟動協議，首先運行BSP，系統中的其他AP處于睡眠狀態，等待BSP的喚醒，BSP上運行VMM，VMM從BIOS數據區中獲得完整的多處理器信息，識別需要分配給CAPPM的AP。

2.1.2物理內存劃分與實現

為了實現VMM和CAPPM地址空間的隔離以及數據交互。需要將整個物理內存劃分為3個部分，分別是VMM管理區、CAPPM管理區、共享區，共享區只能被訪問而不參與分配，管理區則需參與內存管理器的動態分配和回收。VMM根據E820內存信息獲得整個物理內存的布局狀況，在此基礎上VMM對不可分配的區域進行限制。通常采用基于位圖的管理方式來控制內存的使用，對VMM不可分配的區域相應的位圖進行標記，表示此段內存區間也被保留，從而實現VMM和CAPPM內存區域的隔離。

2.1.3中斷路由

外部中斷有兩種情況，一是IOAPIC遞交的設備中斷，二是AP產生的處理器間中斷。通過中斷源對應的中斷向量可以區分這兩種外部中斷，第二種中斷跟VMM與CAPPM通信有關將在后面討論。我們需要把所有的第一種中斷首先遞交給VMM，然后VMM根據中斷來源做出進一步處理，或直接在內部處理，或遞交給CAPPM處理。

多處理器平臺上的中斷不再通過單處理器的中斷控制器8259A向處理器遞交，而是通過IOAPIC將中斷遞交給特定的處理器，通過對IOAPIC設置，可以實現將所有的外部中斷首先遞交給VMM。IOAPIC包括了一組中斷重定向表，一個外部中斷對應重定向表中的一項，通過重定向表將外部中斷發到指定的LAPIC，最后VMM通過操作LAPIC中的中斷命令寄存器將外部中斷遞交給CAPPM。

2.2CAPPM構造

CAPPM作為一個的獨立系統為云計算應用提供安全保護。作為一個和VMM對等協作的獨立系統，CAPPM也將運行在VMX根模式下，重新為CAPPM編寫操作系統沒有必要，我們可以借助開源的操作系統，對其進行添加和修改，將云計算應用保護模塊添加到開源的操作系統的內核中。Linux是最好的選擇，因為CAPPM目前只提供云計算應用保護這一功能，所以我們可以對最初的Linux版本（例如linux0.11版本）進行添加和修改。CAPPM的構造主要包括處理器控制、內存限制和啟動。

2.2.1CAPPM處理器控制

CAPPM運行改造后的Linux系統，處理器控制主要是防止CAPPM去管理其余的處理器，我們是選擇最初的Linux版本進行修改的，最初的Linux版本本來就不支持多處理器，所以CAPPM不會去管理其余的處理器。

2.2.2CAPPM內存限制

整個物理內存被VMM和CAPPM分區管理，需要對CAPPM能夠探測、分配使用、訪問的范圍進行限制。由于E820探測出的是完整的內存布局信息，因此需要對CAPPM的E820信息進行修改來控制CAPPM訪問的限制，分配限制則通過對CAPPM的內存位圖進行修改。

2.2.3CAPPM啟動

傳統的操作系統是由Bootloader加載并啟動，VMM是第一個啟動的系統，它的啟動可以由Bootloader完成。CAPPM是在VMM的控制下啟動的，并且機器的運行環境也發生了改變，如物理內存布局等，因此需要VMM根據啟動協議的要求和當前資源的分配情況，模擬出Bootloader的行為并啟動CAPPM。

2.3VMM-CAPPM通信實現

在VMM和CAPPM通信之前首先采用了輪詢的負載均衡算法選擇與哪個CAPPM進行通信。VMM和CAPPM通過同步通信的方式進行通信，以處理器間中斷完成消息通告，并通過一塊共享內存完成數據的傳輸。VMM-CAPPM通信實現主要包括共享內存組織結構設計和通信處理流程構造

2.3.1共享內存組織結構

由于共享內存空間有限，在傳遞大量數據時需要提供復用機制，保證數據在共享區內的可靠傳遞，因此需要對共享內存區域進行組織。我們把共享內存劃分為控制區和數據區，控制區存放公開控制指針，數據區則以環的形式組織。

2.3.2通信處理過程

通信的關鍵在于數據的發送方式和接收方式，發送數據相對容易實現，可以先將數據放置到共享內存，然后以處理器間中斷完成消息通告。接收數據則需要考慮IPI丟失、緩沖區溢出、同步等問題。

三、模型評估

基于多處理器虛擬化的云計算應用安全保護模型，將云計算應用保護模塊集成在Linux內核中直接控制部分硬件成為獨立的系統，實現了VMM和CAPPM之間的對等協作，然而采用對等協作方式之后，隨著CAPPM系統個數的增加，云計算應用保護密集的云平臺上的需要保護的云計算應用執行效率會不會也隨之而提高，然而模型的穩定性會不會降低，這些問題是模型評估的主要方面，需要搭建相應的測試環境，對上述問題進行嚴格的測試。

對于硬件需要具備兩個以上的處理器核，并且支持硬件虛擬化的處理器，和具備較為充足地址空間的內存，因此我們選擇Intel的支持虛擬化的多核心處理器和4GB內存，對于軟件CAPPM我們采用chaos系統和Linux 0.11內核開發而成，虛擬機監控器則采用支持硬件虛擬化的Xen。

我們構造了含有不同CAPPM系統個數的協作模型，編寫了性能測試程序對我們構造的模型進行性能測試，此性能測試主要測試模型在云計算應用保護密集時，隨著CAPPM系統個數的增加，需要保護的云計算應用的平均執行效率的變化以及模型穩定性的變化。

如圖2所示隨著CAPPM系統個數的增加，模型的穩定性基本保持不變。說明了模型的可行性。

如圖3所示隨著CAPPM系統個數的增加需要保護的云計算應用的平均執行效率在逐漸提高，然而由于用于測試的機器中的處理器個數有限并沒有測試出CAPPM個數一直增長，云計算應用的平均執行效率會怎樣變化。

四、結束語

本文提出了基于多處理虛擬化的云計算應用保護技術，將集成在虛擬機監控器中云計算應用保護模塊移植出來，讓其集成在Linux內核中成為與VMM對等協作的獨立系統，在一定程度上解決了云計算應用保護密集型的云計算平臺的需求。然而由于用于測試的機器中的處理器個數有限并沒有測試出CAPPM個數一直增長，云計算應用的平均執行效率會怎樣變化。

參考文獻

[1]馮登國，張敏，張研等.云計算安全研究[J].軟件學報，2011，22（1）：71-83.

[2]房晶，吳昊，白松林.云計算安全研究綜述[J]. China Academic Journal Electronic Publishing House，2010年第九期.

[3]陳全，鄧倩妮.云計算及其關鍵技術[J].計算機應用，2009年9月第九期.

[4]張云勇，陳清金，潘松柏等.云計算安全關鍵技術分析[J]. China Academic Journal Electronic Publishing House.