計算機Linux 操作系統(tǒng)調用測試的自動化設計

李 菲

（沈陽市公用事業(yè)技工學校 遼寧 沈陽 110011）

0 引言

在計算機中，操作系統(tǒng)作為基礎組成部分，是保障計算機系統(tǒng)正常、穩(wěn)定運行的關鍵。 隨著計算機生態(tài)體系的不斷完善，各類操作系統(tǒng)嶄露頭角，Linux 操作系統(tǒng)憑借自身開源免費、軟件環(huán)境良好、服務器發(fā)展勢頭強等優(yōu)勢，在嵌入式系統(tǒng)和個人電腦等領域具有廣泛的應用［1］。 但與之相伴的是在操作系統(tǒng)的快速發(fā)展以及用戶需求的不斷增多下，Linux 操作系統(tǒng)內核的更新速度更快，內核復雜性也在持續(xù)提升，隨著內核接受代碼量的增加，Linux 內核遭受攻擊的范圍相繼提升，導致計算機系統(tǒng)面對的安全隱患加劇，此時就需要對操作系統(tǒng)進行自主可控測試。 而系統(tǒng)調用作為操作系統(tǒng)內核測試的關鍵切入點，在發(fā)展進程中規(guī)模越來越大，無論是數(shù)量、種類還是復雜程度均發(fā)生了較大的改變，致使操作系統(tǒng)調用測試工作的難度增大，且易出現(xiàn)遺漏情況。 由此，基于Linux 操作系統(tǒng)內核，設計一種面向系統(tǒng)調用測試的自動化程序框架，以此實現(xiàn)對系統(tǒng)調用的全面、高效測試，為國內操作系統(tǒng)開發(fā)工作的進一步發(fā)展提供支持。

1 Linux 操作系統(tǒng)調用機制

1.1 傳統(tǒng)系統(tǒng)調用機制

針對Linux 操作系統(tǒng)而言，傳統(tǒng)系統(tǒng)調用機制原理如下：借助軟中斷將用戶態(tài)的代碼請求轉移至內核態(tài)之中，當前執(zhí)行代碼段所處位置可用代碼段寄存器（code segment，CS）中最低兩位予以表述。 在某個系統(tǒng)調用執(zhí)行時，需將調用號、參數(shù)和程序的上下文環(huán)境存儲至寄存器之中，再進行軟中斷［2］。 之后由中央處理器從中斷描述符表中提取匹配門描述符，并對門描述符的結構化查詢語言（data processing language，DPL）和調用者的計算機程序庫（computer program library，CPL）進行檢查，當DPL 大于CPL 時，調用者才可以訪問此代碼段。 此時，int 指令會更改寄存器中的CPL 為0，從而進入Linux 系統(tǒng)內核。 門描述符是system_call（）函數(shù)，入口地址儲存在中斷描述符之中，在Linux 初始化時預先設置好此函數(shù)，當執(zhí)行軟中斷指令時，則會自動執(zhí)行system_call（）。 同時，system_call（）作為全部系統(tǒng)調用的公用入口，能夠根據(jù)調用號對相應的內核函數(shù)予以處理。 最后，執(zhí)行iret 指令即可切回用戶態(tài)。

1.2 快速系統(tǒng)調用機制

自Linux 內核2.6 之后，出現(xiàn)快速系統(tǒng)調用機制。 因為在執(zhí)行系統(tǒng)調用時調用者的CPL 必然是3，對應的門描述符DPL 也為3。 由此，采用SYSENTER／SYSCALL 指令將處在3 的用戶程序可以直接調用處在0 的內核程序，并利用SYSENTER／SYSRET 指令將處在0 的內核程序切回到用戶程序。 此過程中，因為無需進行CPL 和DPL 檢查，系統(tǒng)調用指令的執(zhí)行速度明顯增快。 以Intel 的快速系統(tǒng)調用指令為例，其實現(xiàn)主要涉及如下三個寄存器：

（1）SYSENTER_CS_MSR，負責存儲待執(zhí)行的內核態(tài)代碼段，還能得到內核堆棧段基址和用戶態(tài)代碼段與堆棧段基址；

（2）SYSENTER_EIP_MSR 負責存儲下一次將要執(zhí)行指令的偏移地址；

（3）SYSENTER_ESP_MSR：負責存儲內核態(tài)代碼堆棧的棧頂指針。

對于上述寄存器內容的寫入采用WRMSR 指令，而讀取則可采用RDMSR 指令。 當用戶程序調用SYSENTER指令時，即可在CS 寄存器中存儲內核態(tài)代碼段描述符，將值增加8 后于SS 寄存器中進行存儲，將待執(zhí)行的指令地址存入企業(yè)信息門戶寄存器，并將棧頂指針存入擴展棧指針寄存器，從而實現(xiàn)3 向0 的切換，對相應的內核程序予以執(zhí)行。

2 Linux 操作系統(tǒng)調用測試自動化程序設計與實現(xiàn)

2.1 系統(tǒng)調用分類

針對Linux5.6.14 內核版本而言，系統(tǒng)調用表是Linux內核的大數(shù)據(jù)結構，負責對所有系統(tǒng)調用內核函數(shù)指針進行記錄，借助此表即可明確哪個系統(tǒng)調用得到實現(xiàn)。 在x86 架構下，使用syscall_64. c 文件實現(xiàn)初始化系統(tǒng)調用表［3］。 通過對系統(tǒng)調用表的分析，能夠明確Linux5.6.14內核版本在x86 架構下實現(xiàn)的系統(tǒng)調用共有342 個，依照功能劃分，共分為以下6 類：

（1）文件操作：共具有127 個文件操作類系統(tǒng)調用，涉及文件的創(chuàng)建、讀寫、刪除、復制、重命名、屬性設置等功能。

（2）系統(tǒng)管理：共具有70 個系統(tǒng)管理類系統(tǒng)調用，涉及系統(tǒng)日期、時間的設置和獲取，系統(tǒng)數(shù)據(jù)的設置和查看等功能。

（3）進程控制：共具有53 個進程控制類系統(tǒng)調用，涉及進程創(chuàng)建、執(zhí)行、加載、終止以及進程屬性設置等功能。

（4）通信：共具有48 個通信類系統(tǒng)調用，涉及通信連接的創(chuàng)建、刪除，狀態(tài)信息傳遞，消息接發(fā)等功能。

（5）內存管理：共具有26 個內存管理類系統(tǒng)調用，涉及內存頁面的加解鎖、映射以及內存緩沖區(qū)數(shù)據(jù)寫回等功能。

（6）用戶管理：共具有18 個用戶管理類系統(tǒng)調用，涉及用戶組的設置、修改以及用戶權限等功能。

2.2 系統(tǒng)調用測試自動化程序設計及實現(xiàn)

現(xiàn)階段系統(tǒng)調用測試方法以黑盒測試為主，測試過程缺少對內核函數(shù)的分析，忽略了測試程序的內部實現(xiàn)，導致系統(tǒng)調用測試易出現(xiàn)用例冗余或覆蓋范圍不全的情況。因此，在上述分析的基礎上提出一種基于灰色測試的系統(tǒng)調用測試自動化程序。

2.2.1 用例設計和優(yōu)化

系統(tǒng)調用由用戶程序發(fā)起，以“文件打開”系統(tǒng)調用為例。 用戶程序共傳入4 個參數(shù)，在第3 個參數(shù)中文件打開標志位存有14 個選項，各選項還可以與其他標志項進行多種組合，倘若未進行內核源碼分析就對參數(shù)進行盲目性的組合，一方面可能出現(xiàn)只能對錯誤代碼進行調用的情況，導致核心功能代碼未執(zhí)行，從而造成用例冗余，增加系統(tǒng)調用測試難度，另一方面部分系統(tǒng)調用的內核函數(shù)完全相同，例如fstate 與state 等。 針對此類系統(tǒng)調用測試而言，可以選擇傳遞參數(shù)最全的系統(tǒng)調用進行測試，盡可能減少測試數(shù)量。

在系統(tǒng)調用測試程序的執(zhí)行過程中，具體的執(zhí)行路徑取決于if 條件判斷，由此在用例優(yōu)化過程中，可從if 條件判斷的優(yōu)化入手。 考慮部分if 條件判斷的標準為不可控因素，所以可以將此類if 條件判斷忽略，例如__d_lookup_rcu（）函數(shù)是對緩存中某個目錄項進行查找，并非用戶程序可控，故此可以忽略。 倘若if 條件判斷與用戶傳入參數(shù)相關，在測試過程中無論真假分支均需進行測試。

此外，通過對系統(tǒng)調用內核源碼的靜態(tài)分析，能夠發(fā)現(xiàn)內核函數(shù)在系統(tǒng)調用的實現(xiàn)過程中還與內核安全自主訪問控制機制的權限檢測有關。 在測試前，需要提前賦予用戶針對文件擁有的訪問控制列表（access control list，ACL）權限或進程具備的能力。 在此過程中，若只采用黑盒測試對系統(tǒng)調用功能的實現(xiàn)進行驗證，難免全面涉及所有與權限檢查相關的代碼，導致執(zhí)行測試的過程中內核代碼的覆蓋率較低［4］。

2.2.2 測試程序自動化設計和實現(xiàn)

基于上述對系統(tǒng)調用分類和內核函數(shù)的分析，對系統(tǒng)調用測試程序自動化的設計流程如圖1 所示。

圖1 系統(tǒng)調用測試自動化流程圖

在系統(tǒng)調用測試自動化流程中，測試環(huán)境配置、測試用例執(zhí)行、測試結果記錄與分析均實現(xiàn)自動化，顯著提升系統(tǒng)調用測試的效率。

在自動化設計過程中，將自動化測試程序的目錄進行四層結構設計，如圖2 所示。

圖2 系統(tǒng)調用測試自動化程序目錄結構

第一層目錄結構是系統(tǒng)調用的六大分類。

第二層目錄結構包括部分以系統(tǒng)調用名稱進行命名的子目錄，一個Makefile 文件以及auto. sh 腳本，Makefile文件可遞歸至第三層目錄結構中的Makefile 文件之中，從而實現(xiàn)對同一系統(tǒng)調用中全部測試程序的共同編譯。 而auto.sh 腳本則可以對已經完成編譯的測試程序進行執(zhí)行。

第三層目錄結構中Makefile 文件負責對某系統(tǒng)調用測試程序進行編譯，因為在一兩層目錄結構中也對Makefile 文件及對應的腳本進行設計，所以測試程序自動化粒度既要求能夠對同類系統(tǒng)調用進行統(tǒng)一測試，也能夠針對單獨的一個系統(tǒng)調用進行測試。 result 中存儲的是測試分析結果，采用系統(tǒng)調用名稱+測試時間的方式對存儲文件進行命名。 TEST 中存儲的是執(zhí)行測試時創(chuàng)建的目錄與文件。 inelud 存儲的是測試程序中具有的頭文件，其中包括存放測試用例和結果的結構體。 通過對測試用例數(shù)量TOTALLINE 宏的初始化，當出現(xiàn)用例數(shù)量變化時，僅需對宏進行修改或調整即可。 main. c 則是主要測試程序，通過對可執(zhí)行文件的運行實現(xiàn)對系統(tǒng)調用的測試，負責初始化數(shù)據(jù)結構體和全局變量、逐條獲取測試用例參數(shù)、執(zhí)行系統(tǒng)調用測試、記錄結果、編寫日志等工作［5］。 setup.sh腳本負責測試前的環(huán)境配置和檢查工作，例如權限檢查，用戶及用戶組創(chuàng)建并賦予相應權限等。 testcases 存儲的是為單個系統(tǒng)調用設計的測試用例，測試程序可將從此文件中提取出的用例存入test_cases 結構體中。

當完成系統(tǒng)調用測試之后，即可對設置的測試環(huán)境進行清除，考慮不同系統(tǒng)調用測試需要的測試環(huán)境也有所差異，所以應依照具體測試情況對測試環(huán)境清除程序進行設計。 大體上，測試環(huán)境清除的類別劃分如下：

（1）對測試前預先創(chuàng)建的目錄或文件進行清除；

（2）對測試前預先創(chuàng)建的用戶及用戶組以及賦予的權限進行清除；

（3）對測試過程中創(chuàng)建的目錄和文件進行清除；

（4）對執(zhí)行測試時打開的文件予以關閉。

3 面向SylixOS 的測試實施和結果分析

SylixOS 是一款類Linux 的國產計算機操作系統(tǒng)，將上述設計的測試用例移植到SylixOS 上，既是對系統(tǒng)調用測試程序自動化設計成果的檢驗，也是對Linux 系統(tǒng)調用測試用例在國產操作系統(tǒng)中的適用性展開探究。

3.1 測試用例執(zhí)行

在面向SylixOS 的測試過程中，需采用RealEvo-IDE工具對測試環(huán)境進行部署，并新建Base 工程。 實驗采用兆芯，編譯工具鏈為x86-sylixos-toolchain，編譯代碼級別是Debug。 當完成Base 工程創(chuàng)建后，編譯SylixOS 內核，完成編譯后即可將其上傳至目標板上并啟動。 之后對測試工程進行建設，須注意在Base 工程中對創(chuàng)建好的x86 Base文件夾進行選擇，并對測試工程予以編譯，編譯完成的工程上傳至SylixOS 系統(tǒng)目標文件之中。 最后將編譯好的測試程序在目標板上進行執(zhí)行。

3.2 測試結果分析

系統(tǒng)調用測試實驗結果顯示，在75 個測試用例中存在8 個用例的執(zhí)行結果和預期不符，如表1 所示，其余測試結果均與預期結果和Linux 測試結果保持一致。

表1 測試結果對照表

以其中問題級別為“嚴重”的15、22、23、25 為例，主要測試的是O_TRUNC 標志同寫權限之間的關系。 O_TRUNC 是當文件存在清空文件內容，在打開時需賦予用戶相應的寫權限，文件自身也需要提供權限。 但在SylixOS 測試中并未檢查對寫權限的賦予，與操作系統(tǒng)的安全性問題有關，所以標注問題級別為“嚴重”。

同時，將本文提出的系統(tǒng)調用測試程序與Linux 測試計劃（Linux test project，LTP）程序進行對比，發(fā)現(xiàn)本文提出的系統(tǒng)調用測試自動化程序更為靈活，既可支持單一或全部系統(tǒng)調用的檢測，也支持某一類的系統(tǒng)調用檢測。 同時，由于本文提出的測試自動化程序建立在灰盒測試方法基礎上，在測試用例設計上基于系統(tǒng)調用內核源碼分析，且盡可能全面覆蓋代碼執(zhí)行路徑，在用例設計方面具有更強的完備性，冗余情況得到有效減少。 以openat 系統(tǒng)調用為例，LTP 測試僅對其基本功能進行了驗證，測試用例僅在3 個測試程序中有所分布；而本文提出的測試自動化程序，針對openat 系統(tǒng)調用共設計了75 個用例，除基本功能測試外還包含面向ACL 機制的權限測試、內核機制的權限測試等，在測試用例的完備性方面明顯更強，可選性更為靈活。

4 結語

綜上所述，本文基于對Linux 操作系統(tǒng)調用測試機制的介紹以及系統(tǒng)調用類型劃分，對Linux 操作系統(tǒng)調用測試自動化程序展開設計，總結規(guī)律優(yōu)化系統(tǒng)調用測試用例。 并將測試用例移植到SylixOS 操作系統(tǒng)之中進行檢驗，分析測試結果，在驗證系統(tǒng)調用程序自動化設計有效的同時，對更適合國產計算機操作系統(tǒng)的自動化系統(tǒng)調用測試方法進行探究。