面向硬件瞬時故障的Linux設備驅動敏感代碼的自動分析與檢測

馬培++翟高壽

摘要：操作系統是整個計算機系統的核心，而設備驅動程序則占據操作系統內核的相當份額并對系統安全產生舉足輕重的作用。作為主機與外圍設備之間通信控制的橋梁，設備驅動無疑會受到硬件設備故障的直接影響。在Linux系統中，驅動程序問題是造成系統安全的主要根源之一。特別地，由于設備驅動代碼的編寫往往沒有考慮到硬件設備的瞬時故障，所以當硬件設備發生瞬時差錯的時候，就有可能導致相應驅動程序甚至整個系統出現不可預料的后果。本文主要討論了面向硬件瞬時故障的驅動程序敏感代碼的自動分析方法，并設計和實現了對應的代碼分析工具原型。運用該工具原型對Linux內核設備驅動源碼的實驗分析結果表明，該方法和原型可以發現設備驅動中潛在的受到硬件設備瞬時故障影響的敏感代碼。據此，采用適當方法對敏感代碼進行修復完善，將可以實現設備驅動程序的安全加固。

關鍵詞：設備驅動程序；硬件瞬時故障；敏感代碼；Linux；自動分析

中圖分類號：TP311

文獻標識碼：A

DOI：10.3969/j.issn.1003-6970.2015.12.003

本文著錄格式：馬培，翟高壽.面向硬件瞬時故障的Linux設備驅動敏感代碼的自動分析與檢測[J].軟件，2015，36（12）：09-15

0 引言

可靠性對于操作系統來說一直是最重要的問題，由于計算機已經深深嵌入到我們的生活中，并且故障一旦發生我們很難有機會能彌補，因而我們需要計算機更高的可靠性來保證系統運行的正確性。

應用程序是通過設備驅動程序喚起設備，而設備和驅動程序的交互是通過硬件指定的一個特定的協議，如果硬件設備遵從這些特定的協議，那么驅動程序就會完全的信任它并接受來自它的任何輸入。不幸的是設備常常不能按照這樣的規章行事，某些故障是由于磨損或者電磁干擾引起的，導致往驅動輸入的數據發生改變，由于驅動在Linux內核中，就可能導致不可預料的系統故障。我們將驅動程序中由于硬件的瞬時故障而可能導致驅動出現問題的代碼稱為敏感代碼。微軟windows服務器的研究證明：（l）設備故障是引起系統崩潰的主要原因；（2）短暫性的硬件設備故障是正常的現象；（3）驅動程序容忍硬件設備故障能提高系統的可靠性。沒有解決這些問題，操作系統的可靠性就會由于設備及驅動的可靠性而被限制。

針對設備瞬時故障如何自動分析和檢測驅動程序的敏感代碼，我們主要是通過驗證來自設備的所有輸入，并且報告所有存在的故障以使得管理員能夠主動管理硬件錯誤。本文提出通過代碼分析工具分析設備驅動程序代碼，找到驅動中使用來自設備輸入的位置，即敏感代碼在驅動程序中的位置。如果驅動程序使用了沒有通過正確檢查的設備輸入數據并且該數據不正確，我們就通過修改驅動程序以插入驗證代碼，實現驅動容忍硬件瞬時故障的目的。我們實現了當瞬時故障發生并導致驅動出現問題的時候，使用系統日志的方式報告相關的硬件故障。為了修復相應的硬件故障所造成的驅動甚至內核錯誤，我們引入了一個通用的恢復服務，這個服務可以重置設備。我們依賴于使用隱匿驅動程序來提供這種修復的服務，從而能夠針對設備故障實現驅動的恢復機制。

本文提出面向硬件瞬時故障的驅動程序敏感代碼的自動分析方法，實現了自動分析工具原型。通過執行自動分析工具表明，該方法可以準確檢測到驅動程序中的敏感代碼，并實現驅動程序的加固，提高驅動及系統的可靠性。

1 硬件瞬時故障及敏感代碼

1.1 硬件瞬時故障

現代的CMOS設備傾向于發生內部錯誤，并且在當晶體管萎縮的情況下這種錯誤會更加嚴重。以前的研究表明某些設備會發生短暫的比特位反轉錯誤，即單個比特位從1變為0或從0變成1；永久性的門級故障，即在一段較長的時間內某一比特保持固定值；橋接故障，即相鄰比特對發生電力干擾從而在比特間產生邏輯與門、邏輯或門。環境條件的改變如電磁干擾或者輻射都能導致產生短暫性故障。設備的磨損和老化也可能導致門級故障或者橋接性的錯誤。

設備驅動程序訪問來自設備的輸入的時候會偵查故障，如PCI驅動，通過內存或I/O端口執行I/O操作，設備驅動可能會在I/O中讀取到設備中的錯誤的值；如USB驅動，使用請求/響應協議，設備故障可能導致響應包中包含錯誤的數據。很多硬件故障表現為在設備寄存器中存放了被篡改的值，如設備控制器內部的單比特反轉可能傳播到某些內部寄存器，而設備驅動程序讀取到這個內部寄存器中被篡改的值的時候就可能會發生故障。門級故障也可能存在上述同樣的問題。當硬件設備不能在規定的時間內響應，在設備固件中的錯誤表現就可能會是不正確的輸出數據或超時故障。

1.2 敏感代碼

敏感代碼即驅動程序中由于硬件的瞬時故障導致驅動出現問題的代碼。各類硬件紛繁復雜質量層次不齊，驅動可能由于物理設備出現偶發性的瞬時故障而影響驅動及系統的安全可靠性。驅動對外設的訪問主要是通過I/O端口，I/O端口即外設寄存器，是接口電路中能被CPU直接訪問的寄存器地址。幾乎每一種外設都是通過讀寫設備上的寄存器來進行工作的。Linux下訪問I/O端口的方式主要有兩種I/O映射方式和內存映射方式。I/O映射方式是直接使用I/O端口操作函數，即使用inb（），outb（）等函數進行端口訪問，內存訪問方式是將I/O端口映射為內存進行訪問，即使用I/O內存的函數進行端口訪問。當發生硬件瞬時故障的時候可能會篡改I/O端口操作函數、I/O內存函數的返回值，導致驅動從I/O端口讀取到的數據是不正確的值。當該數據被應用到驅動代碼中不恰當的位置如作為循環條件或數組下標時，就可能導致驅動出現無限輪詢或數組越界錯誤，從而影響驅動運行的正確性，降低驅動及系統的可靠性。因此，我們將驅動代碼中使用I/O端口操作函數，并將這些I/O端口函數直接或間接應用在循環條件或數組下標中的代碼稱之為敏感代碼。

2 設備驅動敏感代碼自動分析方法的設計

大部分操作系統供應商向設備驅動程序編寫者提出建議：如何固化驅動程序能夠容忍硬件故障，（1）驗證：我們認為從設備中獲取的所有的輸入都是可疑的，都需要進行驗證才能確保數據在正確的范圍內；（2）超時：當設備一直沒有響應的時候，對于所有與設備的交互都應當有響應的措施來應對超時從而防止永久性的等待；（3）報告：所有可疑的行為或者操作都需要報告給操作系統服務器，從而方便對硬件故障的集中偵查和管理；（4）恢復：設備驅動程序應當能從任何的設備故障中恢復，如果需要可以通過重置設備來達到恢復的目的。

我們的目標主要就是能自動完成上述建議。總體設計方案如圖1所示，首先，我們試圖使得驅動程序能夠容忍設備故障并能夠從設備故障中恢復，從而防止了設備故障導致系統崩潰。我們主要針對的是短暫性的故障，即當重置設備后這樣的故障不會再重復發生。其次，我們讓設備驅動程序報告設備故障，使得系統管理員能夠知道存在的短暫性故障并及時的處理故障設備。自動分析方法設計的過程主要是（l）分析驅動與設備交互的原理從而確定I/O端口及I/O內存操作函數，（2）分析驅動程序中直接或間接使用I/O端口操作函數的位置即找到所有受I/O影響的變量，（3）標注敏感代碼即被修改的變量被使用在循環條件或數組下表的位置。由于短暫性的硬件故障是偶發性的，我們需要用到簡單的故障注入工具進行模擬硬件故障，從而達到驗證實驗的目的。

2.1 110端口及I/O內存操作函數

Linux操作系統內核主要有主內核、內存管理、網絡、文件系統及其設備驅動等目錄。其中驅動設備通常不會完全集成到內核代碼中，且對應于設備的驅動程序也通常是由第三方編寫實現，因此容易在與內核模塊通信、系統調用等方面產生錯誤，從而波及到系統的其他內核模塊導致系統崩潰。實踐證明，在導致系統故障的代碼中，有50%以上的錯誤是由設備驅動程序引起的。

在Linux系統中，主機與外界交換信息是通過輸入輸出設備進行的，輸入輸出設備與系統的交互式是使用驅動這個中間媒介，驅動通過訪問I/O端口實現與硬件設備的通信。由于CPU對外設端口物理地址的編址有兩種方式：I/O映射方式和內存映射方式，所以驅動訪問I/O端口也有兩種途徑：其一為I/O映射方式即是直接使用I/O端口操作函數；其二是內存映射方式即將I/O端口映射為內存進行訪問。這兩種方式都要使用相應的I/O端口及I/O內存操作函數對數據進行讀寫。I/O端口操作函數主要包括inb（），inb_p（），insb（），outb（），outb_p（）等。I/O內存操作函數主要有ioread8（），ioport_map（），readb（），readl（）等。當硬件發生瞬時故障，可能影響這些函數的返回值，使得驅動讀取到錯誤的值而使驅動出現運行錯誤，影響驅動甚至系統的可靠性。

2.2 自動分析方法

設備驅動程序依賴于硬件的正確性以確保自身的正確性，我們通過對驅動程序代碼進行靜態分析找到驅動程序中使用源于設備的數據的位置，并且驗證數據的有效性，防止在執行代碼之前讀取到非有效的數據而導致不可預料的系統錯誤。靜態分析過程的輸入主要是整個Linux源碼中的驅動代碼，即/Linux/drivers和/Linux/sound下的所有文件，輸出是驅動程序源碼中直接或間接使用I/O和內存操作函數的位置和敏感代碼，即可能潛在的故障源列表。

自動分析方法主要是對系統驅動代碼進行掃描，首先針對驅動的每一個文件進行詞法分析，分析出所有變量、常量、函數、界符等。然后對驅動文件進行語法分析，找出所有的使用I/O端口操作函數和I/O內存函數的位置，并標注被I/O操作函數直接或間接修改的變量。最后找出被修改的變量被應用在循環條件或數組下標的位置，即找到驅動中與硬件瞬時故障相關的敏感代碼。

針對自動分析結果所找到的敏感代碼，我們的處理機制是在敏感代碼處插入超時、越界檢查和引入自動修復機制。當發生設備瞬時故障并引起驅動程序發生無限輪詢或數組越界錯誤時，則會喚起通用的恢復服務，即隱匿驅動程序，對設備進行重置，從而達到恢復的目的。

3 原型實現及驗證

該原型實現的開發平臺是Ubuntu12.04，在Sourceinsight和Gedit下實現代碼的編寫，開發語言為C語言，使用Makefile和gcc4.8.1實現編譯功能，使用gdb代碼調試工具對自動分析工具進行調試運行。

3.1 原型實現

本文提出的加固驅動程序主要是排除硬件依賴性故障，固化驅動程序的工作流程如圖2可分為三個部分，分別為分析驅動源碼找到驅動程序使用源于設備的數據的位置、驗證驅動程序獲取硬件數據的有效性、插入代碼對潛在的故障進行修復。找到驅動程序中使用1/0操作函數的位置主要是對驅動程序代碼進行詞法分析和語法分析用以識別各種類型的語句，檢測出與硬件通信相關的I/0操作函數的使用位置并進行標注。驗證相關硬件數據的有效性是對從硬件獲取的數據進行有效性檢查，如：添加計時器，檢查數據范圍等。插入代碼進行修復是當硬件依賴故障偶然性的發生時我們插入代碼，引入通用的自動修復機制，對硬件進行重置從而達到容忍硬件故障的目的。為實現對Linux內核源碼中的所有文件應用自動分析工具，我們通過編寫shell腳本，實現對所有驅動文件進行遍歷，在遍歷過程中執行我們的分析過程。

敏感代碼檢測分析流程如圖3所示。主要有四個部分組成：驅動程序代碼的預處理、詞法分析、語法分析、靜態分析輸出敏感代碼。

3.1.1 設備驅動源程序的預處理

預處理驅動程序是分析代碼的第一步，它主要處理C語言中的各種預處理語句和注釋。處理的預處理語句主要包括#define、#error、#include、#if、#else、#ifdef、#line等。同時在預處理階段刪除“//”和以“/*”開頭以“*/”結尾的注釋，以方便后續代碼分析。

預處理后生成與分析驅動文件所對應的*.tmp文件。處理后的文件中沒有注釋行，并且完成了宏定義的替換，被include包含的文件也被插入到相應的位置。

3.1.2 詞法分析

詞法分析主要是對經過預處理的程序代碼進行分析，得出相關單詞符號如關鍵字（int、struct）、變量、常量（十進制、十六進制等）、運算符（+、-、*、/等）、界符（，、；、（等）等，將這些單詞符號放入到相應的符號表中。該詞法分析主要檢測的是變量，以方便后續靜態分析找到被I/0操作函數影響的變量。

經過詞法分析將相關的單詞符號填入到符號表中，用于記錄源程序中各種單詞符號的屬性和特征。本文變量和函數的符號表的定義如下：

（l）變量標識符的符號表否為I/O操作函數*/

}FuncTable：

3.1.3 語法分析

語法分析主要是在完成詞法分析的基礎上對代碼進行語法結構的分析。該分析過程用于獲取與變量和函數相關的信息存入到符號表中，為后續的靜態分析做準備。

（l）提取變量相關信息，將驅動代碼中出現的每一個變量的行號都記錄下來，存放在變量符號表的定義變量和使用變量的字段中。

（2）提取函數相關信息，標識每個函數所定義和使用的變量，并記錄下函數體內所引用的函數名等。

3.1.4 敏感代碼的檢測

通過上述的分析過程，我們能準確的標識出驅動源碼中所有的標識符及其引用流程，我們靜態分析的過程包括兩步，第一步是標識出驅動程序中直接或間接使用I/0端口函數和I/0內存函數的位置，并找到被這些函數修改的變量標注在變量符號表的tainted字段中。第二步是找出被修改的變量或I/0操作函數應用在循環條件和數組下標的行號，將其標注為敏感代碼輸出到Taintedfor.txt中。

當被修改的變量被應用在驅動程序的循環條件中，而由于偶發性的硬件故障而導致該變量從硬件讀取來的數據不是預期的值，那就可能導致驅動進去死循環永遠都不能跳出來。由于驅動和系統內核有著千絲萬縷的聯系，驅動的無限輪詢就可能導致不可預料的系統故障。當被修改的變量被應用在全局或局部數組變量的下標中，由于數組下標有范圍界限，若因為偶發性的硬件故障而導致從硬件獲取的數據值不在該數組的合法范圍內，驅動就會因為存在越界錯誤而導致系統問題。

3.1.5 敏感代碼的修復與報告

針對上述分析出的潛在的故障因素，我們需要對其進行修復。對于無限輪詢故障，主要是在驅動中插入代碼打破無限輪詢的條件?；诙啻螌︱寗哟a的延時測試和其他設備所使用的延時，我們使用最大的延時。我們在循環內添加計時器，并設置最大延時時間。當在循環體內循環的時間超過我們設置的最大延時時間時，我們就認為該循環陷入了無限輪詢，此時我們引入通用的恢復服務隱匿驅動程序對硬件進行重置，重新獲取硬件相關的信息。對于數組越界問題，我們主要是根據驅動代碼上下文，在被修改變量用在數組下標之前的位置處對該變量進行條件判斷，若變量值在數組范圍外，則引入通用的恢復服務，對故障進行恢復。

在對無限輪詢和數組越界的驅動錯誤進行修復后，當確實出現硬件故障的時候我們使用printk函數實現系統日志通知系統管理員發生了硬件故障，以便于系統管理員對故障進行管理和維護。

3.2 實驗驗證

3.2.1 敏感代碼自動檢測結果分析

我們靜態分析的對象主要是整個Linux內核驅動，內核版本為Linux2.6.18。通過分析drivers和sound目錄下的6000多個源程序文件，這些文件包括的驅動類主要有網卡驅動、聲卡驅動、視頻驅動、SCSI驅動和其它類驅動，從靜態分析的輸出文件中發現了大量的潛在的無限輪詢和數組越界錯誤。分析結果表明驅動的硬件依賴性故障是普遍存在的，只有盡量避免這些潛在的錯誤才能提高操作系統的可靠性。

使用隨機抽樣方法檢查驅動代碼分析結果表明：誤報率低于9%。對于無限輪詢錯誤，我們檢查了100個例子，只是發現了10個誤報，誤報原因主要是該驅動自身已經實現了檢查和修復方法，但這種誤報并不會對驅動造成損害，唯一可能的損害就是增加了少量的不必要的開銷。

3.2.2 敏感代碼修復與故障報告

通過使用自動分析工具對驅動源碼進行分析，我們能得到所有驅動類中潛在的硬件依賴性故障。由于對驅動進行測試依賴于硬件，我們不可能擁有內核驅動所對應的所有的硬件，所以我們主要對已經存在的硬件進行驗證，如電腦本機的網卡和聲卡。由于短暫性的硬件故障是偶發性的，我們無法預期什么時候會發生，所以我們引入了故障注入工具，模擬硬件故障的發生。通過故障注入工具模擬硬件故障，我們測試了固化前的驅動和固化后的本機網卡驅動。在測試過程中，我們發現對于固化后的驅動代碼示例如下圖4所示，當發生了硬件瞬時故障的時候能夠喚起通用的恢復機制對硬件進行重置，驅動程序再次讀取相關信息可以正常運行，而對于固化前的驅動，由于發生了短暫性的硬件故障，導致了驅動不能正常運行下去。正是由于我們插入的修復代碼和引入驅動的恢復機制，當發生硬件故障時候，我們的驅動程序能夠容忍硬件瞬時故障，從而實現在軟件中容忍硬件故障的目的。

對于故障的報告分析，我們主要是報告設備超時（驅動代碼發生無限輪洵）和報告驅動代碼數組越界。由于Linux沒有故障管理服務，我們使用printk來實現系統日志。系統管理員可以通過在終端輸入命令dmesg或者進入Linux系統日志目錄進行查看。對于設備超時的故障報告主要是當由于硬件瞬時故障而導致驅動程序發生無限輪詢錯誤的時候通過printk函數以infinite loop為標識寫系統日志。系統管理員通過infinite loop為標識查看是否發生該類故障。對于數組越界的錯誤報告主要是當驅動代碼由于硬件故障而發生數組越界錯誤的時候通過printk函數以Array out of range為標識寫系統日志。系統管理員通過Arrav out of range查看是否發生數組越界故障。通過dmesg查看系統日志發現，我們能正確的報告發生的相關驅動故障，從而方便管理員對故障進行管理和維護。

4 測試評估

4.1 功能測試評估

為了評估自動分析工具的功能準確性，我們定義誤檢率和漏檢率。誤檢率即某處不是受硬件瞬時故障影響的敏感代碼，而自動分析工具卻標注其為敏感代碼，在整個掃描過程中出現這種誤報的概率。某處是受硬件瞬時故障影響的敏感代碼，但自動分析工具卻沒有標注其為敏感代碼，這種漏報的概率稱為漏報率。

本文主要是對2.6.18的內核版本應用我們的自動分析工具，驗證了這種分析方法能夠正確的查找到所有驅動模塊的敏感代碼，按照驅動類劃分查詢到的敏感代碼數量如下表1所示。

通過靜態分析和有效性檢查，我們對整個Linux內核驅動代碼進行全盤分析掃描，主要是查找兩類硬件依賴故障即無限輪詢和數組越界錯誤。對于短暫性硬件故障導致驅動程序的無限輪詢，在網卡驅動類中查找到110個潛在的錯誤，在scsi驅動類290個潛在的錯誤，在整個Linux驅動中總體查找到740個錯誤。對于靜態數組越界的敏感代碼，我們在Linux驅動中共查找到43個潛在的錯誤。上述錯誤充分說明潛在的硬件依賴性錯誤在內核驅動代碼中是普遍存在的且是亟待的問題。

通過對2.6.18和3.2.1內核版本的驅動源碼使用自動分析工具進行比較，內核版本為3.2.1的內核源碼所檢測到的敏感代碼比2.6.18少，并通過抽樣檢查其誤報率和漏報率均較小且差別不大。由于內核版本為3.2.1是2.6.18的升級，所以檢測到的敏感代碼少是合理的。比較結果證明，我們的自動分析工具能夠對不同內核版本的驅動的敏感代碼進行準確的分析。

我們針對本機的網卡驅動通過引用故障注入工具模擬短暫性的硬件故障，對修改前和修改后的驅動進行測試，修改前的網卡驅動會產生無限輪詢錯誤導致本機網卡驅動出現無法修復的問題，而修改后的驅動能正確的容忍硬件依賴性故障，喚起通用的驅動恢復服務并告知系統管理員發生了短暫性的硬件故障，達到我們預期的效果。

4.2 性能評估測試

性能評估主要是評估檢測敏感代碼系統能力及故障恢復性能，識別出系統存在的弱點并驗證該系統的穩定性。本文采用系統性能測試，對系統性能進行全面的評估，主要包括宏觀性能測試和微觀性能測試。宏觀性能測試主要是對檢測敏感代碼系統的耗時和準確性進行評估。微觀性能分析主要是對自動分析工具進行CPU利用率評估。

本文所采用的測試是在Ubuntu 12.04系統下完成，該系統中Linux內核版為3.11.0-26，GCC編譯器版本4.8.1，計算機硬件配置為CPU Pentium Dual-Core，內存2G，硬盤200G。

本文宏觀性能測試主要測試檢測敏感代碼系統的耗時及其準確性。檢測耗時主要方法是使用UNIXdate命令。在對Linux驅動源碼進行遍歷掃描的腳本中，增加驅動分析開始時間及結束時間，通過計算得出分析檢測驅動代碼所消耗的時間為4700s。對檢測到的敏感代碼的準確性我們主要是采用加權隨機抽樣的方式，通過對自動檢測敏感代碼的結果和手動抽樣檢查進行比較，其檢測到的敏感代碼的準確率較高。

微觀性能評估主要是對自動分析工具進行CPU利用率評估，檢測方法主要是利用Linux操作系統的ps命令獲取該分析工具的CPU利用率。在對內核驅動代碼進行自動分析的過程中，我們使用ps命令獲取其CPU利用率為2.2%，結果表明，該工具性能開銷較小，符合我們的設計要求。

5 結論

系統的可靠性由于設備及對應驅動的可靠性而受到限制，Linux系統出現的很多故障都是由于硬件瞬時故障導致的。為解決該問題，本文提出一種在驅動軟件中容忍硬件瞬時故障的機制，討論了面向硬件瞬時故障的驅動程序敏感代碼的自動分析方法，通過對Linux驅動源碼進行預處理、詞法分析、語法分析和靜態分析，查找出可能產生無限輪詢和靜態數組越界的敏感代碼并進行標注。為修復該類敏感代碼可能引起的驅動問題，我們通過插入時間檢查和范圍檢查，并引入了一個通用的恢復服務隱匿驅動程序對發生短暫性硬件故障的設備進行重置，驅動重新讀取寄存器中的硬件數據以達到修復的目的。同時，當發生短暫的硬件依賴性故障的時候，我們通過系統日志的方式通知管理員硬件發生問題，方便系統管理員對系統進行管理和維護。由于偶發性的硬件故障比較罕見的發生，為測試實驗結果，我們使用了故障注入工具來模擬我們期望的硬件故障，通過測試，經加固后的驅動程序能夠很好的容忍硬件瞬時故障，從而很好的實現了在軟件中容忍硬件故障的目的。