基于故障注入的LINUX設(shè)備驅(qū)動程序測試的研究.pdf

1、基于Linux內(nèi)核的操作系統(tǒng)在世界上被廣泛應(yīng)用。一方面，超過90％的最強大的超級計算機是建立在Li nux內(nèi)核基礎(chǔ)之上的。另一方面，占領(lǐng)移動設(shè)備最大份額市場的操作系統(tǒng)Android也是基于Linux而形成的。在企業(yè)系統(tǒng)中，使用Linux的機會越來越大，因為用戶期望的是非常高的可靠性。在Linux內(nèi)核中，設(shè)備驅(qū)動程序是最為重要也最為常見的關(guān)鍵組件之一。當然，還有許多其它重要的內(nèi)核組件，例如網(wǎng)絡(luò)堆棧、文件系統(tǒng)、聲音和視頻基礎(chǔ)結(jié)構(gòu)、提供虛擬化

2、支持的子系統(tǒng)等等。
　　測試Linux內(nèi)核模塊在故障情況下的行為是很重要的。為了開展故障測試，許多科學(xué)家試圖通過不同的技術(shù)技巧創(chuàng)造一個人為的故障場景和注入相關(guān)故障。故障注入是Linux內(nèi)核模塊的一個重要研究和應(yīng)用領(lǐng)域，其主要目的是在異常情況下檢查和確認內(nèi)核組件的行為。盡管這種情況很少發(fā)生，而且難以預(yù)料，但這卻使得有關(guān)負責(zé)處理對應(yīng)故障的代碼很難檢測到或把這種錯誤限制在有限的范圍內(nèi)。在正常測試的實施過程中，唯一能夠發(fā)現(xiàn)這些問題的方法是

3、人工引入一些隨機性的錯誤。隨機故障注入的工作遠遠優(yōu)于完全沒有異常的測試，但是它也有自身的一些缺點。
　　故障注入或故障模擬技術(shù)通常通過調(diào)節(jié)故障發(fā)生和錯誤處理代碼的執(zhí)行來最大限度地減少或克服這些困難。在Linux故障注入和故障模擬方法中，可以使用不同的故障注入工具或技術(shù)，不過它們都無法滿足所有各種故障情形的注入或者在支持用戶注入自己想要注入的故障方面缺乏靈活性，然而這卻正是關(guān)于錯誤處理代碼的系統(tǒng)評估所需要的。
　　Linux內(nèi)

4、核模塊的故障模擬測試是一項重要的任務(wù)。它與用戶空間應(yīng)用程序不同，Linux內(nèi)核模塊可能會直接訪問正在被內(nèi)核的其它部分所使用的某些內(nèi)存區(qū)域。內(nèi)核模塊可以在較低層級與硬件進行通信，而且可能還擁有一些在內(nèi)核之外的空間幾乎不可能具備的其它功能。
　　故障注入通常會嘗試驗證有關(guān)系統(tǒng)響應(yīng)是否與發(fā)生在不同范圍的故障相吻合，或者有關(guān)系統(tǒng)響應(yīng)與所要求的規(guī)格不相匹配。在正常情況下，首先在系統(tǒng)分析階段確定某些系統(tǒng)狀態(tài)和時間節(jié)點，然后在相應(yīng)狀態(tài)和時間節(jié)點

5、中注入故障。測試人員往往對相關(guān)設(shè)計非常了解，然后他們會以確定的方式設(shè)計對應(yīng)的測試用例。
　　我在自己的碩士學(xué)位論文研究課題中，著重分析和研究了現(xiàn)有的一些主要故障注入工具或框架，例如LTP(Linux Test Project，即Linux測試項目)，KEDR(KernelDevice Driver at Runtime，即內(nèi)核設(shè)備驅(qū)動程序運行時故障注入)，SCSI故障注入器和Linux故障注入框架(Linux Fault Inje

6、ction Framework，簡記作LFI)。
　　在論文中，我首先描述了所有工具的一般故障注入框架，然后描述了每種故障注入工具的具體框架或工作機理。進一步說，一個對于所有工具通用的方法描述如下:
　　首先，使用不同的框架并不是一件很容易的事情。在Linux測試實驗中，我們試圖通過利用不同的框架注入相應(yīng)的故障。為此，需要分析、研究在Linux平臺上（我們具體采用的是Ubuntu桌面操作系統(tǒng)）的故障注入的一般行為特征和流程。

7、鑒于我們選擇了Linux內(nèi)核源碼、模塊和設(shè)備驅(qū)動程序作為研究目標，所以，我們通過研究故障注入對內(nèi)核的一般影響，從而整理完成了對應(yīng)不同工具所提供的不同的故障注入功能以及相應(yīng)于不同注入對象和目標的實現(xiàn)方法。經(jīng)過大量的關(guān)于Linux內(nèi)核故障注入的調(diào)查、分析、實驗和研究，最后我們決定基于四種不同的故障注入平臺(包括LTP、KEDR、SCSI和LFI)開展研究工作。
　　其次，要想有效地研究故障注入的行為，就需要根據(jù)實驗要求來選擇合適的工具

8、。故障注入工具的選擇基本上是繼續(xù)在第一步上所進行的研究，按照LFI、LTP、KEDR和SCSI這樣的順序依次選擇相應(yīng)的框架或工具進行分析、研究和實驗例證。
　　第三，在成功完成第二步之后，按照對應(yīng)故障注入實驗的具體要求，安裝所選的故障注入工具。每種故障注入工具的安裝可能會有所不同，具體取決于相應(yīng)的故障注入功能和支持要求。
　　第四，當把故障注入工具完全安裝成功后，就可以選擇相應(yīng)工具的故障支持。只能注入被選定提供的故障類型。一

9、旦選擇了故障類型，那么故障類型的參數(shù)（如概率、時間、冗余、循環(huán)和永久性等）同時也應(yīng)當被指定。成功完成所有這些步驟后，就把對應(yīng)故障注入到了目標對象或受害者身上。
　　最后，收集故障注入的測試實驗結(jié)果。每種工具都提供了自己的收集結(jié)果的各種方法(如syslog和dmesg)以及可用來保存相關(guān)輸出結(jié)果的特定文件。根據(jù)采用不同工具進行實驗所收集到的故障注入成功的有效測試結(jié)果，對它們展開縱向或橫向的比較，從而驗證它們的效率、行為、時延、容易程

10、度以及類型故障支持等。
　　1 Linux故障注入(LFI)
　　Linux內(nèi)核集成了一個故障注入框架。開發(fā)人員可以使用此框架來實現(xiàn)簡單的故障注入工具，可以測試內(nèi)核子系統(tǒng)的實現(xiàn)和設(shè)備驅(qū)動程序。本章介紹了我們在應(yīng)用Linux故障注入框架注入故障時的經(jīng)驗。
　　a) Page-fail
　　b) Failslab以及我們發(fā)現(xiàn)的局限性。
　　2 Linux測試項目(LTP)
　　在故障路徑上調(diào)整內(nèi)核執(zhí)行進程

11、的能力已經(jīng)被眾所周知很長時間了。如上所述，Linux內(nèi)核集成了一個故障注入框架，這個基礎(chǔ)設(shè)施可以被用來誘導(dǎo)不同內(nèi)核部件的任意故障。現(xiàn)在，Linux故障注入框架被應(yīng)用在LTP(Linux測試項目)測試用例，根據(jù)故障內(nèi)核故障注入。
　　LTP是本實驗的兩種方式使用:
　　a)錯誤的內(nèi)核。
　　b)穩(wěn)定的內(nèi)核
　　3運行時內(nèi)核驅(qū)動程序(KEDR)
　　KEDR強制目標模塊的某些調(diào)用失敗。KEDR主要是通過目標模塊

12、使一些調(diào)用失敗。也許，KEDR模擬故障實際上是調(diào)用特定的目標函數(shù)的失效。用戶可以對方案進行修改和控制（哪個功能可能在哪種情況下，會面臨失?。Ｔ诒緦嶒炛?，KEDR故障模擬在兩個條件下得到驗證:
　　a)在KEDR中，為kmalloc、 vmalloc和字符設(shè)備(cfake0、cfake1)注入故障。
　　b)在不同的條件下比較kedr-sample-target模塊
　　4 SCSI Fault Injector

13、>　　該工具主要集中在Linux上的RAID(md/dm-miror)軟件測試。該工具也可以適用于任何使用SCSI中間層的上層驅(qū)動程序/應(yīng)用程序。
　　本實驗中使用此工具，RAID1(dev/md0，dev/md127)通過使用選項sector_rerr.stp（通過寫入模擬可讀取錯誤）在其上應(yīng)用故障進行測試。但是它需要知道目標SCSI設(shè)備的（主要，次要）號碼?；蛘呤褂锰囟ㄎ募?，文件的inode號（例如，通過1s-i命令）指出文件

14、位置。
　　LTP, KEDR, LFI和SCSI故障注入工具用于Linux的結(jié)果從彼此各不相同。
　　對于LTP(Linux測試項目)，在錯誤的內(nèi)核下進行了三次測試，每次都有不同的概率百分比和循環(huán)次數(shù)。首先，測試了mm（內(nèi)存管理），它在錯誤的內(nèi)核下成功運行，而沒有任何的出錯信息或失敗。但是dma-threat-dio用例在錯誤的內(nèi)核下失敗了。在49個中只有7個測試通過，42個失?。?5.7％失敗發(fā)生）。在第三次測試中，錯誤

15、的內(nèi)核下的mmap壓力（內(nèi)存映射壓力）也會失敗。內(nèi)存映射壓力04完全失敗，但內(nèi)存映射壓力02會給出警告消息。
　　KEDR工具用于研究內(nèi)置模塊(Kedr-sample-target)和定制內(nèi)核模塊(ExampleLKM)的故障模擬和內(nèi)存泄漏的檢測。兩個模塊“無法分配內(nèi)存”和設(shè)備驅(qū)動程序(cfake0/cafake1)的故障模擬結(jié)果相同，兩個模塊的“出錯地址”的模擬結(jié)果也是相同的。每個模塊的檢測內(nèi)存泄漏結(jié)果有所不同，對于kedr-s

16、ample-target“allocation3和可能泄漏possible leak2”但是，自定義內(nèi)核模塊(ExampleLKM.c)“allocation2可能泄漏possible leak0”。這些結(jié)果在debugfs目錄(sys/kernel/debug/kedr-fault-simulation/cat last fault)下被進一步驗證。
　　使用SCSI工具在RAID1下注入”故障，mdadm方法用于創(chuàng)建RAID1

17、。它由sdc和sdb硬盤組成。選擇注入的故障類型為“讀取可校正錯誤”。一旦在dev/md127設(shè)備上成功注入了故障，在從syslog讀取scsi腳本之后，它顯示“SCSI-decision-decomposition major=8 minor=16 scmd=4122759912”。一旦注入了故障，sdb將被恢復(fù)，因為注入的故障sdb被更正，并且md127由于與sdb的關(guān)聯(lián)而自動恢復(fù)。
　　LFI不支持kedr-sample-t

18、arget，因為注入內(nèi)存分配失敗，模塊在讀寫操作中需要內(nèi)存分配，但對于讀寫操作沒有內(nèi)存分配功能，所以沒有故障可以被注入。每個測試對每個工具需要不同級別的空間，也可以這樣說每個工具對空間的要求是不同的。在這幾個工具中，LTP需要最大的空間，而KEDR需要較少的帶有GB的空間。每個工具所需的時間取決于當時的測試或被測試的類型。通過不同的工具成功地注入故障后，觀察哪種工具在哪個方面（比較基于特征，支持，設(shè)計和易用性）更好。LTP比其他的要更好