楊世德　梁光明　余凱

摘 要： 隨著針對(duì)嵌入式系統(tǒng)的攻擊事件不斷發(fā)生，安全指標(biāo)在嵌入式系統(tǒng)設(shè)計(jì)過(guò)程中得到了越來(lái)越廣泛的關(guān)注。傳統(tǒng)的嵌入式系統(tǒng)安全分析主要針對(duì)嵌入式操作系統(tǒng)和應(yīng)用軟件，很少關(guān)注底層硬件安全。通過(guò)分析嵌入式系統(tǒng)底層運(yùn)行機(jī)制，建立和提出一種基于ARM嵌入式系統(tǒng)底層硬件漏洞挖掘模型和方法。

關(guān)鍵詞： Linux； 內(nèi)核模塊； 寄存器； 挖掘技術(shù)

中圖分類(lèi)號(hào)： TN710?34 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2015）18?0057?03

Abstract： As the attacks on the embedded systems occurs continually， more attention is paid to the safety index in the process of the embedded system design. The traditional security analysis on the embedded systems focused on embedded operating system and application software， but the security of the underlying hardware was ignored. By analyzing the underlying operating mechanism of embedded systems， the discovery model and method against hardware vulnerability of ARM?based embedded systems are proposed in this paper.

Keywords： Linux ； kernel module； register； discovery technology

嵌入式系統(tǒng)是以應(yīng)用需求為目的，軟硬件資源結(jié)合為手段，通過(guò)裁剪軟硬件資源滿(mǎn)足用戶(hù)對(duì)功能、可靠性、成本、體積、功耗等性能指標(biāo)要求的專(zhuān)用計(jì)算機(jī)系統(tǒng)[1]。在嵌入式系統(tǒng)發(fā)展初期，嵌入式系統(tǒng)通常都是作為完成單一任務(wù)的處理器被獨(dú)立使用，很少通過(guò)網(wǎng)絡(luò)與外界相連。由于嵌入式系統(tǒng)用戶(hù)的單一性和網(wǎng)絡(luò)的封閉性，不存在通過(guò)網(wǎng)絡(luò)的攻擊，所以在嵌入式系統(tǒng)設(shè)計(jì)過(guò)程中很少考慮安全的因素。但是，隨著互連網(wǎng)和無(wú)線通信等技術(shù)的迅速發(fā)展，嵌入式設(shè)備不斷向數(shù)字化，網(wǎng)絡(luò)化，智能化方向發(fā)展，嵌入式系統(tǒng)安全也成了一個(gè)急需解決的問(wèn)題[2]。對(duì)于嵌入式系統(tǒng)軟件的漏洞挖掘理論已經(jīng)日趨成熟，但是針對(duì)嵌入式系統(tǒng)硬件漏洞挖掘方法還沒(méi)有形成理論。

1 嵌入式系統(tǒng)體系結(jié)構(gòu)

嵌入式系統(tǒng)一般由嵌入式軟件和嵌入式硬件組成，軟件主要由嵌入式操作系統(tǒng)、驅(qū)動(dòng)程序和上層應(yīng)用程序構(gòu)成[3]。硬件主要由嵌入式微處理器和外圍電路構(gòu)成。嵌入式系統(tǒng)層次結(jié)構(gòu)圖如圖1所示。

2 嵌入式操作系統(tǒng)與Linux內(nèi)核模塊驅(qū)動(dòng)

2.1 嵌入式操作系統(tǒng)

嵌入式設(shè)備發(fā)展早期并沒(méi)有操作系統(tǒng)。主要存在兩個(gè)原因，一方面控制嵌入式設(shè)備運(yùn)行只需要一些簡(jiǎn)單的程序，如洗衣機(jī)、微波爐、電冰箱等；另一方面，早期的嵌入式設(shè)備硬件資源有限，沒(méi)有足夠的資源支撐嵌入式系統(tǒng)運(yùn)行。隨著硬件的不斷發(fā)展和用戶(hù)對(duì)于產(chǎn)品功能要求的提高，嵌入式系統(tǒng)不斷變的復(fù)雜，這時(shí)候需要操作系統(tǒng)管理軟硬件資源。

嵌入式操作系統(tǒng)是上層應(yīng)用程序與底層物理硬件的接口，嵌入式操作系統(tǒng)使硬件系統(tǒng)和應(yīng)用軟件層產(chǎn)生相對(duì)獨(dú)立性，可在一定范圍對(duì)硬件模塊進(jìn)行升級(jí)和替換而不影響應(yīng)用軟件的使用。對(duì)于用戶(hù)而言，嵌入式操作系統(tǒng)屏蔽了硬件工作細(xì)節(jié)，為用戶(hù)提供統(tǒng)一的應(yīng)用程序開(kāi)發(fā)接口，這大大簡(jiǎn)化了應(yīng)用程序的開(kāi)發(fā)設(shè)計(jì)流程，同時(shí)保障了軟件質(zhì)量和縮短了開(kāi)發(fā)周期。

2.2 Linux內(nèi)核模塊驅(qū)動(dòng)

設(shè)備驅(qū)動(dòng)程序是嵌入式操作系統(tǒng)的一部分，它是位于應(yīng)用程序和實(shí)際設(shè)備之間的軟件。設(shè)備驅(qū)動(dòng)程序是驅(qū)動(dòng)硬件工作的特殊程序，其直接與硬件打交道。上層應(yīng)用程序與操作系統(tǒng)使用硬件必需調(diào)用相應(yīng)的驅(qū)動(dòng)程序[4]。對(duì)于普通用戶(hù)而言，設(shè)備驅(qū)動(dòng)程序?yàn)橛脩?hù)提供了硬件操作的接口，不需要知道硬件工作具體細(xì)節(jié)就可以驅(qū)動(dòng)硬件工作。用戶(hù)操作通過(guò)一組標(biāo)準(zhǔn)化的調(diào)用完成而這些調(diào)用是和特定的驅(qū)動(dòng)程序無(wú)關(guān)的。驅(qū)動(dòng)程序運(yùn)行于操作系統(tǒng)，操作系統(tǒng)通過(guò)驅(qū)動(dòng)程序才可以控制硬件設(shè)備工作。只有正確安裝了設(shè)備驅(qū)動(dòng)程序，才能保證硬件設(shè)備正常工作。

Linux設(shè)備驅(qū)動(dòng)程序存在兩種安裝使用方法：

（1） 直接將設(shè)備驅(qū)動(dòng)程序編譯進(jìn)Linux內(nèi)核。將編寫(xiě)完成的驅(qū)動(dòng)程序源碼放在Linux內(nèi)核源碼相應(yīng)目錄下，通過(guò)修改Makefile和Kconfig文件將其添加到內(nèi)核目錄樹(shù)中，然后通過(guò)make menuconfig配置該選項(xiàng)，將驅(qū)動(dòng)程序直接編譯進(jìn)Linux內(nèi)核中。

（2） 以可加載內(nèi)核模塊LKM（Loadable Kernel Module）的方式安裝驅(qū)動(dòng)程序。通過(guò)使用已經(jīng)運(yùn)行于嵌入式系統(tǒng)的Linux內(nèi)核相應(yīng)的源碼，將驅(qū)動(dòng)程序編譯成內(nèi)核模塊，加載內(nèi)核模塊。

本文研究的是第2種方式。相比于第1種方式，以加載內(nèi)核模塊的方式安裝驅(qū)動(dòng)程序可在需要時(shí)動(dòng)態(tài)的加載，且不需要重新編譯內(nèi)核，不會(huì)使內(nèi)核過(guò)于龐大和浪費(fèi)內(nèi)存資源。以系統(tǒng)調(diào)用read為例，Linux內(nèi)核模塊工作原理如圖2所示。

3 基于測(cè)試的硬件漏洞挖掘模型

Linux內(nèi)核模塊提供了在用戶(hù)空間操作底層寄存器的途徑，而嵌入式系統(tǒng)存儲(chǔ)器種類(lèi)繁多、容量較大，如何從中選取出對(duì)嵌入式系統(tǒng)運(yùn)行起關(guān)鍵作用的寄存器也是本文研究的重點(diǎn)[5]。本文提出了一種基于測(cè)試的硬件漏洞挖掘模型，如圖3所示。

基于測(cè)試的硬件漏洞挖掘目標(biāo)為：從嵌入式系統(tǒng)存儲(chǔ)體系中搜索對(duì)嵌入式系統(tǒng)運(yùn)行起核心作用的寄存器；挖掘可導(dǎo)致嵌入式系統(tǒng)運(yùn)行出錯(cuò)的寄存器配置。在基于測(cè)試的硬件漏洞挖掘模型中，關(guān)鍵技術(shù)是測(cè)試向量構(gòu)建、確定適度函數(shù)和異常自動(dòng)監(jiān)測(cè)。典型的測(cè)試向量生成方法有兩類(lèi)，基于變異的測(cè)試向量生成方法和基于生成的測(cè)試向量生成方法。

4 基于內(nèi)核模塊的硬件寄存器訪問(wèn)機(jī)制漏洞

為防止對(duì)資源的未經(jīng)授權(quán)的訪問(wèn)，ARM微處理器劃分為不同的操作模式[6]。不同的工作模式運(yùn)行不同級(jí)別的程序和享有不同的操作權(quán)限，Linux用戶(hù)程序工作在ARM微處理器SVC模式，內(nèi)核程序工作在ARM微處理器USR模式。例如，SVC模式可以控制內(nèi)存映射方式、特殊寄存器、中斷和DMA等，而usr模式則不可以。

驅(qū)動(dòng)程序是在“內(nèi)核空間”中運(yùn)行，而應(yīng)用程序是在“用戶(hù)空間”中運(yùn)行[7]。通過(guò)系統(tǒng)調(diào)用和硬件中斷可以完成由“用戶(hù)空間”到“內(nèi)核空間”的轉(zhuǎn)換。兩個(gè)空間分別引用不同的地址映射。即程序代碼使用不同的地址空間。由此可見(jiàn)，想直接通過(guò)指針把“用戶(hù)空間”的數(shù)據(jù)地址傳遞給“內(nèi)核空間”是不可能的，必需通過(guò)Linux提供的一些函數(shù)實(shí)現(xiàn)地址空間的轉(zhuǎn)換，如get_user，put_user，copy_from_user，copy_to_user等。通過(guò)上述分析，可以找出一種在用戶(hù)空間對(duì)硬件寄存器操作的方法，即通過(guò)可加載內(nèi)核模塊的方法操作硬件寄存器。內(nèi)核模塊運(yùn)行于內(nèi)核空間，此時(shí)ARM處理器處于svc模式，有權(quán)限對(duì)硬件寄存器進(jìn)行讀/寫(xiě)操作。本文設(shè)計(jì)一個(gè)可對(duì)看門(mén)狗寄存器進(jìn)行更改的內(nèi)核模塊，動(dòng)態(tài)加載到嵌入式Linux系統(tǒng)中，通過(guò)應(yīng)用程序調(diào)用此內(nèi)核模塊實(shí)現(xiàn)激活看門(mén)狗電路、重啟嵌入式系統(tǒng)的操作。內(nèi)核模塊open函數(shù)中定義的對(duì)看門(mén)狗寄存器的操作代碼如圖4所示。

以上內(nèi)核模塊代碼即為用戶(hù)程序中系統(tǒng)調(diào)用函數(shù)open的最終實(shí)現(xiàn)代碼。Linux中，無(wú)論是內(nèi)核程序還是應(yīng)用程序，都只能對(duì)虛擬地址進(jìn)行操作。圖中代碼完成看門(mén)狗寄存器物理地址到虛擬地址的映射和賦值工作。通過(guò)分別對(duì)看門(mén)狗定時(shí)器數(shù)據(jù)（WTDAT）寄存器、看門(mén)狗定時(shí)器計(jì)數(shù)（WTCNT）寄存器、看門(mén)狗定時(shí)器控制（WTCON）寄存器賦值，實(shí)現(xiàn)啟動(dòng)看門(mén)狗電路，重啟嵌入式系統(tǒng)的操作。

5 結(jié) 語(yǔ)

本文通過(guò)分析嵌入式系統(tǒng)體系結(jié)構(gòu)和基于內(nèi)核模塊的驅(qū)動(dòng)加載原理，獲知嵌入式Linux系統(tǒng)在內(nèi)核層次對(duì)于寄存器沒(méi)有防護(hù)，特別是核心寄存器。攻擊者可通過(guò)動(dòng)態(tài)加載內(nèi)核模塊方式更改核心寄存器值。并且，針對(duì)內(nèi)核中已經(jīng)存在驅(qū)動(dòng)程序的硬件設(shè)備，仍然可通過(guò)可加載內(nèi)核模塊的方式獲得硬件設(shè)備的控制權(quán)，即嵌入式Linux中缺乏不同驅(qū)動(dòng)操作同一硬件的沖突處理機(jī)制。并以看門(mén)狗電路為例，對(duì)看門(mén)狗相關(guān)寄存器值進(jìn)行更改，實(shí)現(xiàn)了嵌入式系統(tǒng)的重啟。文中提出的嵌入式系統(tǒng)硬件漏洞挖掘方法和模型對(duì)于嵌入式系統(tǒng)漏洞挖掘具有一定的應(yīng)用價(jià)值。

參考文獻(xiàn)

[1] 姜榮萍.ARM嵌入式系統(tǒng)分析[J].計(jì)算機(jī)光盤(pán)軟件與應(yīng)用，2010（6）：71?72.

[2] 蔡紅輝.嵌入式系統(tǒng)的安全與分析[J].科教文匯，2007（9）：217?218.

[3] 袁源，戴冠中.LKM后門(mén)綜述[J].計(jì)算機(jī)科學(xué)，2008（7）：5?8.

[4] 李淑文.嵌入式Linux內(nèi)核模塊加載技術(shù)分析[J].廣東經(jīng)濟(jì)管理學(xué)院學(xué)報(bào)，2004（8）：78?80.

[5] 劉瑜.Linux安全分析與系統(tǒng)增強(qiáng)的研究[D].成都：電子科技大學(xué)，2004.

[6] YAMAURA T. How to design practical test cases [J]. Software， IEEE， 1998， 15（6）： 30?36.

[7] HUANG J C. Program instrumentation and software testing [J]. Computer， 1978， 11（4）： 3?8.