利用ColdFire uClinux實現數據采集和傳輸
1 防危核技術
本文引用地址:http://www.104case.com/article/21271.htm防危核關心的是如何保護設備不被非法訪問,以避免因對設備的誤操作引起的重大生命財產損

為了不影響系統的性能,防危核應盡可能小,為此系統所有的防危核策略均由防危核為實施是不現實的。采用將防危策略放在防危核外部的防危策略庫中的方法,縮小防危核的大小主,防危核在防危處理時訪問防危策略庫,以獲取相應防危策略。
(2)完備性
完備性要求,不通過防危核主體就不能對客體進行任何訪問操作。它表明對設備的任何訪問請求都必須通過防危核的驗證。如果系統中存在其它組件可以繞開防危核訪問設備,顯然安全將無法得到保障。所以采用了防危核技術的系統必須要保證防危核對設備的專一控制。
(3)通用性
通用性指防危核模塊的基本結構不依賴于任何特定的操作系統和設備,只需要操作系統和設備滿足防危核的接口要求,并修改策略庫,就可以將防危核軟件應用到任何操作系統和設備中。 2 開發平臺rt-linux os構架與特征
通常,安全關鍵系統對實時性有嚴格要求,我們選擇rt-linux操作系統為安全實驗模型的開發平臺。
rt-linux是美國nmt大學對標準linux的一個實時擴展版本,其結構如圖2所示。它實際上是給原linux內核打了實時補丁,打了補丁的linux內核由兩部分組成:rt-linux和linux。在rt-linux內核實時應用(任務)則是一種可加載的內核模塊,具有高的優先級。另外,所有的中斷都先由rt-linux來處理,之后才由標準的內核來處理。非實時任務通過rt-linux提供的fifo(一種透明的管道)與實時任務通信。
rt-linux可以提供應用程序的硬實時保證。所謂“硬實時”是區別“軟實時”而言的。硬實時對滿足時限的要求比軟實時嚴格,通常硬實時的系統響應時間在ms或μs級,而軟實時對其響應時間的要求沒有那么嚴格。硬實時工作通常指超過時限要求就會造成嚴重損害的工作,而軟實時即使超過時限也不會帶來嚴重后果。以核能電廠和看vcd為例,用在核能電廠的實時操作系統,如果超出時限可能會導致嚴重的損害,然而vcd播放器超出時限只不過讓使用者感覺不舒服而已。所以前者是硬實時,后者是軟實時。
這樣一種linux實時化方案,對原linux改動最小,又能充分利用標準linux的全部特性,從而能滿足實時系統防危核控制模型研究的諸多要求,因此,nmt rt-linux是本安全模型研究的最佳實驗平臺。

通常,基于rt-linux的應用程序由兩部分組成:一部分運行在real-time下,另一部分運行在標準的linux下。運行在real-time下的任務是實時任務,它作為linux的內核模塊(module)被加載到linux內核中,也就是它運行于linux內核態,因此需要使用linux內核態資源。本控制模型系統中的防危核正是作為實時任務運行于linux內核態,而十字路口交通燈控制設備運行于標準linux下。控制設備任務采用linux的tcl/tk圖形編程語言編程,以友好、形象、直觀的界面模擬防危核對十字路口交通燈的控制。下面將分別介紹上述資源。
3.1 內核模塊加載機制 linux提供的可加載內核模塊(module)是linux內核支持的動態可加載模塊,它們是核心的一部分;但是并沒有編譯到核心里面去,只是一個目標文件,可根據需要在系統啟動后動態地加載或卸載,linux中大多數設備驅動程序或文件系統都做成這樣的模塊。超級用戶可以通過insmod和rmmod命令分別載入和卸載模塊。核心也可在需要時,請求守護進程(kerneld)載入和卸載模塊。這種方式可以減小核心代碼的規模,使核心配置更為靈活,并且用戶不必每次修改后都重新編譯核心代碼和啟動系統。
一旦linux模塊載入核心后,就成為核心代碼的一部分。它與其它核心代碼的地位是相同的。當模塊載入系統核心時,系統修改核心中的符號表,將新裁入模塊提供的資源和符號加載核心符號表中,新載入的模塊可以訪問已載入的模塊提供的資源為自己服務。 3.2 tcl/tk圖形編程語言
本系統中的圖形用戶界面采用tcl/tk圖形編程語言,使界面友好、形象、直觀。tcl是tool control language(工具控制語言)的縮寫。tk是tcl“圖形工具箱”的擴展,它提供各種標準的gul接口,以利于迅速進行高級應用程序開發。
tcl/tk是一種解釋執行的腳本語言,應用中通常將嵌入到c程序中。“小巧、易學、高效、跨平臺執行”是tcl語言特點的集中體現。實際上,tcl不僅僅在開發小的應用程序上有其快速、可維護性強等優勢,在大型應用系統方面,如操作系統及網絡管理、測試系統、自控、仿真、可視化應用及計算機輔助設計等方面都有豐富的應用成果。
4 防危核實驗原型的設計與實現
圖3為以交通燈控制為模型的防危核系統體系結構。
由圖3可以看出,整個系統由四個部分組成:防危核、模擬設備、設備控制器、命令文件。防危核作為rt-linux的實時任務,與模擬設備、設備控制器間的通信采用rt-linux提供的實時fifo;而模擬設備和設備控制器間的通信使用linux提供的非實時命名管道。下面仔細分析各模擬所提供的功能。2⑤⑥⑦sδδλδωω·αγ∈βθθθ→→→→ττ 防危核模塊的設計和實現
系統在運行時先通過命令insmod將防危核動態加載到linux內核中,于是它便一直運行內核態。當不需要時再用命令rmmod手動卸載。這種方式下會對操作系統內核的基本功能產生任何影響,同時又可以保證demo系統的實時性。

下面定義以交通燈為模型的防危系統的防危策略。
返回值=0;
/*表明經防危核驗證為正確命令*/
返回值=1;
/*命令經防危核直接傳送到模擬設備而未經過安全檢測模塊驗證,模擬設備狀態根據此值改變*/
返回值=2;
/*當前設備狀態驗證失敗,失敗原因不明。
措施:模擬設備保持當前狀態不變*/
返回值=3;
/*同一個方向有多個信號燈同時開啟。
措施:所有交通燈都關閉,然后在收到新的命令前設備執行缺省命令序列,此處由模擬設備接到“3”時直接處理*/
返回值=4;
/*四個方向同時為黃燈或綠燈。
措施:系統恢復到初始狀態。在收到新的命令前設備執行缺省狀態*/
反回值=5;
/*命令驗證失敗,失敗原因不明,
措施:模擬設備保持當前狀態不變*/
返回值=6;
/*信號燈保持當前狀態的時間短于最短時間(<2s),
措施:模擬設備自動延遲(sleep(time))顯示此命令*/
返回值=7;
/*使同一個方向有多個信號燈同時開啟的信號燈命令錯誤。
措施:不執行此命令,保持當前信號燈狀態*/
返回值=8;
/*命令的執行將會使信號燈變化的順序不正確。
措施:不執行此命令,保持當前信號燈狀態*/
返回值=9;
/*四個方面同時為黃燈或綠燈的命令。
措施:不執行此命令,保持不前信號燈狀態*/
4.2 模擬設備模塊
防危核系統中以十字路口交通燈模擬外部設備。當經防危驗證設備命令合法時,此模擬接受防危核傳入的真實設備命令int realcmd(),并向防危核返回設備當前最新狀態。用圖形方式形象、直觀地顯示設備本身的實時狀態(交通燈顏色的變化)、模擬設備當前接收的命令和命令驗證結果(合法或非法命令,對非法命令顯示出錯原因)。
該進程中設有三個線程,其中第一個線程專門用于讀管道fifo6(實時管道)獲取防危核發送的控制命令,第二個線程讀管道myfifo(非實時管道)獲取命令控制器發送的設備控制命令,第三個線程用tcl/tk腳本語言實現模擬設備形象、美觀的圖形顯示功能。當模擬設備啟動后,自動進行初始化并調用缺省的交通燈控制命令序列完成基本操作,直以有來自設備控制和防危核的設備控制命令為止。若交通燈的顯示時間超過一定時間,則強制設備執行缺省的設備狀態。
4.3 設備控制器模塊
模擬設備控制器作為一個進程獨立運行,控制器先從命令文件中獲取命令參數,然后根據命令的防危等級分別向模擬設備和防危核發送設備操作命令(包括正常的和不正常的操作命令)。命令中設置了時間控制參數,控制器按此時間間隔值發送設備命令。
4.4 設備命令文件
設備命令文件中存放了各種對交通燈的操作命令,包括正常和不正確命令。命令執行有三種防危等級可供選擇:第一種,不通過防危核的命令,操作命令直接由設備控制器發送到模擬設備;第二種,通過防危核并驗證其正確性的命令,此時防危核將調用防危策略庫的相應防危策略驗證命令,然后將驗證結果發送到模擬設備;第三種,通過防危核但不驗證設備操作的命令,命令被防危核直接送到模擬設備。設計三種等級命令的目的在于,比較是否使用防危核或是否進行命令驗證在系統性能和防危性上的差異。
設備的命令格式為:char sourcecmd="cmd east-light,cmd north-light,cmd west-light,cmd south-light,int time,bool verifiedl,bool verfied2"。操作命令要對十字路口的12盞交通燈進行操作控制。參數time指本命令相對于前一條命令延遲多長時間發送。參數verified1=0表示不經過防危核驗證直接傳送到設備的命令;verified1=1表示要經過防危核驗證。verified2=0表示該命令直接發送到模擬設備不經過防危核的任何處理;verified2=1表示該命令要通過防危核。
struct cmd
{
char first-light-color;
char second-light-color;
char third-light-color;
}
first-light-color,second-light-color,third-light-color表示每個方向三盞燈的顏色插入相應的顏色的圖片。整個圖形界面形象、美觀。
5 實驗系統的測試評價
根據防危核設計要求,從防危核的大小、對系統實時性的影響以及完備性三方面對本實驗系統進行測試。
①防危核大小:防危核所編譯后的目標文件為5kb,相對于rt-linux內核源碼是非常小的。
②時間開銷:將防危核對控制命令驗證所需時間進行了200次測試,得出其平均時間僅10μs左右,說明防危核對系統實時性影響非常小。
③完備性:將防危核對第二種控制命令各種情況的防危處理結果表明,防危核的驗證結果完全正確。說明滿足防危核完備性要求。
以上對防危核的測試結果表明,本控制模型完全滿足防危核設計要求,防危核機制完全可以在實時操作系統中使用。 結語
根據防危核等相關理論并結合rt-linux操作系統本身的特色,本文先從理論上分析了在rt-linux中實現防危核的可行性,然后通過實際例子實現了基于rt-linux的防危核,為防危核探索了一種新的實現途徑。最后,通過對實驗系統的測試進一步證明防危保障機制在實時操作系統中完全可行.
評論