Linux設備驅動程序自動更新及輔助工具①

任艷艷, 翟高壽, 張俊紅

1(北京交通大學 計算機與信息技術學院, 北京 100044)2(北京建筑大學 電氣與信息工程學院, 北京 100044)

設備驅動程序通常會占到70%以上份額的操作系統內核源碼, 且設備驅動程序的更新維護往往會牽涉到超過35%的源碼修改, 故而保持設備驅動程序與操作系統內核不斷變化的其余部分的一致性是目前操作系統內核開發的一項難題[1]. 伴隨Linux內核版本更新升級速度的提升, 其內核穩定版本的發布周期已縮短至不到30天. 對于比較依賴內核接口的驅動程序來說, 由內核更新變化而引發的設備驅動的更新操作亦即設備驅動的協同演化將會更加頻繁, 所以實現設備驅動程序的自動更新就顯得尤為迫切. 換句話說, 若是設備驅動程序能夠最大化地實現自動更新, 就可在更大程度上減少協同演化所耗費的時間, 進而提高設備驅動程序更新效率. 作為占據內核源碼較大比重且是操作系統內核漏洞主要來源的驅動代碼, 設備驅動程序自動更新還可以提高驅動代碼的正確性, 從而進一步提高操作系統的安全性和健壯性.

現在尚未有工具可以完整實現設備驅動程序的自動更新, 不過已有相關的差異分析工具和差異應用工具. 常見的差異分析工具有 Unix diff, 還有 Python dfflib等, 都是基于文本的差異比較工具, 也有以函數為粒度的內核差異比較工具DIFFE[2], 還有基于語法樹的內核差異分析工具[3,4], 雖然都可以進行驅動代碼差異比較, 但也僅僅是差異比較, 而且是基于已知兩版驅動代碼的比較. 差異應用工具如 Coccinelle[5–9], 此項目最初被設計于解決Linux 內核與驅動協同演化問題,設計理念是內核開發人員編寫區別于傳統補丁的語義補丁, 說明兩個版本的變動信息, 然后由驅動開發人員使用Coccinelle應用此補丁, 完成內核驅動移植工作,但這沒有被Linux內核接受, 如今Coccinelle轉而專注于在內核中發現并修復漏洞.

為了改變設備驅動程序更新操作現狀, 本文研究了Linux設備驅動程序自動更新方法, 設計并實現了一組相應的自動更新支撐工具, 包括設備驅動程序對內核依賴接口分析工具、依賴接口差異性分析工具以及設備驅動更新輔助信息生成工具, 這組工具統稱為設備驅動自動更新輔助工具(Device Driver Assistant Updater, DDAU), 以便輔助用戶解決隨著內核更新帶來的驅動更新問題, 源代碼可在GitHub上獲取.DDAU實現設備驅動的更新過程, 是通過A、B兩版Linux 內核源碼, A 版更新后是 B 版. 其中, A 版是完整版內核源碼, B版在全文中沒有特別說明的情況下默認都不含有設備驅動代碼. 設備驅動更新就是, 根據A版內核設備驅動接口依賴分析和設備驅動依賴接口在A、B兩版本之間的差異分析, 得到A版內核設備驅動依賴接口差異信息, 然后根據此差異信息就可以得到設備驅動程序必須要做出哪些改動才能和內核變化保持一致, 這些必須要改動的信息或者可能需要改動的信息就是DDAU生成的設備驅動更新輔助信息.設備驅動依賴接口分析就是分析設備驅動程序對內核接口的依賴關系, 提取設備驅動依賴的內核接口, 包括內核數據、內核函數、宏以及驅動對它們的調用關系.Linux設備驅動更新問題模型如圖1所示.

圖1 Linux 設備驅動更新問題模型

1 Linux 設備驅動與驅動更新

1.1 Linux設備驅動程序

Linux設備驅動程序在操作系統中扮演著特殊的角色, 其完全隱藏了設備工作的細節, 只為操作系統提供定義好的內部編程接口, 操作系統通過這些接口調用驅動以達到操作實際硬件的目的. 因此設備驅動程序是操作系統和硬件的溝通橋梁, 它位于操作系統和硬件之間, 是直接和硬件打交道的軟件程序, 設備驅動與操作系統內核關系如圖2所示. 設備驅動依賴于操作系統內核接口, 因而隨著Linux內核升級帶來的內核接口變化, 設備驅動也必須協同更新, 以便設備驅動能和操作系統內核保持一致性, 才能和內核進行正確的信息交互.

圖2 設備驅動與操作系統內核關系示意圖

在Linux內核中, 設備驅動程序一般以內核可加載模塊(LKM)的方式存在, 可以在內核編譯的時候靜態加載, 因此單個設備驅動的更新只需要更改相對應的驅動目錄里的相關文件. 內核和設備驅動的信息交互通過宏和函數, 數據的傳遞一般是通過結構體等數據類型, 因此在分析接口依賴關系的時候, 著重在函數、宏, 以及數據類型如結構體等接口分析上, 設備驅動接口分析是圖2中操作系統內核部分的設備驅動內核依賴接口部分的分析.

1.2 Linux設備驅動更新

對于應用程序來說, 它因實現某個功能需要而調用系統提供的函數時, 它并不關心這個函數內部的實現細節, 只需要知道要調用的函數名字, 要傳入的參數以及返回值類型. 同樣地, 對于驅動來說, 驅動更新需要了解內核接口的名字、參數以及返回值的類型發生了哪些改變. 接口改變主要包括函數、宏, 以及數據類型的變化[10].

內核函數變化類型主要有: (1)函數被刪除或添加;(2)函數添加或刪除參數, 即函數的參數個數發生變化;(3)函數參數類型改變; (4)函數返回類型變化, 如添加錯誤處理機制由void變為返回錯誤碼.

內核中宏的類型主要包括有參宏和無參宏. 無參宏的變化類型有: (1)宏被刪除或添加; (2)宏的值改變,即宏名沒有變化但是宏的值發生了變化, 它的調用方式不變, 但可能會影響使用宏值的變量或其它數據類型的結果. 對于有參宏來說, 變化類型同函數類似, 有參宏可以說是某種意義上的另一種形式的函數.

數據類型主要包括結構體, 聯合體和枚舉, 結構體和聯合體的變化主要有: (1)刪除或者重新命名結構體成員或結構體; (2)更改結構體成員類型; (3)更改結構體成員順序; (4)增加或刪除結構體別名. 枚舉類型的變化一般就是枚舉成員的增減或者整個枚舉結構被刪除或添加.

接口變化還包括接口類型的改變. 例如接口在A版內核中聲明為函數, 在B版內核中可能會更改為宏, 或者反之. 接口類型的改變對于設備驅動來說, 有的影響不大, 有的卻必須跟隨內核接口的變化提供相應的改變. 本文根據對設備驅動更新操作產生的影響將差異分析結果進行等級劃分, 再根據等級劃分對用戶做出不同的輔助更新提示信息的輸出. 設備驅動的自動更新就是將引言中圖1所示的研究過程, 最大化地實現自動化, 研發出一個插件或者獨立的小工具嵌入到編輯器或者大型集成開發工具中幫助內核開發人員或者驅動維護人員更新相關程序的源代碼.

2 設備驅動自動更新方法設計

設備驅動自動更新的方法設計主體是考慮從驅動源代碼調用的內核接口入手, 有針對性的分析驅動源代碼接口依賴, 根據其調用的依賴接口差異分析, 提示用戶做出什么樣的協同演化操作.

設備驅動自動更新的方法設計具體是: 首先加載編譯器插件編譯內核導出特定格式的編譯中間結果,分析編譯中間結果提取待處理設備驅動程序源碼的接口依賴關系; 然后分析驅動源碼提取待處理驅動程序所依賴的頭文件, 根據頭文件列表提取兩版本內核接口原型聲明信息, 進而根據提取的接口原型聲明信息獲取兩版本內核中的接口差異信息, 并將差異信息篩選分類; 在此基礎上, 根據提取的接口依賴關系獲取設備驅動程序依賴接口差異信息及分類規則得出驅動更新的輔助信息, 最終向用戶展示結果.

圖3為設備驅動更新模型模塊設計, 主要包括預處理模塊, 設備驅動接口依賴關系提取模塊, 設備驅動頭文件依賴列表提取模塊, 驅動依賴接口原型聲明信息提取模塊, 驅動依賴接口差異分析和驅動更新輔助信息生成模塊. 設備驅動更新模型每個模塊既可以單獨運行也可以作為集成工具一起按規則自動執行, 自動執行腳本可以將各個模塊集成為一組工具集.

圖3 設備驅動更新模型

預處理模塊. 此模塊主要是編譯A版Linux內核源碼獲取編譯中間結果. GCC編譯器自4.5.0版本后開始支持插件技術[11], 為用戶提供了豐富的API接口, 方便用戶獲取GCC編譯中間結果, 因此可通過GCC Plugin技術獲取編譯過程中的抽象語法樹然后導出特定格式的文件, 以便提取設備驅動程序接口依賴關系.

驅動接口依賴關系提取模塊. 根據C語言的語法規則, 接口應該包括函數、宏、結構體、枚舉結構等主要方面. 此模塊就是分析預處理模塊得到的編譯中間結果即序列化的抽象語法樹文件, 提取A版內核中設備驅動的內核接口依賴關系, 生成包括設備驅動的自身接口聲明和去掉自身接口調用關系的外部接口調用關系文件, 調用關系包括驅動所調用的函數, 引用的宏, 使用的數據類型, 還有這些接口的調用位置和主調函數.

驅動頭文件依賴提取模塊. 提取A版內核中待處理驅動程序源碼所直接引用的頭文件, 然后根據此頭文件信息進一步提取A、B兩版本內核中頭文件中引用的頭文件, 稱之為二級頭文件即間接引用的頭文件,然后由二級頭文件以同樣的方法再提取三級頭文件,生成設備驅動對兩個內核版本的頭文件依賴列表, 這個頭文件依賴列表基本包含了驅動程序依賴接口所涉及的頭文件. 而為了新增功能或者代碼重構而添加頭文件導致一級頭文件列表的變化情況, 由于添加的頭文件對此時的用戶來說是透明的, 所以這種情況不予考慮.

接口原型聲明信息提取模塊. 此模塊是獲取驅動頭文件依賴提取模塊生成的兩個內核版本的頭文件依賴列表中所有頭文件的內容, 包括宏、函數以及extern原型的聲明, 結構體、枚舉等數據類型的聲明,聲明信息包括接口名稱、接口類型, 所在文件, 起始行號, 原型聲明語句. 此模塊生成兩個版本內核頭文件中的接口原型聲明文件.

接口差異分析和驅動更新輔助信息生成模塊. 此模塊是分析這些依賴關系在兩版內核中的差異信息,例如函數調用, 這些差異信息就包括函數名稱、返回值的改變, 參數列表的改變, 如參數個數或者參數類型發生變化等. 再如宏常量的使用, 大多數宏常量名稱沒有變化, 但是其值卻發生了變化, 雖然值發生了變化但由于調用宏時用的是名字, 所以宏常量的值變化不影響編譯卻可能會影響后續的使用結果. 因此, 所有這些差異信息都要提取出來, 并加以分析處理, 然后根據對驅動更新操作的影響進行等級劃分, 最后把差異信息的分級處理結果轉化為驅動更新的輔助信息.

3 原型設計與實現

根據設備驅動自動更新方法設計, 設計并實現設備驅動更新輔助工具DDAU, 開發平臺是虛擬機32位操作系統 Ubuntu 14.04 LTS, GCC 編譯器版本 4.8.4,Linux內核版本3.5.6和3.8.13.

設備驅動更新輔助工具DDAU操作主要步驟包括: (1)預處理, 加載GCC插件編譯A版Linux內核源碼得到編譯中間結果--序列化的抽象語法樹; (2)分析編譯中間結果提取待處理設備驅動程序源碼的接口依賴關系; (3)分析源碼提取待處理設備驅動程序所依賴的頭文件列表, 包含兩個內核版本頭文件依賴列表;(4)根據頭文件列表提取兩版本內核頭文件的接口的原型聲明信息; (5)根據提取的接口依賴關系和接口的原型聲明信息獲取接口差異信息, 再由差異信息得出驅動更新的輔助信息, 然后向用戶展示結果等5個主要步驟. 各步驟之間以及生成的文件的關系如圖4所示.

圖4 DDAU各步驟和生成文件之間的關系圖

預處理步驟主要是編譯內核執行make時設置參數 EXTRA_CFLAGS=“-fplugin=plugin_name”加載GCC插件導出序列化的抽象語法樹文件, 頭文件依賴分析步驟是得到驅動兩版內核頭文件依賴列表, 現在著重介紹驅動接口依賴分析、接口原型聲明提取、依賴接口差異分析和驅動更新輔助信息生成的設計與實現.

3.1 驅動接口依賴關系初步提取

預處理階段導出的序列化抽象語法樹文件, 是以函數為單位構成, 樹的根節點是函數聲明節點func_decl, 它的子樹有返回值子樹result_decl, 參數子樹parm_decl, 以及它的函數體子樹 bind_expr, 根據不同子樹節點不同含義可以提取驅動自定義函數聲明信息和函數、宏調用關系信息以及數據結構的使用信息等.

以函數聲明節點為入口和界限, 提取驅動自身定義的接口, 提取函數體子樹bind_expr中驅動調用的函數、宏, 以及結構體等, 對于函數、宏的調用需要記錄下所有主調函數和調用位置. 函數調用信息還需要剔除設備驅動程序調用自身定義函數的調用信息. 最后將這些函數定義以及函數、宏等的調用關系即驅動接口依賴關系分別保存成文本文件供后續處理.

3.2 接口原型聲明提取

根據頭文件列表獲取模塊, 可以分析這些頭文件的內容, 得到設備驅動程序依賴的頭文件中聲明的函數、宏、結構體等的原型聲明原句, 以便在接口差異信息獲取和驅動更新輔助信息生成模塊比較差異和根據差異生成驅動更新輔助信息.

本文使用Exuberant-Ctags[12](以下統稱為Ctags)作為信息獲取的輔助工具. 首先修正Ctags的輸出. 由于Ctags的主要目的是用于生成索引, 它并不關心接口是如何聲明的, Ctags生成各種索引的時候, 雖然列出了索引的文件名和行號, 但是在取原型聲明語句的時候只是取了對應行號的那一行, 因此它的輸出結果并不能滿足實驗需求, 需要對Ctags的輸出結果中接口聲明部分進行修改, 將函數、宏的原型聲明提取完整, 對于數據類型和數據結構, 輸出的結果中數據的名字和數據成員是拆分開的, 需要重新合并組合成一個完整的數據類型或數據結構的聲明, 以滿足實驗中對接口原型聲明信息的提取和后續的差異分析.

3.3 接口差異分析和驅動更新輔助信息生成

接口差異類型如圖5所示.

圖5 接口差異類型分類

用v0表示原版內核接口信息, v1表示新版內核接口信息, 接口信息存儲在Python語言的字典dict中,用k表示接口名稱, file表示接口所在文件, type表示接口類型即接口是函數還是宏或者是結構體等等,state表示接口原型聲明語句, diff_type表示差類型,#號表示注釋語句, 差異分析算法關鍵代碼如下:

上述操作后剩下的v1_dict中的接口就是Add增加類型的接口.

根據在接口依賴關系分析模塊得到的接口調用關系信息, 可以從接口差異信息中提取設備驅動所調用的接口是否發生了變化, 以及發生了哪些變化. 利用差異篩選算法把這些差異信息又根據對設備驅動程序更新的影響程度分為表1所示4個等級.

表1 差異信息影響等級劃分

輔助更新信息只輸出A、B、C三個等級.

4 原型測試與結果分析

4.1 測試方法

首先進行模塊化黑盒測試, 分析各個模塊得出的結果是否正確, 確認各個模塊之間銜接正確, 再對輔助工具進行整體測試, 查看最后得出的更新輔助信息, 然后根據輔助信息介入人工操作對驅動進行更新, 最后將更新的驅動復制到B版內核(假設此操作之前B版內核還沒有更新對應驅動)的對應位置, 對B版內核進行編譯, 測試是否編譯通過, 編譯通過后加載運行測試驅動模塊進一步驗證.

選擇測試驅動時, 為了盡可能測試多種驅動類型,選擇Linux內核源碼中drivers目錄下不同的驅動目錄進行實驗測試驗證, 修改配置文件中內核源代碼所在路徑, 然后運行批處理自動執行腳本文件batch_run.sh,也可以運行單處理腳本run.sh分析單個測試文件.

4.2 測試結果

對Linux內核源碼中drivers目錄下不同驅動目錄進行實驗測試驗證, 統計分析結果時不是單純統計代碼行數, 而是統計設備驅動依賴的內核接口變化而應當采取的設備驅動更新操作, 設備驅動更新操作修改的可能是一行代碼, 也可能是相關聯的多行代碼, 不考慮源代碼內部優化問題.

為量化實驗結果, 本文提出漏報率和誤報率概念.漏報率 (Rate of Missing Report, RMR)是指驅動程序根據設備驅動依賴接口變化應當給出但未給出修正提示的次數(MR)占據根據設備驅動依賴接口變化應當給出修正提示的總次數(TAR) 的比例. 誤報率(Rate of False Report, RFR)是指驅動程序根據設備驅動依賴接口變化所給出的錯誤修正提示次數(FR)占據根據設備驅動依賴接口變化給出修正提示的總次數(TR)的比例. 單個設備驅動文件的漏報率(RMRi)的計算公式是 RMRi= MRi/TARi. 平均漏報率的計算公式是 RMR= ∑RMRi/N,N為文件總數, 平均漏報率的數值越低越好. 單個設備驅動文件的誤報率(RFRi)的計算公式是RFRi= FRi/TRi. 平均誤報率的計算公式是 RFR =∑RFRi/N,N為文件總數, 平均誤報率的數值越低越好.實驗結果統計如表2所示.

表2 drivers/目錄測試文件的測試結果統計表

對于漏報原因分析: (1)接口在A版內核中定義在驅動內部, 而B版內核中把定義移到了頭文件中, 并可能更改接口名, 例如pci-acpi.c驅動中接口add_pm_notifier(參數)為自定義接口, 在B版內核則把此接口移動到了acpi/acpi_bus.h頭文件里并改名為acpi_add_pm_notifier(參數), 而驅動程序中的調用則同步替換.(2)內核頭文件中既保留原有接口函數、又新增同功能接口函數、并調用新增同功能接口函數的情況. 這兩種漏報情況, 前者需要進一步優化接口差異分析算法, 后者無法避免.

對于誤報原因分析: (1)函數參數只名字改變, 函數原型差異分析考慮了參數名, 造成誤報. (2)函數返回值發生變化, 但調用時沒有使用函數返回值, 因而函數返回值改變并沒有對程序造成影響, 無需給出更新提示, 造成誤報. (3)可變參數宏變化成了固定參數宏,但由于調用時參數個數依然可以接受, 所以無需修正,卻給出修正提示, 造成誤報. (4) 宏變化成函數, 返回值、參數由無類型變更為具體類型, 例如兩版本接口聲明語句: “-- #define con_debug_enter(vc) 函數體 ++static inline int con_debug_enter(struct vc_data *vc)”, 此情況給出更新提示誤報可以諒解. (5)對于函數參數中某個參數類型和名稱均發生變化, 例如內核接口async_synchronize_full_domain , 參數列表由 (struct list_head*list)變為 (struct async_domain *domain), 但驅動程序源碼中此接口調用語句參數部分卻都是 (&scsi_sd_probe_domain), 調用不受影響, 無需給出更新提示, 此情況的誤報可以諒解.

對于誤報原因各種情況分析得出, 實際平均誤報率要比計算得出的誤報率小的多, 因而DDAU可以為驅動更新提供有效的輔助更新提示.

輔助更新提示信息中的A級差異信息生成的輔助信息如圖6所示, 依次是接口差異信息的級別A級, 接口的差異類型 Del, 接口類型, 接口所在文件, 接口的原型聲明信息, 這些信息方便用戶了解接口的調用方式,接下來是驅動文件調用此接口的位置, 直接定位源代碼方便用戶修改. 圖7中所示是接口的差異類型All,輔助信息會把接口變化前后的文件和原型聲明列出來,方便用戶查看以便根據需要修改代碼.

根據輔助信息的提示, 對A版驅動進行人工輔助更新操作, 根據輔助信息提供的接口變化類型和接口原型信息進行修改, 將修改好的驅動放到B版內核對應位置后編譯內核, 經驗證可以編譯通過, 證明論文的設備驅動輔助更新方法設計是可行的.

圖6 設備驅動更新A級輔助信息部分結果示例

圖7 設備驅動更新B級輔助信息部分結果示例

4.3 結果分析

文獻[3,4]利用GCC插件導出已知兩版內核設備驅動源碼的抽象語法樹文件, 提取接口名字和在抽象語法樹文件中的起止行號, 傳入修改了前后端的Gumtree[13]進行差異分析, 分析驅動內部代碼實現的細節差異. 但由于其是基于已知兩版驅動代碼比較, 且旨在比較接口實現內部細節, 因而并不能實現驅動的更新操作. 與之相比, DDAU是利用GCC插件分析待更新的驅動代碼提取待更新設備驅動接口依賴, 同時依據引用的頭文件分析依賴接口差異, 并最終得出輔助更新提示, 在此基礎上, 就可以根據提示對原有設備驅動源碼進行修正而得到新版驅動源碼.

直接編譯方法[14]是在新版內核中編譯驅動源碼,修改錯誤, 重新編譯, 不斷重復此過程直到驅動編譯不再出錯, 但改錯的方法是人工分析提取的錯誤日志, 這需要人工查找接口在兩版內核中的接口原型聲明信息,對比接口原型聲明差異分析調用如何更改驅動源碼,與直接編譯方法不同, DDAU為用戶提示的驅動更新輔助信息, 直接提供了接口的變化類型, 接口所在文件和兩版接口原型聲明對比, 以及驅動代碼調用此接口的位置, 直觀的為用戶展示出接口聲明的不同和代碼需要修改的位置, 為驅動開發和維護人員省去大量繁瑣的人工查找和定位修改代碼的時間, 大大減少了驅動更新操作所耗費的時間.

5 結論與展望

本文實現了一個Linux設備驅動程序自動更新輔助工具DDAU, 以便用戶解決隨著內核更新帶來的驅動協同演化問題. 該工具可以為內核驅動的開發和維護提供有效的輔助更新信息, 為驅動在內核空間和用戶空間的拆分自動化問題[15]提供借鑒意見, 同時也為操作系統軟件更新問題提供技術思路. 但此工具也存在一些不足之處: (1)由于使用GCC插件所以對于驅動內核中的條件編譯語句#ifdef—#endif括起來的非本機器體系架構的代碼無法處理; (2)對于接口發生變化,但依據調用情況的不同需要做出不同提示的情況不夠靈活進行處理, 需要進一步的完善; (3)接口差異分析算法對處理接口名稱改變但功能不變的特殊情況需要進一步細化完善; (4)對于驅動接口依賴分析中的數據類型或數據結構依賴關系的提取不夠全面; (5)更新輔助信息提示不能圖形化動態展示在源碼需要更新的位置, 沒有將此輔助工具嵌入vi等編輯器或者集成開發環境中進而高效率更新代碼. 這些不足之處需要進一步的研究和探索, 會不斷的修正和完善.