董振輝 侯春青 郭堅 張紅軍

(1 北京空間飛行器總體設(shè)計部，北京 100094)(2 華為技術(shù)有限公司，北京 100095)

?

一種航天器軟件進程堆棧使用深度的動態(tài)檢測方法

董振輝1侯春青2郭堅1張紅軍1

(1 北京空間飛行器總體設(shè)計部，北京 100094)(2 華為技術(shù)有限公司，北京 100095)

航天器軟件進程堆棧溢出往往會導(dǎo)致軟件“跑飛”的后果。文章分析了現(xiàn)有堆棧使用深度檢測的靜態(tài)測試方法和動態(tài)測試方法的優(yōu)點和不足，針對航天器數(shù)管軟件的特點，提出了一種適用于航天器數(shù)管軟件進程堆棧使用深度的動態(tài)檢測方法。通過訪問應(yīng)用軟件與系統(tǒng)軟件的接口，獲得進程堆棧的起始地址和大小等信息，將堆棧區(qū)初始化為特定標(biāo)識，對軟件執(zhí)行最大路徑測試后，掃描堆棧區(qū)特定標(biāo)識被覆蓋情況，獲得進程堆棧的使用深度。在嫦娥五號上升器數(shù)管軟件中，實現(xiàn)了此方法，并通過上注在軌維護指令進行了測試。結(jié)果表明：在不借助任何專業(yè)檢測軟件的情況下，該方法能夠?qū)崟r檢測出軟件進程堆棧的最大使用深度，以利于避免進程堆棧溢出的風(fēng)險，提高軟件的可靠性。

航天器軟件；進程堆棧；使用深度；動態(tài)檢測

1 引言

航天器數(shù)管中央處理單元軟件主要完成航天器遙控、遙測、自主管理及與其他分系統(tǒng)通信等功能，關(guān)鍵程度通常為最高等級A級，它由系統(tǒng)軟件和應(yīng)用軟件組成，應(yīng)用軟件運行在系統(tǒng)軟件之上[1]。根據(jù)軟件用戶需求，應(yīng)用軟件一般劃分為多個進程，每個進程堆棧的大小在創(chuàng)建進程時配置，之后不能更改。若進程堆?？臻g分配不足，應(yīng)用軟件運行過程可能發(fā)生進程堆棧溢出，導(dǎo)致軟件運行異常，甚至“跑飛”，從而影響航天器的正常工作，對航天器安全造成極大危害。

合理分配進程堆棧大小的關(guān)鍵，在于對堆棧的使用深度進行準(zhǔn)確測量。堆棧使用深度檢測方法一般分為靜態(tài)測試[2-3]和動態(tài)測試[4]兩種。基于這兩種方法，國內(nèi)外開發(fā)了一系列專業(yè)的堆棧使用深度檢測軟件。例如：德國AbsInt公司的StackAnalyzer軟件基于靜態(tài)測試方法，但測試中要對軟件使用函數(shù)指針的語句人工指定函數(shù)入口地址，這給測試帶來較大的工作量；上海創(chuàng)景科技公司的RTInsight工具基于動態(tài)測試方法，測試中要有專門的硬件工具支持，并且對被測嵌入式系統(tǒng)的硬件接口有特定要求。由于上述專業(yè)檢測軟件面向嵌入式軟件進行通用化設(shè)計，并未針對航天領(lǐng)域進行專門定制，因此測試和分析過程比較復(fù)雜。本文結(jié)合航天器數(shù)管軟件的開發(fā)和測試環(huán)境，提出了一種將堆棧使用深度檢測程序內(nèi)嵌到數(shù)管應(yīng)用軟件的檢測方法，可解決專業(yè)檢測軟件在航天領(lǐng)域應(yīng)用中存在的不足。

2 堆棧溢出檢測技術(shù)

2.1 進程堆棧溢出的原理

航天器數(shù)管軟件通常固化在只讀存儲器中，加電后將文本段和數(shù)據(jù)段均搬移到內(nèi)存，之后軟件一直運行在內(nèi)存中，內(nèi)存空間被分為文本段、數(shù)據(jù)段、BSS(Block Started by Symbol)段和進程堆棧區(qū)等。其中，文本段和數(shù)據(jù)段的大小由編譯后的軟件代碼決定，進程堆棧的大小是在應(yīng)用軟件啟動之初創(chuàng)建各個進程時配置的，之后不能更改，因此，在軟件代碼固定的情況下，進程堆棧的大小決定了內(nèi)存資源的可用余量(一般要求余量占整個內(nèi)存的20%以上)。以創(chuàng)建N個進程的數(shù)管中央處理單元應(yīng)用軟件為例，系統(tǒng)軟件為RTEMS操作系統(tǒng)，內(nèi)存空間分配情況如圖1所示。

由圖1可見，每個進程對應(yīng)一個進程控制塊，控制塊之后即為進程堆棧區(qū)，用于保存進程運行過程中函數(shù)返回地址、函數(shù)形參、局部變量等。若在進程深層次的函數(shù)調(diào)用過程中，進入進程堆棧的數(shù)據(jù)超出了堆棧的邊界，將發(fā)生進程堆棧溢出。這種情況下，首先被覆蓋的就是本進程的進程控制塊，由于控制塊中保存的是進程運行過程中的必要信息，一旦內(nèi)容被改寫，就可能發(fā)生軟件“跑飛”，進而導(dǎo)致軟件復(fù)位前功能出錯，危及整個航天器的安全。

在應(yīng)用軟件運行過程中，通常有兩種情況導(dǎo)致進程堆棧溢出，一是進程函數(shù)嵌套調(diào)用層次過深，二是壓入到進程堆棧的函數(shù)局部變量占用空間太大。但是，進程堆棧溢出往往僅在滿足特定條件時才會發(fā)生，而數(shù)管應(yīng)用軟件在確認測試或整個航天器電測過程中往往不會觸發(fā)堆棧溢出的條件，這就造成了堆棧溢出問題難以事先防范，出現(xiàn)問題后的排查工作也非常困難[5-6]。

2.2 靜態(tài)測試和動態(tài)測試

進程堆棧溢出的檢測方式多種多樣，按照測試原理一般分為靜態(tài)測試和動態(tài)測試兩種。

靜態(tài)測試不依賴于程序的運行就能檢測出堆棧溢出的錯誤。其測試思路是將源程序進行反匯編，分析匯編語句中的特定語句和分支，建立樹狀結(jié)構(gòu)。相對動態(tài)測試而言，靜態(tài)測試的主要優(yōu)勢在于不需要軟件實際發(fā)生堆棧溢出，堆棧使用深度通過理論分析得到；缺點是難以檢測遞歸調(diào)用，因為函數(shù)的遞歸次數(shù)在靜態(tài)下是一個不可確定的參數(shù)，所以只能檢測到部分堆棧溢出情況。另外，靜態(tài)測試分析工具通常會產(chǎn)生大量錯誤的警告信息，實際上會加重分析人員的負擔(dān)。

動態(tài)測試是指檢測過程必須依賴于程序的動態(tài)運行，一般要在程序中插樁或者修改一些指令來檢測堆棧溢出。根據(jù)插入方式的不同，動態(tài)測試可以進一步劃分為靜態(tài)插樁和動態(tài)插樁。動態(tài)測試最主要的缺點是只能檢測出真正發(fā)生動態(tài)溢出的代碼。實際上，只有極少量的代碼能夠觸發(fā)堆棧溢出，測試過程能否運行到這些代碼取決于測試用例的設(shè)計，因此，動態(tài)測試檢測到的堆棧使用深度往往小于等于堆棧的最大使用深度。

3 一種新的航天器軟件進程堆棧使用深度動態(tài)檢測方法

3.1 檢測原理

本文介紹的航天器軟件進程堆棧使用深度動態(tài)檢測方法的原理是，應(yīng)用軟件創(chuàng)建多個進程后，通過應(yīng)用軟件與系統(tǒng)軟件的接口函數(shù)獲取各個進程堆棧的起始地址和空間大小，并將各個進程堆棧區(qū)初始化為特定標(biāo)識的十六進制數(shù)據(jù)。特定標(biāo)識設(shè)計采用巴克碼或2個以上巴克碼的組合，針對壓入堆棧的內(nèi)容可能會與特定標(biāo)識相同的問題，可使用2種不同的特定標(biāo)識獨立執(zhí)行2次檢測，取2次檢測結(jié)果的最大值。在軟件運行過程中，被壓入堆棧的數(shù)據(jù)會將特定標(biāo)識覆蓋。從進程堆棧區(qū)的最低地址開始檢查，凡是內(nèi)容為特定標(biāo)識的地址，可以認為沒有保存過入棧數(shù)據(jù)，檢測到首個不為特定標(biāo)識的地址，即可視為堆棧被使用過的最大地址，該地址減去進程堆棧起始地址，即可獲得堆棧使用深度，檢測原理和流程分別如圖2和圖3所示。

實現(xiàn)本文方法的難點和關(guān)鍵在于獲取各個進程堆棧的起始地址和堆棧大小信息。目前，航天器數(shù)管系統(tǒng)軟件一般使用裁剪過的RTEMS或VxWorks操作系統(tǒng)，應(yīng)用軟件調(diào)用系統(tǒng)軟件接口函數(shù)創(chuàng)建進程時，系統(tǒng)軟件會為每個進程創(chuàng)建并維護一個進程控制塊結(jié)構(gòu)體變量，用于存放進程運行所需的一切信息，包括進程堆棧起始地址和堆棧大小信息。通過對RTEMS或VxWorks操作系統(tǒng)的進程控制塊結(jié)構(gòu)體進行分析，可以獲得進程堆棧的起始地址和堆棧大小信息在進程控制塊結(jié)構(gòu)體中的地址偏移量。每個進程的進程控制塊內(nèi)存地址，可通過應(yīng)用軟件與系統(tǒng)軟件的接口函數(shù)獲取，加上固定偏移之后，即可獲得進程堆棧的起始地址和堆棧大小信息。

3.2 測試流程

如果將檢測程序作為應(yīng)用軟件的一部分添加到代碼中，將會導(dǎo)致軟件編譯后的文本段和數(shù)據(jù)段變大，且該功能并不是應(yīng)用軟件功能的一部分，僅用于地面測試使用，對于航天器上應(yīng)用功能來說就是多余物?？紤]到數(shù)管計算機內(nèi)存中通常留有20%以上的余量，可以在需要開展進程堆棧使用深度測試時，將檢測程序通過在軌維護指令[7]的方式上注到內(nèi)存的空閑區(qū)域，并通過修改應(yīng)用軟件的函數(shù)指針跳轉(zhuǎn)到該函數(shù)執(zhí)行。這種方法避免了對應(yīng)用軟件本身進行修改，且可以隨時啟動測試。堆棧使用深度檢測的測試流程如圖4所示。

檢測程序執(zhí)行之后，結(jié)果保存在內(nèi)存中，并可通過內(nèi)存讀出[8]的方式利用測控信道下傳給地面測試設(shè)備，供軟件開發(fā)人員分析。整個檢測過程基于現(xiàn)有數(shù)管軟件開發(fā)和測試環(huán)境，不須要借助任何專業(yè)軟件或工具，這也是本文方法區(qū)別于其他專業(yè)檢測軟件的一個重要特點。

3.3 結(jié)果獲取時機

航天器數(shù)管應(yīng)用軟件是多任務(wù)軟件，通常會創(chuàng)建一個空閑自檢進程，它運行在系統(tǒng)時間片空閑時段，空閑時段占整個系統(tǒng)時間片的20%以上，以滿足時間性能要求。為避免對其他進程功能產(chǎn)生影響，堆棧使用深度檢測程序運行在空閑自檢進程中，并在每個系統(tǒng)時間片運行1次。

檢測結(jié)果以全局變量的形式保存在特定內(nèi)存地址中，并被新的檢測數(shù)據(jù)不斷更新，檢測數(shù)據(jù)包括各進程堆?？臻g大小和各進程堆棧最大使用深度。地面可在任意時刻上注內(nèi)存讀出指令，獲得檢測結(jié)果。由于軟件實際測出的是堆棧使用過的最大深度，因此在執(zhí)行軟件最大運行路徑測試[9-10]或者觸發(fā)深層次的函數(shù)調(diào)用之后的檢測結(jié)果，才具有實際參考價值。

3.4 堆棧大小分配原則

航天器數(shù)管軟件進程堆棧大小分配時須留有足夠的空間：一是在軟件運行異常情況下，要留有足夠的堆?？臻g，避免軟件馬上“跑飛”，便于問題排查；二是為將來軟件在軌維護留有足夠的空間，避免上注新的函數(shù)模塊后導(dǎo)致進程堆棧空間不足。但是，航天器數(shù)管軟件通常要求內(nèi)存余量大于20%，在內(nèi)存資源非常有限的情況下，進程堆棧又不宜分配過大，以免浪費。

4 實例驗證

以嫦娥五號上升器數(shù)管分系統(tǒng)綜合管理單元軟件在地面測試驗證為例，其處理器采用TSC695F，只讀存儲器容量為128 Kbyte，內(nèi)存容量為2 Mbyte，系統(tǒng)軟件為RTEMS操作系統(tǒng)，應(yīng)用軟件共創(chuàng)建了12個進程。該軟件為典型航天器數(shù)管軟件，可基于本文方法執(zhí)行堆棧使用深度檢測，檢測過程不須要借助其他專業(yè)軟件，僅使用數(shù)管軟件自身的開發(fā)和測試環(huán)境，如圖5所示。

對照圖4檢測程序的測試流程，在圖5所示環(huán)境中，可通過總線仿真卡、測試客戶機和主控計算機模擬觸發(fā)軟件最大運行路徑的條件，檢測程序以在軌維護指令的形式上注到數(shù)管應(yīng)用軟件，檢測結(jié)果通過上注內(nèi)存讀出指令后從下行遙測中獲取。在相同觸發(fā)軟件最大運行路徑的條件下，使用同樣基于動態(tài)測試方法的RTInsight工具執(zhí)行堆棧使用深度檢測，將2種檢測方法進行比較，結(jié)果見表1，證明本文方法是可行的。執(zhí)行堆棧使用深度檢測程序后，堆?？臻g分配優(yōu)化前的測試結(jié)果見表2和圖6。

通過分析測試結(jié)果，結(jié)合軟件任務(wù)需求，對部分進程的堆棧大小進行調(diào)整，將(Task)12的堆?？臻g擴展保證足夠的余量，將(Task)2的堆?？臻g縮小以避免不必要的浪費。調(diào)整后，將軟件重新編譯運行，并在相同條件下重新執(zhí)行堆棧使用深度檢測程序。堆?？臻g分配優(yōu)化后的測試結(jié)果見表3和圖7。

表1 2種檢測方法比較Table 1 Comparison of two detection methods

表2 優(yōu)化前堆棧使用情況Table 2 Usage of stack before optimization

進程ID分配空間/byte已用空間/byte使用百分比/%(Task)112560152012(Task)28704133615(Task)320752324815(Task)4436848010(Task)520752714434(Task)620752543226(Task)720752376018(Task)820752432021(Task)910512237622(Task)10436899222(Task)1110512236823(Task)1210512227222總計1652963524821

通過優(yōu)化前后的對比可見，在所有進程堆棧占用內(nèi)存之和變化不大的情況下，通過調(diào)整各個進程堆棧大小，可以實現(xiàn)每個進程堆棧余量百分比保持在一個合理的范圍，從而實現(xiàn)進程堆棧空間的合理分配。

5 結(jié)束語

根據(jù)航天器數(shù)管軟件的運行環(huán)境和使用特點，本文設(shè)計了一種進程堆棧使用深度的動態(tài)檢測方法。此方法不須要借助專業(yè)檢測軟件，具有實現(xiàn)簡單、測試方便的特點，有利于優(yōu)化進程堆?？臻g分配。本文方法屬于動態(tài)測試方法，檢測結(jié)果為軟件開始運行后所使用過的最大堆棧深度，不一定等于理論最大堆棧使用深度，兩者的誤差取決于軟件測試用例的設(shè)計。該方法已在航天器地面軟件調(diào)試中得到了應(yīng)用，對提高航天器軟件的可靠性和安全性起到了一定作用。

References)

[1] 何熊文，孫勇.一種衛(wèi)星數(shù)管中心計算機軟件的工程實現(xiàn)[J].航天器工程，2007,16(5)：47-53

He Xiongwen，Sun Yong. Engineering realization of software in central terminal unit of satellite data mana-gement system [J]. Spacecraft Engineering，2007,16(5)： 47-53 (in Chinese)

[2]張西超，郭向英.一種用于分析MCS-51目標(biāo)碼堆棧深度的方法[J].空間控制技術(shù)與應(yīng)用，2010，36(2)：47-50

Zhang Xichao，Guo Xiangying. An approach to MCS-51 object stack depth analysis [J]. Aerospace Control and Application,2010,36(2)： 47-50 (in Chinese)

[3]魏強，金然，王清賢.基于中間匯編的緩沖區(qū)溢出檢測模型[J].計算機工程，2009，35(3)：169-172

Wei Qiang，Jin Ran，Wang Qingxian. Buffer overflow detection model based on intermedia assembly [J]. Computer Engineering,2009,35(3)： 169-172 (in Chinese)

[4]劉通平.棧溢出的動態(tài)檢測技術(shù)[J].計算機科學(xué)，2007，

34(9)：282-286

Liu Tongping. Dynamic detection of stack overflow [J]. Computer Science,2007,34(9)： 282-286 (in Chinese)

[5]孫海彬，徐良賢，楊懷銀.堆棧溢出攻擊的原理及檢測[J].計算機工程，2001，27(1)：127-128

Sun Haibin，Xu Liangxian，Yang Huaiyin. The principle and detection of buffer overflow attack [J]. Computer Engineering,2001,27(1)： 127-128 (in Chinese)

[6]潘琦，王澄，楊宇航.堆棧溢出攻擊的分析及防范[J].上海交通大學(xué)學(xué)報，2002，36(9)：1346-1350

Pan Qi，Wang Cheng，Yang Yuhang. Analysis and prevention of the stack overflow attacking [J]. Journal of Shanghai Jiaotong University，2002,36(9)： 1346-1350 (in Chinese)

[7]安軍社，劉艷秋，孫輝先.軟件的動態(tài)維護與實現(xiàn)[J].計算機工程，2003，29(2)：238-239

An Junshe，Liu Yanqiu，Sun Huixian. Implementation of on-board software maintenance [J]. Computer Engineering,2003,29(2)： 238-239 (in Chinese)

[8]何熊文，張猛.遙控和遙測包應(yīng)用標(biāo)準(zhǔn)在航天器中的使用方法[J].航天器工程，2012，21(3)：54-60

He Xiongwen，Zhang Meng. Application method of telecommand and telemetry packet utilization standard in spacecraft [J]. Spacecraft Engineering,2012,21(3)： 54-60 (in Chinese)

[9]吳國偉，姚琳，岳峰.一種快速程序最壞執(zhí)行時間分析方法研究[J].計算機工程與應(yīng)用，2010，46(21)：69-71，96

Wu Guowei，Yao Lin，Yue Feng. Study on fast program worst-case execution time estimation [J]. Computer Engineering and Applications,2010,46(21)： 69-71，96 (in Chinese)

[10] 劉育芳，張立臣.兩種基于符號的最壞執(zhí)行時間分析方法的比較與分析[J].微電子學(xué)與計算機，2006，23(5)：60-62

Liu Yufang，Zhang Lichen. Comparison and analysis of two symbolic worst-case execution time analysis methods [J]. Microelectronics & Computer,2006,23(5)： 60-62 (in Chinese)

(編輯：夏光)

Dynamic Detection Method of Spacecraft Software Process Stack Used Depth

DONG Zhenhui1HOU Chunqing2GUO Jian1ZHANG Hongjun1

(1 Beijing Institute of Spacecraft System Engineering,Beijing 100094,China) (2 Huawei Technologies Co., Ltd.,Beijing 100095,China)

Spacecraft software process stack overflow often causes the procedure to lose control. The paper analyzes the advantages and disadvantages of stack used depth detection of static test and dynamic test methods,and proposes a dynamic detection method according to the characteristics of spacecraft software. Through the interface of application software and system software,the start address and size of process stack can be obtained and the stack space will be initialized as specific identity after the software performs the maximum path test,and the stack space will be scanned to obtain the process stack used depth. In CE-5 ascent stage onboard data handling software,the method is realized and tested by the way of onboard software maintenance. The results show that the method can detect the maximum used depth of the process stack in real time without any professional software,which is beneficial for avoiding the risk of process stack overflow,then improving the software reliability.

spacecraft software； process stack； used depth； dynamic detection

2016-08-16；

2016-12-29

國家重大科技專項工程

董振輝，男，工程師，從事航天器器載軟件設(shè)計工作。Email：564760683@qq.com。

V446

A

10.3969/j.issn.1673-8748.2017.01.013