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

1、基于Linux內(nèi)核的操作系統(tǒng)在世界上被廣泛應(yīng)用。一方面，超過90％的最強(qiáng)大的超級(jí)計(jì)算機(jī)是建立在Li nux內(nèi)核基礎(chǔ)之上的。另一方面，占領(lǐng)移動(dòng)設(shè)備最大份額市場的操作系統(tǒng)Android也是基于Linux而形成的。在企業(yè)系統(tǒng)中，使用Linux的機(jī)會(huì)越來越大，因?yàn)橛脩羝谕氖欠浅８叩目煽啃浴Ｔ贚inux內(nèi)核中，設(shè)備驅(qū)動(dòng)程序是最為重要也最為常見的關(guān)鍵組件之一。當(dāng)然，還有許多其它重要的內(nèi)核組件，例如網(wǎng)絡(luò)堆棧、文件系統(tǒng)、聲音和視頻基礎(chǔ)結(jié)構(gòu)、提供虛擬化

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

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

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

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

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

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

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

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

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

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

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

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

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

15、的內(nèi)核下的mmap壓力（內(nèi)存映射壓力）也會(huì)失敗。內(nèi)存映射壓力04完全失敗，但內(nèi)存映射壓力02會(huì)給出警告消息。
　　KEDR工具用于研究內(nèi)置模塊(Kedr-sample-target)和定制內(nèi)核模塊(ExampleLKM)的故障模擬和內(nèi)存泄漏的檢測。兩個(gè)模塊“無法分配內(nèi)存”和設(shè)備驅(qū)動(dòng)程序(cfake0/cafake1)的故障模擬結(jié)果相同，兩個(gè)模塊的“出錯(cuò)地址”的模擬結(jié)果也是相同的。每個(gè)模塊的檢測內(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)下被進(jìn)一步驗(yàn)證。
　　使用SCSI工具在RAID1下注入”故障，mdadm方法用于創(chuàng)建RAID1

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

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