非侵入式故障注入技術研究與實現*

杜陽華

(江蘇自動化研究所,江蘇 連云港 222061)

非侵入式故障注入技術研究與實現*

杜陽華

(江蘇自動化研究所,江蘇 連云港 222061)

可靠性驗證過程需要模擬一些較為苛刻的測試場景,如出現網絡帶寬受限、內存過載、文件拒絕訪問等故障類型,而傳統方法常常會對系統資源或被測軟件造成破壞或影響。在Windows 環境下利用Detours的截獲機制研究了三種非侵入式故障注入技術,對常見的資源故障進行模擬。然后,設計開發了一款故障注入工具,能夠快速自動地在軟件測試或可靠性驗證中實施故障注入試驗,最后,通過試驗驗證了軟件實現的正確性和功能的適用性。

非侵入式;故障注入;測試場景仿真;截獲調用;故障注入工具

故障注入技術是指按照選定的故障模型,用人工的方法有意識地產生故障并施加于特定的目標系統中,觀察記錄被測系統對故障檢測及隔離的結果,并對試驗數據進行統計分析,進而給出被測系統測試性評估結果[1]。故障注入作為一種靈活方便、便宜有效的方法,可廣泛應用于計算機系統容錯性、可靠性的測試與評價領域。常用的故障注入技術主要有三種[2-4]:仿真故障注入、硬件故障注入和軟件故障注入。其中,軟件故障注入作為一種比較成熟的評測系統可靠性的關鍵技術,以其對硬件無損傷、易實現、易移植等特點,引起眾多工程設計者和研究人員的重視。國外較為常見的軟件故障注入技術主要有:可注入處理器或內存故障的Xeption[5]和HYBRID[6];可注入網絡或通信故障的ORCHESTRA[7]和FTAPE[8];可注入輸入錯誤的Ballista[9]和Fuzz[10];可模擬操作系統環境擾動的Holodeck[11]和FIG[12];直接向源代碼中注入錯誤的思想[13]。

除了在軟件可靠性領域得到廣泛的應用之外,故障注入技術在軟件測試驗證領域的應用具有更深刻的影響和意義。軟件測試過程中往往需要模擬一些較為苛刻的測試條件以驗證被測系統的穩定性,如文件讀寫、內存分配及網絡訪問等資源類故障。而傳統的強制關機方式、硬件故障注入方式、被測軟件代碼等方式不僅會對系統的硬件器件造成損傷,而且會影響計算機系統內存資源及其它軟件程序。更為重要的是，難以滿足被測軟件尤其是可靠性安全性要求較高的軟件對測試環境的精確性要求,如以100Kbps/s讀寫網絡數據,文件讀寫時間超過10分鐘等場景。

潘慶和[14]等人在Windows環境下利用Detours庫對截獲的系統調用注入故障,模擬各種文件系統錯誤，卻沒有研究如何解決上述的一些測試場景構建問題。本文正是在此基礎上利用Windows下Detours庫提供的系統調用截獲機制,在不破壞系統資源且不改變被測軟件代碼的情況下模擬文件、內存、網絡等資源故障,并開發出一款資源故障注入工具,輔助故障注入過程中場景的構建。

1 可注入故障類型分析

為了研究故障注入技術,需要研究軟件的失效機理,并根據失效機理總結可注入的故障層次和故障類型。

1.1 軟件失效原理分析

軟件缺陷是指存在與軟件中、不期望的或不可接受的偏差,以靜態的方式存在于軟件內部。當軟件運行于某一特定環境或接收特定的輸入時,該軟件缺陷會被激活,若軟件設計過程中未考慮相應的容錯機制,則該缺陷將會導致軟件發生失效,如圖1所示。

圖1 軟件失效機理示意圖

為了盡可能多地發現軟件內部潛藏的缺陷以觸發軟件發生失效,需要模擬各種可能的輸入或操作。因此,需要從軟件架構及軟件運行環境出發,分析軟件運行過程中所有可能的輸入,并實施故障注入測試。

1.2 故障注入層次及類型分析

根據軟件的體系架構及軟件運行環境分析可知,軟件所有的輸入層次可分為界面操作層、函數/組件調用層、系統資源訪問層、硬件層和網絡層等層次,如圖2所示。

圖2 故障注入層次圖

1)人機界面操作層

人機界面是軟件接收外部輸入的主要接口。用戶通過界面可以輸入任何不可控的數據,因此,對人機界面輸入或操作進行故障注入較容易發現程序中潛藏的缺陷。由于該類故障注入較易實現,因此,不屬于本文的研究對象。

2)函數/組件集成層

軟件系統由許多配置項(CSCI)集成而來;每個配置項實現一組獨立的功能,且配置項由多個獨立的軟件部件(CSC)集成而來;而部件是多個單元(CSU)組裝后的結果。由于大型軟件集成了很多的小單元、小部件,集成過程錯綜復雜,當某個單元或模塊出錯時,可能引發多處錯誤。所以有必要對集成過程進行故障注入,模擬某單元或部件出錯時,軟件是否能夠正確可靠地運行。據研究文獻統計,在對1200個軟件缺陷進行因果關系分析后,得出軟件中組件內部故障、組件功能故障和組件外部接口故障分別占10% 、30%和60%。由于軟件組件化技術的應用,軟件開發周期的后續階段中組件接口故障相對于其他類型故障占據主要地位。

3)系統資源訪問層

應用軟件運行的基礎平臺由操作系統、驅動程序和CPU等資源組成。應用軟件通過調用操作系統的API接口、內存、寄存器等軟硬件資源以完成不同的計算任務。因此,CPU、驅動程序、操作系統發生故障都有可能影響應用軟件的正常運行。所以,對應用軟件進行測試時,需模擬基礎平臺故障注入,驗證應用軟件的容錯能力。

4)網絡層

網絡的廣泛應用使得軟件之間的數據交互變得更為頻繁。網絡傳輸的可靠性由通信設備及網絡模塊保障。對數據傳輸性能有較高要求的軟件系統來說,如果網絡受到其他因素干擾影響信息傳遞的及時性,極有可能導致軟件的運行偏離預期行為。因此,為了提高應用軟件的可靠性和穩定性,需要注入網絡層故障。

綜上所述,本文研究的故障類型包括3個層次、15種故障,不同故障類型所對應的實現機制如表1所示。

表1 故障注入技術實現機制

軟件故障注入的目標可以是應用程序或操作系統。如果目標為應用程序,故障注入程序插入到應用程序中或作為應用程序和操作系統之間的一層。如果目標是操作系統,注入程序只能嵌入到操作系統中[15]。本文研究對象是應用程序,且故障注入程序處于應用程序和操作系統的中間層,而不會改變應用程序本身,因此屬于非侵入式注入方式。

2 非侵入式故障注入技術

2.1 基于系統API返回值截獲的資源類故障注入技術

為了不對實際的系統資源產生任何影響,本文采用一種“欺騙”應用程序的方式實現內存、文件、網絡等系統資源的故障注入。當應用程序訪問系統資源時,通常需要調用Windows提供的各種系統API函數,故障注入正是截獲實際的API調用,并按照故障類型直接向應用程序返回資源訪問結果。該方法不修改被測軟件的源碼,而是通過重寫系統API對應的二進制映像,并將系統調用截獲轉向自定義的函數中,從而實現故障注入,與傳統的故障注入技術相比,既不會修改軟件代碼,又不會對硬件資源產生影響，其具體實現機理如圖3所示。

圖3 資源類故障注入機理

截獲調用是由Win32下Detours庫提供的一種系統調用截獲機制。Detours定義了三個概念:

① Target函數:要截獲的函數,即Windows的API;

② Trampoline函數:目標函數的復制品,在Detours改寫目標函數前,需要先將目標函數復制保存,一方面仍然保存目標函數的過程調用語義,另一方面便于恢復;

③ Detour函數:用以替代目標函數的自定義函數。

Detours用一個轉向用戶自定義Detour函數的非條件跳轉指令取代目標函數的前幾條指令(共5個字節)。此時,Trampoline函數由兩部分構成：一部分是從目標函數中移除的指令,另一部分是指向目標函數剩余部分的非條件跳轉指令。

當執行至目標函數時,將自動跳轉至用戶自定義的Detour函數,Detour函數可以直接返至應用程序,或者可以調用Trampoline函數,該函數將調用原始的目標函數,當目標函數完成,它將控制權返還給Detour函數。Detour函數執行適當的處理并且將控制權返回給應用程序。其具體截獲調用過程如圖4所示。

圖4 Detours庫截獲應用程序調用過程

事實上,系統API的截獲和跳轉是Detours庫自動實現的,因此,研究故障注入技術的關鍵步驟是定義自己的Detour函數。根據實現的具體方式不同,可將Windows下的故障分為基于返回值錯誤代碼的故障注入技術和基于Sleep函數的故障注入技術兩類。為了便于區分,命名時所有真實的Win32 API統一定義為Real-,其對應的Detour函數定義為Mine-。

1)基于API返回值錯誤代碼的故障注入技術

該故障注入技術的實現過程中,應用程序并不需要調用真實的API,而是在Detour函數中模擬系統函數向應用程序返回一個故障代碼。

本文以注入讀文件故障為例,真實的讀文件API為Real-ReadFile,其對應的Detour函數Mine-ReadFile,Mine-ReadFile的部分代碼如下所示。

BOOL WINAPI Mine-ReadFile(

HANDLE hFile,LPVOID pBuffer, DWORD nNumberOfBytes, LPDWORD lpNumberOfBytes, LPOVERLAPPED lpOverlapped

)

{

DWORD error;

BOOL rv;

… …

∥模擬文件讀故障

error=

evaluateReadFileFaults(handle2name(hFile), NULL);

SetLastError(error);

return false;

}

事實上,Mine-ReadFile中并沒有直接調用真實的Real-ReadFile,而是通過直接向應用程序返回false,即意味著應用程序進行讀文件時發生錯誤。類似可模擬故障包括文件打開故障、文件寫故障、內存分配故障等故障類型。

2)基于Sleep函數的故障注入技術

基于sleep函數的故障注入技術可以實現的故障類型包括文件過大、網絡數據讀寫帶寬受限等類型。與基于API返回值故障代碼的故障注入方式不同,基于Sleep函數的故障注入技術需調用真實的系統API,并利用Sleep函數實現延遲效果,間接模擬出各類帶寬受限故障。

本文以發送網絡數據的帶寬受限故障為例,真實的API為Real-send,其對應的Detour函數Mine-send,Mine-send的部分代碼如下所示。

int WINAPI Mine-send(SOCKET a, char* b, int netWRdata, int t)

{

int rv;

… …

∥模擬發送網絡數據的帶寬受限故障

rv=Real-send(a, b, netWRdata, t);

DWORD time=(DWORD)((float)(netWRdata)/netWRBandwidth);

Sleep(time);

return rv;

}

在上述代碼中,Detour函數首先調用真實的系統函數Real-send完成網絡數據的發送,然后計算出在限定帶寬下發送網絡數據所需的時間,并利用Sleep函數實現延遲的效果。讀文件所需時間的計算公式為:

time=netWRdata/netWRBandwidth

其中,netWRBandwidth代表用戶設置的帶寬大小,netWRdata代表文件的大小。因此,可以通過延遲讀寫文件的時間模擬出文件過大的故障現象。

2.2 基于符號表的內存擾動故障注入技術

代碼故障注入技術是利用編譯器生成的符號表來實現故障注入。符號表是一種用于編譯器中的數據結構,符號表中保存程序源代碼中的每個標識符及其聲明、使用信息,如數據類型、作用域及內存信息,如圖5所示。

通過在軟件運行期間,根據內存地址動態修改被測軟件源代碼的全局變量、函數參數、函數返回值方式實現故障注入，其具體過程如圖6所示。

圖5 gcc符號表示例

圖6 基于符號表的故障注入思路

步驟1:根據故障注入的需要,制定類符號表模板

符號表為存放源程序中出現的有關名字的屬性信息的文件,屬性信息反應了名字的語義特征屬性,符號表中包含編譯時節點的各種屬性,包括類型、作用域、分配空間大小、函數的參數類型等;

根據故障注入的需要,只需要符號表中的部分信息,包括:函數/變量與內存地址的對應關系以及占用內存空間的大小;

類符號表模板為二維表模型,包括序號、過程標識、標識符名稱、地址和符號類型;

需要根據類符號表提取的信息包括:待注入故障的變量及函數的標識、地址、類型;其中,要求標識能在被測軟件類符號表中唯一地標識一個函數或變量;通過讀取符號表,地址、類型可以直接確定,對于過程中存在的重名變量或函數,不同符號表由不同的組織方式,需要兩個字段來唯一地確定。

步驟2:根據類符號表模板建立類符號表

類符號表模板是為實現快速查詢符號信息而建議的統一數據格式,要對被測軟件實施故障注入,需要解析源符號表,把可用信息解析成符合類符號表模板的格式,生成類符號表。

從分表結構的符號表到類符號表需要滿足如下條件:

R1:對符號表取唯一標識對應類符號表模板中的過程標識;

R2:將符號表填充到類符號表的過程標識列,遍歷該符號表,取標識符名稱填充到類符號表中的標識符名稱列,取標識符類型填充到類符號表中的符號類型列,取地址填充到類符號表中的地址列;

R3:當類符號表中增加一條數據時,類符號表中的序號自增;

R4:類符號表中的過程標識列不可為空。

從單表結構的符號表到類符號表需要滿足如下條件:

R1:遍歷符號表中的所有標識符,當類符號表中增加一條數據時,類符號表中的序號自增;

R2:取標識符名稱填充到類符號表中的標識符名稱列,取標識符類型填充到類符號表中的符號類型列,取地址填充到類符號表中的地址列;

R3:符號表中層次填充到類符號表中的過程標識列。

通過遍歷被測軟件符號表的方法,根據以上制定的填充規則,填充類符號表模板,生成被測軟件的類符號表。

步驟3:根據故障注入四元組建立類符號表對應的故障模型;其中四元組包括故障類型、故障持續時間、故障位置和故障觸發條件

采用四元組來描述故障模型:故障類型(M)、故障持續時間(D)、故障位置(L)和故障觸發條件(T),故障模型表示為:(M,D,L,T);

故障類型(M)包括:對指定的變量、函數參數以及返回值取反、置零、置1、與設定的掩碼進行與/或運算;

故障持續時間(D)包括兩種形式:時鐘時間,以ms為單位,從觸發后開始計時;兩個事件發生的間隔時間,第一個事件發生時,故障注入觸發,記為開始事件,第二個事件發生時,故障注入結束,記為結束事件,持續時間為結束事件發生時刻減去開始事件發生時刻得到的時間差;

故障位置(L)通過查找類符號表確定;L為一個地址范圍,通過查詢條件“過程標識”和“標識符名稱”唯一地檢索到符號表中某條記錄的“地址”字段,該字段即為L的起始地址,由于各符號存在不同的數據類型,占用的內存空間大小不一,所以還需要檢索類符號表中的符號類型,作為確定L地址范圍的依據;

故障觸發條件(T)包括兩種方式:時間和事件;當故障觸發條件(T)為時間時,故障持續時間(D)為時鐘時間;當故障觸發條件(T)為事件時,故障持續時間(D)為兩事件之間的時間間隔。

步驟4:根據類符號表對應的故障模型,通過查找類符號表,確定冗余空間大小和注入故障后軟件的運行路徑,實現故障注入。

采用更改被測軟件運行時內存訪問路徑的方式,實現故障注入。故障注入機制如下:

1) 根據故障模型中的故障位置,在內存中開辟一段冗余內存空間,大小與故障位置中的符號類型相符;

2) 根據故障模型中的故障類型,在新開辟的冗余內存空間中填寫設定的故障值;

3) 改變被測軟件的運行路徑,用冗余內存空間替代源內存空間;當CPU加載故障位置中指定的地址指令時,改變被測軟件運行路徑,訪問冗余內存空間,之后跳轉回源路徑。

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

3.1 故障注入工具框架設計

基于上述技術研究,本文開發實現了一款非侵入式故障注入工具,該工具由FIM(Fault Injection Manager)和FIK(Fault Injection Kernel)兩部分組成。

其中,FIM的設計遵循MVC架構,并且以插件形式嵌入在Eclipse平臺中運行。FIM的界面如圖7所示。

圖7 FIM主界面圖

FIK是一個使用C/C++開發,僅有20K左右的輕量級軟件。FIK運行在被測設備上,可在FIM的控制下向被測軟件進行故障注入。FIK包含FIKLauncher和FIKDLL兩部分,其中,FIKLauncher為FIK界面,負責與FIM建立連接并通信;FIKDLL為FIK的核心程序,用于實現具體的故障注入。FIKLauncher界面如圖8所示。

圖8 FIKLauncher界面

FIM與FIK之間通過以太網進行通信,交互信息采用XML的形式。FIK啟動后向FIM發出連接請求,由FIM確認后將需要注入的故障信息發給FIK。

3.2 故障注入實例

軟件測試不僅要驗證正常情況下軟件的實現是否正確,更應該驗證錯誤輸入或非法操作時,軟件的異常處理能力,將故障注入機制引入軟件測試可以有助于提高軟件的穩定性和健壯性。

JariFI可以注入文件、內存、網絡、進程等數十種故障類型,實例驗證時逐一對各種故障進行實驗和驗證,由于篇幅所限,表2中僅顯示了文件訪問故障、文件讀寫帶寬受限兩類故障注入試驗的記錄,使用故障注入工具向被測程序resource-test.exe注入上述兩類故障,具體過程如表2所示。

表2 故障注入試驗記錄

試驗數據表明, 故障注入工具的實現是正確的,另外,在對被測程序進行故障注入時,我們同時打開Windows中的notepad.exe,并無異?，F象,由此可以說明文中研究提出的故障注入技術僅僅對被測程序有效,而不會影響到系統中的其它軟件程序,即故障注入的范圍得到有效控制,這也是JariFI與其它同類故障注入工具相比的優勢之一。

4 結束語

故障注入技術不僅可以廣泛應用于軟件可靠性、容錯性評估驗證領域,還可以應用于軟件測試領域,以模擬一些手工方式難以控制或實現的測試條件。本文利用研究提出了三種系統資源故障注入技術,并詳細敘述了如何利用Detours庫的截獲機制來模擬文件讀寫錯誤、網絡數據讀寫帶寬受限故障、內存過載故障等資源訪問故障,且并不會對實際的系統資源和被測軟件代碼產生破壞。最后,開發了一款故障注入工具JariFI,可以輔助測試人員自動實現各類資源故障注入過程。本文的研究成果可以輔助開發人員、測試人員進行軟件測試及可靠性驗證,具有一定的現實指導意義。

未來可以從以下兩個方面對故障注入工具展開進一步的研究:

1)事實上,每一個系統API或API的組合都可以對應一類可注入故障,只要該故障具有實際的應用場景及價值。

2)故障觸發機制是控制故障注入過程的核心,JariFI中提供了事件和時間兩種故障觸發機制,事件類型及多事件間的順序控制有待進一步研究。

[1] Jarboui T Alart J, Crouzet Y, et al.Experimental Analysis of the Errors Induced into Linux by Three Fault Injection Technology[C]. IEEE Proceedings of the International Conference on Dependable Systems and Networks, 2002:6-11.

[2] Barbosa R, Silva N, Duraes J, Madeira H. Verification and Validation of (Real Time) COTS Products Using Fault Injection Techniques[C]. Proc. of the 6th Int’l IEEE Conf. on Commercial-off-the-Shelf (COTS)-Based Software Systems (ICCBSS 2007). Los Alamitos: IEEE CS, 2007: 233-242.

[3] Lopez-Ongil C, Entrena L, Garcia-Valderas, et al. A Unified Environment for Fault Injection at Any Design Level Based on Emulation[J]. IEEE Trans. On Nuclear Science, 2007, 54(4): 946-950.

[4] Blanc S, Gracia J, Gil P J. A Fault Hypothesis Study on the TTP/C Using VHDL-Based and Pin-Level Fault Injection Techniques[C]∥Proc. of the 17th IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems. Los Alamitos: IEEE CS, 2002: 254-262.

[5] Carreira J, Madeira H, Silva J G. Xception: Software Fault Injection and Monitoring in Processor Functional Units[J]. IEEE Trans on Software Engineering, 1998, 24(2):1-25.

[6] Young L T, Iyer R K, Goswami K K, et al. A Hybrid Monitor Assisted Fault Injection Environment[C]∥The Third IFIP Working Confernce on Dependable Computing for Critical Application, 1992.

[7] Dawson S, Jahanian F, Mitton T. ORCHESTRA: A Probing and Fault Injection Environment for Testing Protocol Implementions[C]∥Proceedings of IEEE International Computer Performance and Dependability Symposium, 1996: 56.

[8] Tsai T K, Iyer R K. Measuring Fault Tolerance with the FTAPE Fault Injection Tool[C]∥Proceedings of the Eighth International Conference on Modeling Techniques and Tools for Computer Performance Evaluation. 1995: 26-40.

[9] Kropp N P, Koopman P J, Siewiorek D P. Automated Robustness Testing of Off-the Shelf Software Components[C]∥Proceedings of the 28th International Symposium on Fault-Tolerant Computing, 1998:464-468.

[10]Miller B P, Fredriksen L, So B. An Empirical Study of the Reliability of UNIX Utilities[J]. Communications of the ACM, 1990, 33(12):32-44.

[11]Center for Software Engineering Research[EB/OL]. Holodeck. http:∥se.fit.edu/holodeck/, 2002.

[12]Broadwell P, Sastry N, Traupman J. FIG: Fault Injection in Glibc[C]∥In Workshop on Self-Healing, Adaptive, and Self-Managed Systems (SHAMAN), New York, 2002.

[13]Barton J H.Fault Injection Experiments Using FIAT[J].IEEE Transactions on Computers,1990,39(4):575-582.

[14]潘慶和. 軟件故障注入關鍵技術研究[D]. 哈爾濱:哈爾濱工業大學,2011.

[15]潘慶和. 基于軟件的故障注入方法研究[D]. 哈爾濱:哈爾濱工業大學,2005.

Research and Implementation of Non-Intrusive Resource Fault Injection Tool

DU Yang-hua

(Jiangsu Automation Research Institute, Lianyungang 222061, China)

There are some traditional methods to simulate those falults, but these methods often make damage on the system resource or the code of the SUT. Using the interception service of Windows system, non-intrusive resource fault injection methods are proposed to simulate some common resource faults. Then, a fault injection tool named JariFI is designed and it can inject faults needed in software testing and reliability evaluation。At last, the accuracy and the function applicability about the software are verified by the experiment.

non-intrusive; fault injection; simulation of testing scenario; intercept call; fault injection tool

2016-11-03

總裝備部“十二五”預研項目

杜陽華(1979-),男,湖北武漢人,碩士,高級工程師,研究方向為系統工程、軟件仿真與測試性。

1673-3819(2017)01-0109-07

TP311；E917

A

10.3969/j.issn.1673-3819.2017.01.024

修回日期： 2016-11-29