嵌入式Linux Kernel錯誤跟蹤技術(shù)

這種解決問(wèn)題所需時(shí)間呈上升的趨勢固然有軟件問(wèn)題，但缺乏必要的手段以輔助解決問(wèn)題才是主要的原因。通過(guò)對故障的統計跟蹤發(fā)現，難以解決的軟件錯誤和從發(fā)現到解決耗時(shí)較長(cháng)的軟件錯誤都集中在操作系統的核心部分，這其中又有很大比例集中在驅動(dòng)程序部分[2]。因此，錯誤跟蹤技術(shù)被看成是提高系統安全完整性等級的一個(gè)重要措施[1]，大多數現代操作系統均為發(fā)展提供了操作系統內核“崩潰轉儲”機制，即在軟件系統宕機時(shí)，將內存內容保存到磁盤(pán)[3]，或者通過(guò)網(wǎng)絡(luò )發(fā)送到故障服務(wù)器[3]，或者直接啟動(dòng)內核調試器[4]等，以供事后分析改進(jìn)。

基于Linux操作系統內核的崩潰轉儲機制近年來(lái)有以下幾種：

(1) LKCD（Linux Kernel Crash Dump）機制[3];

(2) KDUMP（Linux Kernel Dump）機制[4]；

(3) KDB機制[5]；

(4) KGDB機制[6]。

綜合上述幾種機制可以發(fā)現,這四種機制之間有以下三個(gè)共同點(diǎn)：

(1) 適用于為運算資源豐富、存儲空間充足的應用場(chǎng)合；

(2) 發(fā)生系統崩潰后恢復時(shí)間無(wú)嚴格要求；

(3) 主要針對較通用的硬件平臺，如X86平臺。

在嵌入式應用場(chǎng)合想要直接使用上列機制中的某一種，卻遇到以下三個(gè)難點(diǎn)無(wú)法解決：

(1) 存儲空間不足

嵌入式系統一般采用Flash作為存儲器，而Flash容量有限，且可能遠遠小于嵌入式系統中的內存容量。因此將全部?jì)却鎯热荼４娴紽lash不可行。

(2) 記錄時(shí)間要求盡量短

嵌入式系統一般有復位響應時(shí)間盡量短的要求，有的嵌入式操作系統復位重啟時(shí)間不超過(guò)2s，而上述幾種可用于Linux系統的內核崩潰轉儲機制耗時(shí)均不可能在30s內。寫(xiě)Flash的操作也很耗時(shí)間，實(shí)驗顯示，寫(xiě)2MB數據到Flash耗時(shí)達到400ms之多。

(3) 要求能夠支持特定的硬件平臺

嵌入式系統的硬件多種多樣，上面提到的四種機制均是針對X86平臺提供了較好的支持，而對于其他體系的硬件支持均不成熟。

由于這些難點(diǎn)的存在，要將上述四種內核崩潰轉儲機制中的一種移植到特定的嵌入式應用平臺是十分困難的。因此，針對上述嵌入式系統的三個(gè)特點(diǎn)，本文介紹一種基于特定平臺的嵌入式Linux內核崩潰信息記錄機制LCRT(Linux Crash Record and Trace)，為定位嵌入式Linux系統中軟件故障和解決軟件故障提供輔助手段。

1 Linux內核崩潰的分析

分析Linux內核對于運行期間各種“陷阱”的處理可以得知，Linux內核對于應用程序導致的錯誤可以予以監控，在應用程序發(fā)生除零、內存訪(fǎng)問(wèn)越界、緩沖區溢出等錯誤時(shí)，Linux內核的異常處理例程可以對這些由應用程序引起的異常情況予以處理。當應用程序產(chǎn)生不可恢復的錯誤時(shí)，Linux內核可以?xún)H僅終止產(chǎn)生錯誤的應用程序，其他應用程序仍然可以正常運行。

如果Linux內核本身或者新開(kāi)發(fā)的Linux內核模塊存在bug，產(chǎn)生了“除零”，“內存訪(fǎng)問(wèn)越界”、“緩沖區溢出”等錯誤，同樣會(huì )由Linux內核的異常處理例程來(lái)處理。Linux內核通過(guò)在異常處理程序中判斷，如果發(fā)現是“嚴重的不可恢復”的內核異常，則會(huì )導致“內核恐慌”（kernel panic），即Linux內核崩潰。圖1所示為L(cháng)inux內核對異常情況的處理流程。