面向虛擬化系統的故障注入工具設計與實現

胡 慎，徐 珞，艾中良，李 寧

(華北計算技術研究所總體部，北京 100083)

0 引 言

面向虛擬化系統的故障注入技術可以給出對虛擬化系統的可靠性及容錯性評價，是對虛擬化系統進行評測的重要方法[1]。

目前存在的故障注入工具如DEFINE、NFTAPE、DOCTOR和Xception等多為傳統物理機故障注入工具[2]，不能直接應用到虛擬化系統上，且其缺少對虛擬化系統特有故障的測試，因此無法滿足對虛擬化系統可靠性及容錯性的評測。本文在分析典型虛擬化系統的體系結構及虛擬化機制的基礎上，提出了一種面向虛擬化系統的故障注入工具架構，并以該架構為基礎以及Xen系統實現了一種故障注入工具，完成了向虛擬化系統的核心即虛擬化管理器層(virtual machine monitor，VMM)的故障注入實驗并依據實驗結果對系統的可靠性和容錯性進行分析，驗證了工具的有效性。

1 傳統故障注入技術

傳統故障注入技術可分為1.1節和1.2節中介紹的兩大類，此兩類技術的具體定義及優缺點請參見文獻[3]。

1.1 基于模擬的故障注入

常見的基于模擬的故障注入工具有CECIUM、FOCUS和MEFISTO等。該方法的優點是可以在系統設計的不同階段進行故障的注入，不存在可訪問性方面的限制。但是這種方法存在的缺點是在建模上比較復雜且比較耗時，不便于系統的便捷開發；并且需要準確的參數輸入，當設計改變復雜化歷史測試數據的使用時，很難獲取準確的參數輸入。

1.2 基于原型的故障注入

1.2.1 硬件故障注入

常見的硬件注入故障工具有Messaline、RIFLE等。其包含接觸式和非接觸式兩類注入方法：接觸式方法會直接接觸目標系統；非接觸式硬件故障注入不直接接觸目標系統的硬件設備。隨著硬件封裝密度的提高，硬件故障注入的使用也越來越少。

1.2.2 軟件故障注入

常見的軟件故障注入工具有DEFINE、NFTAPE、DOCTOR和Xception等。根據故障注入時刻的不同，可將軟件故障注入分為編譯時故障注入和運行時故障注入。編譯時故障注入是指在程序編譯連接時進行故障注入；運行時故障注入是指在程序運行時進行故障注入。

2 故障注入工具的設計與實現

2.1 工具總體架構設計

與傳統物理機相比，虛擬化系統有一個重要的部分，即虛擬機管理器層，因此虛擬化系統的故障模型和注入方法都有其特殊性[4]。例如在虛擬化系統中可以對虛擬機管理器層的頁表進行修改從而實現虛擬機內存故障的注入。顯然這是虛擬化系統特有的方法，物理機不能使用這種方法；與之相對，很多物理機故障的注入方法也不適用于虛擬化系統。本文提出了一種面向虛擬化系統的故障注入工具架構，并在openstack云平臺上創建Xen虛擬機實現了原型系統工具。工具針對虛擬化系統的體系結構特點，實現向虛擬機管理器層的故障注入，完成對虛擬化系統的可靠性和容錯性的分析。其總體架構設計如圖1所示，它由以下幾部分組成：

(1)Xen虛擬機管理器，在虛擬化系統中，它負責所有虛擬化功能的實現，可以直接干涉虛擬機節點(virtual machine，VM)的CPU、內存、硬盤等一切資源的使用。針對該層的特點，本文設計特定的故障類型，實現對其相關管理機制的故障注入。

(2)Xen虛擬機節點，當虛擬器管理器被注入故障時，由于其功能是對虛擬機節點進行管理，所以故障反應是通過其下的虛擬機節點表現出來的[5]，如系統崩潰、遷移失效等。

(3)前端，負責實現與測試者的交互，完成故障注入信息的傳入和故障注入結果收集。

圖1 故障注入工具總體架構

2.2 故障建模方法

進行一次故障注入實驗的過程如圖2所示，因此建立故障模型是故障注入實驗的基礎。故障模型主要包括故障類型、發生位置和發生模型等信息。針對虛擬機體系結構和虛擬化策略，結合物理計算機系統中的故障類型[6]，本文將虛擬機管理層的故障劃分為內存管理、硬件資源分配、狀態查詢、虛擬機遷移、訪問控制、事件通道6類。

圖2 故障注入實驗過程

在實現虛擬化系統的故障注入時，為使故障注入能夠更貼近實際使用中的故障情況，除要設計故障類型、位置等靜態特征外，還需考慮故障的動態特征，即在虛擬化系統中各類型故障的發生次序及相互間的觸發關系等[7]。在實驗過程中，為建立故障發生模型，可以依據故障發生記錄來獲取各類故障發生的特點并建立相應的概率模型；另外，為降低建立模型的復雜度，縮短故障注入的周期，也可以基于人工經驗直接建立滿足測試要求的模型，例如各類故障可以是依某種分布概率分布的，也可以是隨機分布的。

為實現對故障準確而簡明的描述，本文使用xml編寫測試腳本定義各類型故障及故障發生模型，建立起系統的故障注入模型，使得前端交互部分與注入工具得以解耦，并支持各類型故障的自動化注入。圖3為一個xml測試腳本文件示例，其以作為xml根標簽，其子標簽有和，分別定義故障模型和故障發生模型。故障模型下有故障類型、故障位置等標簽；故障發生模型下有故障開始時間、停止時間等標簽。

圖3 測試腳本文件

2.3 故障實現

通過對Xen系列虛擬化系統的體系結構和虛擬化策略的研究分析，可知Xen系列虛擬化管理功能，包括內存管理、虛擬機遷移等，都需要通過其超級調用hypercall來進行，因此可通過對各超級調用注入故障實現對對應管理功能的故障注入。

2.3.1 Xen超級調用

目前Xen系列虛擬化系統共有通用的超級調用37個，還有一些為具體機器環境特有的。為了唯一標識每個超級調用，Xen系統為每個超級調用定義了一個唯一的編號，即為超級調用號[8]，見表1；為記錄各個超級調用函數的入口地址，Xen系統定義超級調用表，可以通過超級調用號在其中定位到對應函數的入口地址。

表1 Xen系統超級調用號

表1(續)

2.3.2 故障類型與超級調用對應關系

本文要實現的6種類型的故障注入均可通過超級調用實現，其與超級調用的對應關系見表2，可根據其中的超級調用號在表1中查得對應的超級調用名稱。實驗過程中對各超級調用注入故障即可完成對應類型的故障注入。

2.3.3 故障注入原理

在Xen系列虛擬化系統中，超級調用為一種類似系統調用的操作，其可以使處在1環的內核能夠越權執行一些在0環才能進行的操作，其軟中斷號為0x82，處理程序為hypercall。其申請和執行過程是通過系統調用ioctl進行的，本文利用kprobe對其對用的內核處理例程sys_ioctl進行攔截并對其參數進行修改，完成對超級調用的故障注入。

在Xen系列虛擬化系統中，kprobe是linux內核中的一個輕量級動態內核調試裝置，可以向正在運行的內核中插入斷點。其實現了Kprobes、jprobes和kretprobes這3種類型的探針，此3類探針各有優缺點及適用的情況，對其具體分析請參見文獻[9]。

依據文獻[9]，由于jprobes可以獲取到內核函數的參數，本文使用jprobes進行對sys_ioctl的攔截。另外，jprobes雖然可以獲得內核函數的參數，但不能修改。在jprobes對sys_ioctl成功攔截后，本文使用copy_to_user()和copy_from_user()這兩個函數對參數進行修改，完成故障的注入。其基本流程如圖4所示，具體過程為：首先使用jprobes攔截ioctl，攔截完成后通過copy_from_user()將超級調用的參數M修改改為N，然后利用copy_to_user()將N寫到用戶空間中。當執行sys_ioctl()時，函數通過copy_from_user()獲得超級調用參數值，而此時獲得的參數N已經是修改后的錯誤參數值，所以故障被成功注入。

圖4 故障注入原理

另外，由于sys_ioctl[10]是linux的通用系統調用接口，除超級調用外，其它很多功能也會觸發其執行。因此在注入過程中需要對其本次執行是否由超級調用觸發進行判定。sys_ioctl由3個參數組成：fd，IOCTL_PRIVCMD和&hcall，其分別為文件描述符、命令碼和指向系統調用參數的指針。sys_ioctl在其第二個參數中定義調用的觸發源，其格式定義如圖5所示，其共包含32位，前兩位是模式標記位，接下來14位表示數據結構位數，然后8位是類型標記位，最后8位標記編號。

圖5 ioctl命令碼格式

宏IOCTL_PRIVCMD_HYPERCALL表示超級調用的命令碼[11]，由于不同環境下該值會發生變化，所以用X表示該值。在注入故障時，對sys_ioctl()的參數cmd進行判定，若其值為X，則進行故障注入；若不是則不進行故障注入。

2.3.4 故障注入過程

以本文提出的架構實現的故障注入工具可以進行故障的自動化注入，測試者只需編寫符合條件的xml測試腳本，即可完成故障注入，圖6所示即為一次故障注入的流程。其中向虛擬機管理器注入故障為本工具的核心部分，其實現過程如下：

(1)在內核函數sys_ioctl處插入jprobes探針，sys_ioctl函數在內核的入口地址由/proc/kallsyms查得；

(2)在故障函數內部判斷cmd的值，若cmd值為X，則本次系統調用為超級調用申請，程序繼續執行；若不是，則不是超級調用申請，程序退出。

(3)經判定為超級調用申請，使用copy_from_user()從傳入的指針org處得到超級調用的參數，然后將其存到hypercall中，變量類型為privcmd_hypercall，該變量數據結構包含兩個成員：op定義hypercall號，另一個為一元數組，定義hypercall的各參數；

(4)取出超級調用號hypercall.op進行判斷，如果故障注入信息中的故障位置相同，那么本次超級調用是故障注入的目標，程序繼續執行；如果不一致，則程序退出；

(5)確定本次超級調用是故障注入目標后，根據本次實驗要注入的故障類型及故障模式將對應超級調用值進行修改，然后把修改后的值傳入用戶空間；

(6)讀取故障注入信息中的故障停止時間，如果已達到要求，則取消jprobes的注冊。

進行以上步驟后，保存在用戶空間的超級調用參數是故障函數更改之后的，所以故障被成功注入。

圖6 自動化故障注入流程

2.4 前端部分

在本文的提出的架構中，前端部分負責提供圖形化交互接口，實現與測試人員的信息交互功能。其具體作用為：在故障注入開始時，收到測試者編寫的測試腳本并對其進行解析，然后將解析出的故障注入信息傳入虛擬機管理器；故障注入完成時，收集故障虛擬機的日志信息并進行記錄以反饋給測試者，從而測試者可以以日志信息中提供的實驗環境、故障類型、系統各部分故障反應等信息為依據，對本次故障注入實驗進行結果分析。

3 實驗結果分析

為了驗證本文設計工具的故障注入效果，本文基于openstack云平臺搭建Xen虛擬化系統進行實驗。依據所提出的故障模型，本文初步實現了虛擬機管理器層6類故障的注入。這些故障能夠在一定程度上反映Xen系統發生故障時的行為反應。據實驗結果，Xen虛擬化系統對各類型故障的反應行為分別為：

(1)內存管理故障，在該類型故障的實驗中，需將其分為多種故障模式進行，各種模式下的故障在實驗中的注入次數及對系統和其它各節點的影響是不同的。其中，頁表掛載和卸載故障的后果最為嚴重，通常會導致系統的崩潰，不過其故障反應不會由故障節點擴展到其它節點；頁表更新故障雖整體后果沒有上種類型嚴重，但其結果較為復雜，因為在Xen系統包含有高級頁表和低級頁表，需分別對此兩類頁表進行故障注入實驗，結果表明在注入次數較少的情況下(如每次實驗注入次數小于10次)，系統大概率可以對其容錯而不會有異常反應，但是當每次實驗注入故障次數增多時，系統無法繼續對該類故障保持容錯性，出現系統崩潰現象，同時在對兩類頁表實驗的對比中得出，系統對高級頁表的容錯性更低，更容易導致系統的崩潰，且恢復難度更大。實驗過程中，存在頁表掛載故障時，有時會出現異常而有時則不會，其結果是由特定因素決定的，若將操作碼置為一些特定值如1時就會發生異常，而其它情況則不會；低級頁表的更新故障在大多數情況下不會使系統發生錯誤，但實驗中將低級頁表項的機器地址置為一些高級頁表項的值時就會引發系統錯誤。

(2)硬件資源分配故障，其可分為Xen系統中各節點虛擬的CPU個數、內存大小等故障模式，通過對其分別進行實驗發現各模式故障的后果一致性較強且系統對該類故障的容錯性較高，只有在故障存在的情況下新建節點時會造成異常，且該異常不會使系統出現嚴重后果。

(3)狀態查詢故障，該類型故障比較簡單，包括虛擬機管理器的版本信息及環境信息等，對系統注入該類型故障時沒有出現運行上的異常情況，只是在執行狀態查詢時會出現結果的不符情況，并且實驗中只需重新啟動虛擬機管理器，該類故障就可完全修復。

(4)虛擬機遷移的故障，此類故障包括對故障節點和非故障節點進行遷移，如果只執行非故障節點的遷移而不對故障節點執行遷移，則系統無異常，即系統對該類型故障有較好隔離性，將其隔離在故障節點中而沒有使之擴散；但對故障節點執行遷移操作時，系統沒有體現出進一步的容錯能力和隔離性，故障發生了擴散導致系統出現崩潰，即故障沒有被隔離。實驗中將虛擬機遷移故障注入到目標節點中，同時正常運行同一虛擬機管理器下的另外兩個節點進行對比，現象為故障節點開始時可以正常運行，但進行虛擬機的遷移時會發生異常，并導致虛擬化系統出現崩潰。

(5)訪問控制故障，包括節點間訪問權限和各節點對硬件資源訪問權限等故障模式，實驗中注入該類型故障時沒有導致系統運行出現故障，只是會出現節點之間和各節點對資源訪問的權限發生錯誤的情況。所以該類型故障造成后果較為輕微且容易修復，及系統對該類型故障有較好容錯性。

(6)事件通道故障，注入該類型故障時，系統運行沒有出現異常，但如果在該故障存在時對節點進行遷移操作，就會發現該操作會發生錯誤不能正常進行，不過此時發生的錯誤不會造成更加嚴重的后果，且如果及時重啟虛擬機管理器可以修復這些錯誤使功能正常執行。例如實驗中存在事件通道故障時進行虛擬機遷移時，由于do_evtch_op負責處理事件通道，系統會報錯并提示該函數內部發生了錯誤，即導致虛擬機遷移發生了失敗。

根據以上實驗結果分析可得，Xen虛擬化系統可以對超級調用故障做出容錯反應，但只限于故障次數較少的情況?？傮w而言后果較為嚴重，有很大幾率會導致虛擬化系統的管理功能故障，進而造成系統的崩潰，所以Xen系統對于虛擬機管理層的故障容錯能力較低。

4 結束語

本文設計了一種面向虛擬化系統的故障注入工具架構，并依據該架構以Xen虛擬化系統為基礎實現了原型系統工具，完成了對虛擬化管理層的自動化故障注入實驗，對工具的有效性進行了驗證。通過本工具，測試者可以使用xml語言編寫故障注入腳本，實現測試環境的自動化部署和各類故障的自動化注入。實驗結果表明，本工具可以有效實現虛擬化系統管理層各類故障的注入，并可以對故障結果進行收集以支撐對系統的可靠性和容錯性評測。

[1]LI Shulin,LUO Lin,YANG Yan.Research on cloud computing and virtualization[J].Software Guide,2013,12(1):141-143(in Chinese).[李樹林,羅林,楊艷.云計算與虛擬化技術研究[J].軟件導刊,2013,12(1):141-143.]

[2]LI Yi,XU Ping,WAN Han.Research on a QEMU-based processor fault simulation and injection method[J].Computer Engineering and Science,2014,36(1):19-27(in Chinese).[李毅,徐萍,萬寒.基于QEMU實現的處理器類故障模擬與注入方法研究[J].計算機工程與科學,2014,36(1):19-27.]

[3]LEI Wei,OU Yuyi.Summary of security test methods based on fault injection[J].Modern Computer,2012,4(1):20-23(in Chinese).[雷煒,歐毓毅.基于故障注入的安全測試方法綜述[J].現代計算機,2012,4(1):20-23.]

[4]FENG Gang.Research and design of fault injectors for virtual machine in cloud computing[D].Harbin:Harbin Institute of Technology,2013(in Chinese).[馮剛.面向云計算平臺的虛擬機故障注入工具研究與設計[D].哈爾濱:哈爾濱工業大學,2013.]

[5]HU Yao,XIAO Ruliang,JIANG Jun,et al.Virtual machine memory of real-time monitoring and adjusting on-demand based on Xen virtual machine[J].Journal of Computer Applications,2013,33(1):254-257(in Chinese).[胡耀,肖如良,姜軍,等.基于Xen虛擬機的內存資源實施監控與按需調整[J].計算機應用,2013,33(1):254-257.]

[6]Guan Q,Debardeleben N,Blanchard S,et al.F-SEFI:A fine-grained soft error fault injection tool for profiling application vulnerability[C]//IEEE 28th International Parallel and Distributed Processing Symposium.IEEE,2014:1245-1254.

[7]NI Zhen.A management system of virtual machine pool based on cloud computing[D].Chongqing:Chongqing University,2012(in Chinese).[倪珍.基于云計算架構的虛擬機池管理系統[D].重慶:重慶大學,2012.]

[8]Wang Feifei,Chen Ping,Mao Bing,et al.RandHyp:Preventing attacks via Xen hypercall interface[J].IFIP Advances in Information & Communication Technology,2012,376(6):138-149.

[9]MA Yandong.Research and design of fault injection platform for virtualization system[D].Harbin:Harbin Institute of Technology,2015(in Chinese).[麻彥東.面向虛擬化系統的故障注入平臺的研究與設計[D].哈爾濱:哈爾濱工業大學,2015.]

[10]Pham C,Chen D,Kalbarczyk Z,et al.CloudVal:A framework for failure validation of virtualization environment in cloud infrastructure[C]//IEEE/IFIP International Confe-rence on Dependable Systems & networks,2013:189-196.

[11]Williams D,Jamjoom H,Weatherspoon H.The Xen-Blanket:Virtualize once,run everywhere[C]//Proceedings of 7th ACM European Conference on Computer Systems.ACM,2012:113-126.