基于動態(tài)追蹤的自愈操作系統(tǒng)故障監(jiān)測技術(shù)

史佳龍，朱怡安，陸 偉，柴瑞亞

1.西北工業(yè)大學(xué) 計算機學(xué)院，西安 710072

2.西北工業(yè)大學(xué) 軟件與微電子學(xué)院，西安 710072

1 引言

隨著各類嵌入式系統(tǒng)應(yīng)用日益廣泛，對其可靠性和安全性的需求也隨之提高[1-2]。具備自愈能力的操作系統(tǒng)可在無需人工干預(yù)的情況下自動發(fā)現(xiàn)、診斷并修復(fù)故障，進而使得操作系統(tǒng)在遭遇系統(tǒng)失效時，還能夠繼續(xù)為用戶程序提供服務(wù)，可以有效減少當(dāng)前操作系統(tǒng)內(nèi)核在出現(xiàn)故障部分或全部服務(wù)失效時帶來的損失[3]，對提高系統(tǒng)可靠性有重要的意義。自愈操作系統(tǒng)中將系統(tǒng)的自愈過程抽象為監(jiān)測、診斷和恢復(fù)三個自主元素，作為自愈操作系統(tǒng)對故障的感知手段，故障監(jiān)測可以使操作系統(tǒng)具備自主發(fā)現(xiàn)故障的能力[4]，是自愈操作系統(tǒng)實現(xiàn)自主故障定位診斷及恢復(fù)的基礎(chǔ)，在自愈操作系統(tǒng)研究中具有重要的意義。當(dāng)前已有的操作系統(tǒng)故障監(jiān)測技術(shù)大都需要硬件支持或?qū)ο到y(tǒng)代碼進行修改，本文根據(jù)已有研究中對操作系統(tǒng)內(nèi)核故障分類和故障點分布的研究，針對內(nèi)核中動態(tài)內(nèi)存分配和資源競爭相關(guān)故障提出了一種基于動態(tài)追蹤的故障監(jiān)測技術(shù)，在Linux操作系統(tǒng)中該機制利用操作系統(tǒng)支持的斷點機制以可加載內(nèi)核模塊的形式實現(xiàn)，不需要對原系統(tǒng)進行擴展或修改，并通過故障注入實驗對提出的監(jiān)測技術(shù)的有效性從故障檢測率、誤報率、系統(tǒng)負載和監(jiān)測延時幾方面進行了驗證。

2 基于動態(tài)追蹤的故障監(jiān)測技術(shù)

操作系統(tǒng)故障監(jiān)測技術(shù)可分為基于異常事件、基于時間和基于系統(tǒng)性能指標(biāo)三類。基于異常事件的監(jiān)測技術(shù)主要通過感知系統(tǒng)中出現(xiàn)的異常事件來進行故障感知[5]，其能夠監(jiān)測的故障類型有限，且一般需要對原系統(tǒng)代碼進行修改；基于時間的監(jiān)測典型代表為定時器機制[6]，當(dāng)系統(tǒng)出現(xiàn)故障導(dǎo)致定時器未被周期性重置時，則認為操作系統(tǒng)或某個部件出現(xiàn)故障，無法精確診斷出現(xiàn)了何種故障以及定位故障點，有時需要在原有系統(tǒng)中增加必要的軟件模塊或特定硬件；基于系統(tǒng)指標(biāo)的監(jiān)測技術(shù)通過對整體操作系統(tǒng)性能指標(biāo)異常值的監(jiān)測實現(xiàn)對故障的監(jiān)測[7-8]，通過故障映射模型實現(xiàn)較為精確的故障診斷，但模型的建立大都需要訓(xùn)練過程以達到較好的監(jiān)測效果，可移植性無法得到保證。

已有研究中在設(shè)計故障監(jiān)測技術(shù)時，大都沒有對目標(biāo)系統(tǒng)的故障分類和分布進行分析，故其適用性無法得到保證，當(dāng)前已有的基于語義匹配的代碼靜態(tài)分析[9-10]和利用操作系統(tǒng)崩潰現(xiàn)場數(shù)據(jù)進行故障點分析[11]的研究結(jié)果表明，操作系統(tǒng)中的故障往往集中分布在特定內(nèi)核位置。針對在操作系統(tǒng)中內(nèi)核故障造成影響較應(yīng)用程序故障更為嚴(yán)重的問題，Deshpande等人[12]進一步將操作系統(tǒng)的故障歸結(jié)為以下四類：非法指針訪問、程序邏輯中預(yù)先設(shè)定的崩潰點、內(nèi)存泄露、同步機制的不恰當(dāng)使用導(dǎo)致的資源競爭。四類故障中，除去人為設(shè)定的內(nèi)核崩潰點，內(nèi)核中的故障點集中于內(nèi)存分配使用及回收、資源競爭同步等方面，且非法指針的訪問造成在很多情形下是由于內(nèi)存分配使用不當(dāng)、同步不當(dāng)導(dǎo)致的數(shù)據(jù)覆蓋造成的。在Linux中由于內(nèi)核程序共享執(zhí)行空間，單點的故障會傳播到整個內(nèi)核進而影響其他程序的執(zhí)行，甚至造成系統(tǒng)整體失效[13]。

針對Linux操作系統(tǒng)，基于以上內(nèi)核故障點的分析，本文將內(nèi)核中內(nèi)存分配和資源競爭操作相關(guān)的故障作為主要監(jiān)測目標(biāo)，而此類操作在內(nèi)核中往往表現(xiàn)為統(tǒng)一的方法調(diào)用（將其定義為內(nèi)核關(guān)鍵方法），因此故障的產(chǎn)生與關(guān)鍵方法的不恰當(dāng)使用存在直接的因果關(guān)系。通過動態(tài)追蹤內(nèi)核方法調(diào)用，可以對導(dǎo)致內(nèi)核全局?jǐn)?shù)據(jù)狀態(tài)遷移的方法調(diào)用進行記錄，依據(jù)設(shè)定的規(guī)則對記錄的調(diào)用序列和數(shù)據(jù)進行分析，可實現(xiàn)對故障的監(jiān)測和定位。圖1中為本文提出的基于動態(tài)追蹤的故障監(jiān)測架構(gòu)，內(nèi)核動態(tài)追蹤機制由三部分構(gòu)成，監(jiān)測斷點定義模塊設(shè)定需要監(jiān)測的關(guān)鍵方法；監(jiān)測數(shù)據(jù)采集模塊用于記錄系統(tǒng)調(diào)用的執(zhí)行序列，將每次方法調(diào)用的內(nèi)核上下文信息以及調(diào)用參數(shù)、返回值信息存儲到監(jiān)測信息鏈表中；故障診斷模塊依據(jù)追蹤信息和設(shè)計的規(guī)則進行故障診斷并輸出診斷結(jié)果。

圖1 內(nèi)核動態(tài)追蹤機制架構(gòu)

自旋鎖機制是操作系統(tǒng)中廣泛使用的一種資源同步機制，已有的研究成果中也將其列為主要故障點，根據(jù)內(nèi)核動態(tài)追蹤架構(gòu)，圖2中描述了操作系統(tǒng)中監(jiān)測自旋鎖相關(guān)故障的過程，通過在自旋鎖獲取內(nèi)核方法和自旋鎖釋放內(nèi)核方法調(diào)用前后設(shè)置監(jiān)測斷點，可以對內(nèi)核中獲取和釋放自旋鎖的操作信息進行記錄，并通過全局鏈表的方式進行保存，在進行內(nèi)核信息采集時，需要注意分析當(dāng)前方法調(diào)用導(dǎo)致的內(nèi)核狀態(tài)變化，確定斷點處理程序類型為應(yīng)當(dāng)在關(guān)鍵方法之前或者之后執(zhí)行，如當(dāng)使用__raw_spin_lock_bh獲取自旋鎖時會關(guān)閉系統(tǒng)軟中斷，此時若要監(jiān)測鎖釋放操作__raw_spin_unlock_bh則斷點處理程序應(yīng)當(dāng)在釋放鎖關(guān)鍵方法之后執(zhí)行，因為內(nèi)核在關(guān)中斷的狀態(tài)下操作監(jiān)測數(shù)據(jù)鏈表可能導(dǎo)致內(nèi)核卡死。在進程調(diào)用do_exit方法退出時，檢查監(jiān)測隊列中是否存在于當(dāng)前要退出進程相關(guān)的記錄，通過對記錄中的信息分析進行故障診斷。

圖2 內(nèi)核自旋鎖故障監(jiān)測實例

Hector[13]、Lockout[14]使用代碼靜態(tài)分析的方法也實現(xiàn)了對內(nèi)核故障點的追蹤，但實際系統(tǒng)在運行過程中時，由于內(nèi)核中中斷、搶占等機制的存在，靜態(tài)代碼分析的故障追蹤并不能完全發(fā)現(xiàn)系統(tǒng)中可能存在的故障，而本文中提出的監(jiān)測技術(shù)可以偵測到內(nèi)核中實際的調(diào)用序列和上下文信息，對故障實現(xiàn)更為有效的監(jiān)測。

3 故障監(jiān)測器實現(xiàn)

3.1 監(jiān)測器架構(gòu)

故障監(jiān)測器由監(jiān)測模塊和數(shù)據(jù)顯示兩個主要模塊構(gòu)成，其中監(jiān)測模塊以可加載內(nèi)核模塊的形式實現(xiàn)，可以根據(jù)需求動態(tài)地加載到內(nèi)核中運行，針對不同類型的故障可同時加載多個故障監(jiān)測器，而數(shù)據(jù)顯示模塊在用戶態(tài)實現(xiàn)，顯示界面使用wxPython程序庫設(shè)計實現(xiàn)，實現(xiàn)故障監(jiān)測結(jié)果的顯示，兩個模塊以系統(tǒng)日志為數(shù)據(jù)交互媒介。故障監(jiān)測模塊的實現(xiàn)包括監(jiān)測點、監(jiān)測數(shù)據(jù)鏈表和斷點處理程序三部分，其中監(jiān)測點可定義為Jprobe、Kretprobe和Kprobe三類，分別用于獲取內(nèi)核調(diào)用參數(shù)、返回值以及調(diào)用棧信息；監(jiān)測數(shù)據(jù)鏈表用于存儲監(jiān)測信息；斷點處理程序根據(jù)采集到的內(nèi)核信息對監(jiān)測數(shù)據(jù)鏈表進行維護，可令其在斷點發(fā)生之前或之后執(zhí)行，在程序退出時分析監(jiān)測數(shù)據(jù)鏈表數(shù)據(jù)，從而進行故障診斷。

3.2 資源競爭故障監(jiān)測

以自旋鎖相關(guān)故障為例說明對資源競爭類故障的監(jiān)測方法，主要是通過對鎖獲取函數(shù)、鎖釋放函數(shù)以及進程退出函數(shù)的監(jiān)測實現(xiàn)對故障的定位診斷，其中使用的監(jiān)測方法以及相應(yīng)的斷點處理程序功能描述如表1所示。

對于監(jiān)測到的每一次鎖操作，監(jiān)測程序動態(tài)分配一個結(jié)構(gòu)體來記錄鎖操作相關(guān)數(shù)據(jù)，監(jiān)測記錄結(jié)構(gòu)體中會記錄鎖指針、獲取鎖的進程以及鎖類型和當(dāng)前進程執(zhí)行上下文（flags），并維護一個監(jiān)測記錄鏈表來記錄操作系統(tǒng)中當(dāng)前鎖的申請釋放情況。在監(jiān)測到某一個進程的釋放鎖操作后，查詢監(jiān)測鏈表并將其中對應(yīng)的信息刪除，在監(jiān)測到某個進程的退出操作時（Linux中進程在退出時都會調(diào)用統(tǒng)一的接口do_exit），對監(jiān)測鏈表執(zhí)行相同查詢過程，若發(fā)現(xiàn)不存在該進程相關(guān)記錄，則說明該進程的鎖操作沒有出現(xiàn)獲取而沒有釋放的錯誤，否則說明當(dāng)前進程在退出時沒有完全釋放其占有的鎖，可能造成資源競爭導(dǎo)致系統(tǒng)故障，此時監(jiān)測程序會向系統(tǒng)日志中輸出相關(guān)的故障信息，供顯示模塊讀取。

3.3 動態(tài)內(nèi)存分配監(jiān)測

同對資源競爭類故障的監(jiān)測原理相同，對內(nèi)核動態(tài)內(nèi)存分配的監(jiān)測是通過對vmalloc和vfree以及do_exit方法的監(jiān)測實現(xiàn)的，具體說明見表2。

對于監(jiān)測到的每一次動態(tài)內(nèi)存分配操作，監(jiān)測程序動態(tài)分配一個結(jié)構(gòu)體來記錄內(nèi)存操作相關(guān)數(shù)據(jù)，對于每一個動態(tài)內(nèi)存分配操作，監(jiān)測記錄結(jié)構(gòu)體中會記錄分配的內(nèi)存指針、獲取內(nèi)存的進程并維護一個監(jiān)測記錄鏈表來記錄操作系統(tǒng)中當(dāng)前動態(tài)內(nèi)存的申請釋放情況。監(jiān)測鏈表的維護與自旋鎖監(jiān)測鏈表類似，若監(jiān)測到當(dāng)前進程在退出操作后存在未釋放的內(nèi)存時，說明當(dāng)前進程出現(xiàn)了內(nèi)存泄露故障，此時向系統(tǒng)日志輸出相應(yīng)的故障信息。

3.4 監(jiān)測結(jié)果顯示

關(guān)鍵方法監(jiān)測模塊以內(nèi)核模塊的形式根據(jù)監(jiān)測需求動態(tài)加載到操作系統(tǒng)中在內(nèi)核態(tài)運行，其監(jiān)測信息會輸出到系統(tǒng)日志文件中，用戶態(tài)的顯示程序會以固定的時間間隔讀取日志文件中的信息，進行解析并顯示在程序界面中，如圖3中所示，從界面顯示框中用戶可以獲取內(nèi)核中每個進程申請釋放鎖和內(nèi)存的信息，如288號進程獲取了地址為f4a881eb的自旋鎖，根據(jù)3.2節(jié)和3.3節(jié)中描述的監(jiān)測規(guī)則若監(jiān)測到當(dāng)前系統(tǒng)中出現(xiàn)故障，顯示模塊會從系統(tǒng)日志文件中讀取相應(yīng)信息并顯示。

表1 自旋鎖相關(guān)操作監(jiān)測方法列表

表2 內(nèi)核動態(tài)內(nèi)存分配相關(guān)操作監(jiān)測方法列表

圖3 監(jiān)測結(jié)果顯示界面

4 實驗結(jié)果及分析

本文中采用故障注入實驗的方法對故障監(jiān)測器的有效性從故障監(jiān)測率、誤報率、系統(tǒng)的負載以及故障監(jiān)測延時等方面進行分析驗證。實驗計算機配置為AMD速龍II雙核 P360（2.3 GHz雙核），2.0 GB內(nèi)存，500 GB硬盤，內(nèi)核版本為Linux 3.5。為了模擬系統(tǒng)真實的運行環(huán)境，在進行故障注入實驗時選取了Unixbench 5.1.2測評集模擬系統(tǒng)運行負載，選用了多個負載測試集以保證對內(nèi)核關(guān)鍵方法調(diào)用的覆蓋率。故障庫以內(nèi)核模塊的形式實現(xiàn)，在負載執(zhí)行流中以一定的時間間隔動態(tài)加載到內(nèi)核運行，并記錄監(jiān)測到的故障總數(shù)，通過系統(tǒng)在加載故障監(jiān)測器加載前后的Unixbench在各個負載集下的系統(tǒng)評分，可以對故障監(jiān)測器對系統(tǒng)造成的負載做出評估。

故障注入實驗的故障庫包含資源競爭（鎖的不恰當(dāng)使用如重復(fù)獲取同一個鎖、程序退出時不釋放占用的資源）和內(nèi)存泄露故障，分別選取context1、dhry、fstime、shell8、pipe、spawn、syscall、excel等標(biāo)準(zhǔn)測試集作為負載，在其正常執(zhí)行流內(nèi)分別注入上述兩種類型的故障各50次，記錄每個負載執(zhí)行流在完成時監(jiān)測到的故障總數(shù)，結(jié)果如圖4所示，從結(jié)果中可知，監(jiān)測器對79.25%的故障進行有效監(jiān)測，但在shell8和execl負載流的執(zhí)行上下文中不允許進行中斷操作，否則會導(dǎo)致內(nèi)核中數(shù)據(jù)不一致問題，甚至出現(xiàn)oops現(xiàn)象，而本文中設(shè)計的監(jiān)測技術(shù)則需要利用中斷產(chǎn)生斷點進行信息采集，因此監(jiān)測器在此時無法對內(nèi)存泄露類故障進行有效的監(jiān)測。在shell8和spawn負載中會產(chǎn)生大量并發(fā)進程并分配到兩個CPU核上并發(fā)執(zhí)行，由于每次創(chuàng)建進程退出進程操作都會執(zhí)行斷點處理程序，在短時間內(nèi)會觸發(fā)大量中斷，kprobe斷點機制在執(zhí)行斷點處理程序之前會產(chǎn)生int3和debug中斷，在本實驗中會導(dǎo)致系統(tǒng)死機，因此在spawn和shell8負載流下對資源競爭類錯誤的監(jiān)測效果較差。

圖4 故障注入實驗結(jié)果

在context1負載集下進行內(nèi)存泄露故障監(jiān)測時，監(jiān)測到的故障總數(shù)超過了50次，雖然可能是由于操作系統(tǒng)中存在內(nèi)存泄露故障造成的，但本文中將監(jiān)測到的非人為注入的故障視為誤報，實驗結(jié)果表明監(jiān)測器在監(jiān)測到的636次故障中僅存在兩次誤報。

監(jiān)測器對整體系統(tǒng)的負載主要是由于在內(nèi)核中產(chǎn)生中斷采集監(jiān)測信息以及對監(jiān)測隊列數(shù)據(jù)的維護造成的，Unixbench可以給出的在不同負載流下實驗計算機在加載故障監(jiān)測器前后的評分值，根據(jù)評分值可計算出監(jiān)測器加載后系統(tǒng)性能下降了0.59%，故障監(jiān)測器對系統(tǒng)造成的負載較小，具體評分值如圖5所示。

圖5 監(jiān)測器負載分析結(jié)果

基于系統(tǒng)性能指標(biāo)的故障監(jiān)測技術(shù)中數(shù)據(jù)采樣周期的設(shè)置會直接影響到故障監(jiān)測延時，對該類型故障監(jiān)測器進行故障監(jiān)測延時評估的時候往往通過設(shè)置不同的監(jiān)測周期來進行實驗，研究[15]中提出的基于貝葉斯模型的進程級故障監(jiān)測器在FDP和SWIMBOX兩類負載下的故障監(jiān)測延時分別為（100.26±136.76）ms和（100±33.33）ms；基于系統(tǒng)I/O吞吐量進行故障監(jiān)器[16]僅使用了I/O吞吐量這一個性能指標(biāo)，且沒有復(fù)雜的故障判別模型，對于不同類型的故障監(jiān)測延時差別較大，對于某些故障可能在很長的時間內(nèi)無法進行有效的監(jiān)測。

表3 基于時間的故障監(jiān)測技術(shù)監(jiān)測延時

基于時間的故障監(jiān)測技術(shù)大都需要增加額外的硬件或者軟件機制支持定時機制，帶來了與具體進程或者系統(tǒng)的通信開銷，根據(jù)在使用管道、Socket、無線網(wǎng)絡(luò)三種通信方法[8]時其延時監(jiān)測結(jié)果如表3中所示。

本文中提出的監(jiān)測機制以內(nèi)核模塊的形式實現(xiàn)，可以動態(tài)地加載到內(nèi)核中運行，采用中斷的方式進行數(shù)據(jù)記錄和分析，減少了與特定進程或者硬件進行通信的開銷，故障監(jiān)測延時實驗結(jié)果如圖6所示，從圖中數(shù)據(jù)可知，監(jiān)測的延時明顯小于基于時間和系統(tǒng)指標(biāo)的監(jiān)測技術(shù)。由于對故障數(shù)據(jù)的采集和監(jiān)測是通過中斷方式實現(xiàn)，監(jiān)測的延時不會受到監(jiān)測器具體配置的影響如性能指標(biāo)采樣周期等。

圖6 監(jiān)測器故障監(jiān)測延時實驗結(jié)果

此外從實驗結(jié)果中可以看出，對資源競爭類故障的監(jiān)測延時要明顯小于對內(nèi)存泄露類故障的監(jiān)測延時，這是由于資源競爭類故障往往和操作系統(tǒng)內(nèi)的臨界區(qū)相關(guān)，為了提高系統(tǒng)的整體運行效率臨界區(qū)執(zhí)行時間一般很短暫，且和多核中斷搶占上下文相關(guān)，因此可在臨界區(qū)執(zhí)行結(jié)束退出時較快地偵測到故障，而對于內(nèi)存泄露類的故障，由于其分配內(nèi)存往往存在延時且可能導(dǎo)致該進程睡眠，因此對于此類故障監(jiān)測的延時要長于資源競爭類故障。

5 結(jié)論

故障監(jiān)測技術(shù)為自愈操作系統(tǒng)提供對故障的自主感知能力，是故障診斷和恢復(fù)的基礎(chǔ)，根據(jù)已有的操作系統(tǒng)故障分布研究成果，本文提出了一種基于動態(tài)追蹤的故障監(jiān)測技術(shù)，通過三類監(jiān)測點的插入可以有效地監(jiān)測內(nèi)核中動態(tài)內(nèi)存分配和資源競爭相關(guān)的故障，并通過錯誤注入實驗驗證了該技術(shù)的可行性，實現(xiàn)的故障監(jiān)測器可以在較低系統(tǒng)負載的條件下對注入的故障進行有效的監(jiān)測，且故障誤報率很低，監(jiān)測延時較已有的基于時間和系統(tǒng)性能指標(biāo)的監(jiān)測技術(shù)明顯降低。

[1]Barbosa R.Layered fault tolerance for distributed embedded systems[M].[S.l.]：Chalmers University of Technology，2008.

[2]Schneider C，Barker A，Dobson S.A survey of self-healing systems frameworks[J].Software：Practice and Experience，2014.

[3]Hamann P S，Perry R L.Compensation recommendations，US patent 20，140，032，382[P].2014.

[4]Asghari S A，Kaynak O，Taheri H.An investigation into soft error detection efficiency at operating system level[J].The Scientific World Journal，2014.

[5]Abaffy J，Krajcovic T.Software support for multiple hardware watchdog timers in the linux OS[J].Applied Electronics，2010：17-19.

[6]David F M，Campbell R H.Building a self-healing operating system[C]//Third IEEE International Symposium on Dependable，Autonomic and Secure Computing，2007：3-10.

[7]Zhu Y，Li Y，Xue J，et al.What is system hang and how to handle it[C]//Software Reliability Engineering（ISSRE）.

[8]Abaffy J，Kraj?ovi? T.Multiple software watchdog timers in the linux OS[M]//Emerging Trends in Computing，Informatics，Systems Sciences，and Engineering.[S.l.]：Springer，2013：759-765.

[9]Palix N，Thomas G，Saha S，et al.Faults in Linux：ten years later[C]//ACM SIGARCH Computer Architecture News，ACM，2011：305-318.

[10]Chou A，Yang J，Chelf B，et al.An empirical study of operating systems errors[Z].ACM，2001.

[11]Lisong L，Peter P，Tschudin S，et al.Oops!What about a Million Kernel Oopses?RT-0436[R].2013.

[12]Deshpande B D.System and methods for self-healing from operating system faults in kernel/supervisory mode，US Patent 20，140，032，962[P].2014.

[13]Saha S，Lozi J P，Thomas G，et al.Hector：detecting resource-release omission faults in error-handling code for systems software[C]//43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks.IEEE，2013：1-12.

[14]Kheradmand A，Kasikci B，Candea G.Lockout：efficient testing for deadlock bugs[R].2014.

[15]Bovenzi A，Cinque M，Cotroneo D，et al.OS-level hang detection in complex software systems[J].International Journal of Critical Computer-Based Systems，2011，2：352-377.

[16]Cotroneo D，Natella R，Russo S.Assessment and improvement of hang detection in the Linux operating system[C]//Reliable Distributed Systems，2009：288-294.