一种航天器软件进程堆栈使用深度的动态检测方法

董振辉 侯春青 郭坚 张红军

(1 北京空间飞行器总体设计部，北京 100094)(2 华为技术有限公司，北京 100095)



一种航天器软件进程堆栈使用深度的动态检测方法

董振辉1侯春青2郭坚1张红军1

(1 北京空间飞行器总体设计部，北京 100094)(2 华为技术有限公司，北京 100095)

航天器软件进程堆栈溢出往往会导致软件“跑飞”的后果。文章分析了现有堆栈使用深度检测的静态测试方法和动态测试方法的优点和不足，针对航天器数管软件的特点，提出了一种适用于航天器数管软件进程堆栈使用深度的动态检测方法。通过访问应用软件与系统软件的接口，获得进程堆栈的起始地址和大小等信息，将堆栈区初始化为特定标识，对软件执行最大路径测试后，扫描堆栈区特定标识被覆盖情况，获得进程堆栈的使用深度。在嫦娥五号上升器数管软件中，实现了此方法，并通过上注在轨维护指令进行了测试。结果表明：在不借助任何专业检测软件的情况下，该方法能够实时检测出软件进程堆栈的最大使用深度，以利于避免进程堆栈溢出的风险，提高软件的可靠性。

航天器软件；进程堆栈；使用深度；动态检测

1 引言

航天器数管中央处理单元软件主要完成航天器遥控、遥测、自主管理及与其他分系统通信等功能，关键程度通常为最高等级A级，它由系统软件和应用软件组成，应用软件运行在系统软件之上[1]。根据软件用户需求，应用软件一般划分为多个进程，每个进程堆栈的大小在创建进程时配置，之后不能更改。若进程堆栈空间分配不足，应用软件运行过程可能发生进程堆栈溢出，导致软件运行异常，甚至“跑飞”，从而影响航天器的正常工作，对航天器安全造成极大危害。

合理分配进程堆栈大小的关键，在于对堆栈的使用深度进行准确测量。堆栈使用深度检测方法一般分为静态测试[2-3]和动态测试[4]两种。基于这两种方法，国内外开发了一系列专业的堆栈使用深度检测软件。例如：德国AbsInt公司的StackAnalyzer软件基于静态测试方法，但测试中要对软件使用函数指针的语句人工指定函数入口地址，这给测试带来较大的工作量；上海创景科技公司的RTInsight工具基于动态测试方法，测试中要有专门的硬件工具支持，并且对被测嵌入式系统的硬件接口有特定要求。由于上述专业检测软件面向嵌入式软件进行通用化设计，并未针对航天领域进行专门定制，因此测试和分析过程比较复杂。本文结合航天器数管软件的开发和测试环境，提出了一种将堆栈使用深度检测程序内嵌到数管应用软件的检测方法，可解决专业检测软件在航天领域应用中存在的不足。

2 堆栈溢出检测技术

2.1 进程堆栈溢出的原理

航天器数管软件通常固化在只读存储器中，加电后将文本段和数据段均搬移到内存，之后软件一直运行在内存中，内存空间被分为文本段、数据段、BSS(Block Started by Symbol)段和进程堆栈区等。其中，文本段和数据段的大小由编译后的软件代码决定，进程堆栈的大小是在应用软件启动之初创建各个进程时配置的，之后不能更改，因此，在软件代码固定的情况下，进程堆栈的大小决定了内存资源的可用余量(一般要求余量占整个内存的20%以上)。以创建N个进程的数管中央处理单元应用软件为例，系统软件为RTEMS操作系统，内存空间分配情况如图1所示。

由图1可见，每个进程对应一个进程控制块，控制块之后即为进程堆栈区，用于保存进程运行过程中函数返回地址、函数形参、局部变量等。若在进程深层次的函数调用过程中，进入进程堆栈的数据超出了堆栈的边界，将发生进程堆栈溢出。这种情况下，首先被覆盖的就是本进程的进程控制块，由于控制块中保存的是进程运行过程中的必要信息，一旦内容被改写，就可能发生软件“跑飞”，进而导致软件复位前功能出错，危及整个航天器的安全。

在应用软件运行过程中，通常有两种情况导致进程堆栈溢出，一是进程函数嵌套调用层次过深，二是压入到进程堆栈的函数局部变量占用空间太大。但是，进程堆栈溢出往往仅在满足特定条件时才会发生，而数管应用软件在确认测试或整个航天器电测过程中往往不会触发堆栈溢出的条件，这就造成了堆栈溢出问题难以事先防范，出现问题后的排查工作也非常困难[5-6]。

2.2 静态测试和动态测试

进程堆栈溢出的检测方式多种多样，按照测试原理一般分为静态测试和动态测试两种。

静态测试不依赖于程序的运行就能检测出堆栈溢出的错误。其测试思路是将源程序进行反汇编，分析汇编语句中的特定语句和分支，建立树状结构。相对动态测试而言，静态测试的主要优势在于不需要软件实际发生堆栈溢出，堆栈使用深度通过理论分析得到；缺点是难以检测递归调用，因为函数的递归次数在静态下是一个不可确定的参数，所以只能检测到部分堆栈溢出情况。另外，静态测试分析工具通常会产生大量错误的警告信息，实际上会加重分析人员的负担。

动态测试是指检测过程必须依赖于程序的动态运行，一般要在程序中插桩或者修改一些指令来检测堆栈溢出。根据插入方式的不同，动态测试可以进一步划分为静态插桩和动态插桩。动态测试最主要的缺点是只能检测出真正发生动态溢出的代码。实际上，只有极少量的代码能够触发堆栈溢出，测试过程能否运行到这些代码取决于测试用例的设计，因此，动态测试检测到的堆栈使用深度往往小于等于堆栈的最大使用深度。

3 一种新的航天器软件进程堆栈使用深度动态检测方法

3.1 检测原理

本文介绍的航天器软件进程堆栈使用深度动态检测方法的原理是，应用软件创建多个进程后，通过应用软件与系统软件的接口函数获取各个进程堆栈的起始地址和空间大小，并将各个进程堆栈区初始化为特定标识的十六进制数据。特定标识设计采用巴克码或2个以上巴克码的组合，针对压入堆栈的内容可能会与特定标识相同的问题，可使用2种不同的特定标识独立执行2次检测，取2次检测结果的最大值。在软件运行过程中，被压入堆栈的数据会将特定标识覆盖。从进程堆栈区的最低地址开始检查，凡是内容为特定标识的地址，可以认为没有保存过入栈数据，检测到首个不为特定标识的地址，即可视为堆栈被使用过的最大地址，该地址减去进程堆栈起始地址，即可获得堆栈使用深度，检测原理和流程分别如图2和图3所示。

实现本文方法的难点和关键在于获取各个进程堆栈的起始地址和堆栈大小信息。目前，航天器数管系统软件一般使用裁剪过的RTEMS或VxWorks操作系统，应用软件调用系统软件接口函数创建进程时，系统软件会为每个进程创建并维护一个进程控制块结构体变量，用于存放进程运行所需的一切信息，包括进程堆栈起始地址和堆栈大小信息。通过对RTEMS或VxWorks操作系统的进程控制块结构体进行分析，可以获得进程堆栈的起始地址和堆栈大小信息在进程控制块结构体中的地址偏移量。每个进程的进程控制块内存地址，可通过应用软件与系统软件的接口函数获取，加上固定偏移之后，即可获得进程堆栈的起始地址和堆栈大小信息。

3.2 测试流程

如果将检测程序作为应用软件的一部分添加到代码中，将会导致软件编译后的文本段和数据段变大，且该功能并不是应用软件功能的一部分，仅用于地面测试使用，对于航天器上应用功能来说就是多余物。考虑到数管计算机内存中通常留有20%以上的余量，可以在需要开展进程堆栈使用深度测试时，将检测程序通过在轨维护指令[7]的方式上注到内存的空闲区域，并通过修改应用软件的函数指针跳转到该函数执行。这种方法避免了对应用软件本身进行修改，且可以随时启动测试。堆栈使用深度检测的测试流程如图4所示。

检测程序执行之后，结果保存在内存中，并可通过内存读出[8]的方式利用测控信道下传给地面测试设备，供软件开发人员分析。整个检测过程基于现有数管软件开发和测试环境，不须要借助任何专业软件或工具，这也是本文方法区别于其他专业检测软件的一个重要特点。

3.3 结果获取时机

航天器数管应用软件是多任务软件，通常会创建一个空闲自检进程，它运行在系统时间片空闲时段，空闲时段占整个系统时间片的20%以上，以满足时间性能要求。为避免对其他进程功能产生影响，堆栈使用深度检测程序运行在空闲自检进程中，并在每个系统时间片运行1次。

检测结果以全局变量的形式保存在特定内存地址中，并被新的检测数据不断更新，检测数据包括各进程堆栈空间大小和各进程堆栈最大使用深度。地面可在任意时刻上注内存读出指令，获得检测结果。由于软件实际测出的是堆栈使用过的最大深度，因此在执行软件最大运行路径测试[9-10]或者触发深层次的函数调用之后的检测结果，才具有实际参考价值。

3.4 堆栈大小分配原则

航天器数管软件进程堆栈大小分配时须留有足够的空间：一是在软件运行异常情况下，要留有足够的堆栈空间，避免软件马上“跑飞”，便于问题排查；二是为将来软件在轨维护留有足够的空间，避免上注新的函数模块后导致进程堆栈空间不足。但是，航天器数管软件通常要求内存余量大于20%，在内存资源非常有限的情况下，进程堆栈又不宜分配过大，以免浪费。

4 实例验证

以嫦娥五号上升器数管分系统综合管理单元软件在地面测试验证为例，其处理器采用TSC695F，只读存储器容量为128 Kbyte，内存容量为2 Mbyte，系统软件为RTEMS操作系统，应用软件共创建了12个进程。该软件为典型航天器数管软件，可基于本文方法执行堆栈使用深度检测，检测过程不须要借助其他专业软件，仅使用数管软件自身的开发和测试环境，如图5所示。

对照图4检测程序的测试流程，在图5所示环境中，可通过总线仿真卡、测试客户机和主控计算机模拟触发软件最大运行路径的条件，检测程序以在轨维护指令的形式上注到数管应用软件，检测结果通过上注内存读出指令后从下行遥测中获取。在相同触发软件最大运行路径的条件下，使用同样基于动态测试方法的RTInsight工具执行堆栈使用深度检测，将2种检测方法进行比较，结果见表1，证明本文方法是可行的。执行堆栈使用深度检测程序后，堆栈空间分配优化前的测试结果见表2和图6。

通过分析测试结果，结合软件任务需求，对部分进程的堆栈大小进行调整，将(Task)12的堆栈空间扩展保证足够的余量，将(Task)2的堆栈空间缩小以避免不必要的浪费。调整后，将软件重新编译运行，并在相同条件下重新执行堆栈使用深度检测程序。堆栈空间分配优化后的测试结果见表3和图7。

表1 2种检测方法比较Table 1 Comparison of two detection methods

表2 优化前堆栈使用情况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

通过优化前后的对比可见，在所有进程堆栈占用内存之和变化不大的情况下，通过调整各个进程堆栈大小，可以实现每个进程堆栈余量百分比保持在一个合理的范围，从而实现进程堆栈空间的合理分配。

5 结束语

根据航天器数管软件的运行环境和使用特点，本文设计了一种进程堆栈使用深度的动态检测方法。此方法不须要借助专业检测软件，具有实现简单、测试方便的特点，有利于优化进程堆栈空间分配。本文方法属于动态测试方法，检测结果为软件开始运行后所使用过的最大堆栈深度，不一定等于理论最大堆栈使用深度，两者的误差取决于软件测试用例的设计。该方法已在航天器地面软件调试中得到了应用，对提高航天器软件的可靠性和安全性起到了一定作用。

References)

[1] 何熊文，孙勇.一种卫星数管中心计算机软件的工程实现[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目标码堆栈深度的方法[J].空间控制技术与应用，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]魏强，金然，王清贤.基于中间汇编的缓冲区溢出检测模型[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]刘通平.栈溢出的动态检测技术[J].计算机科学，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].上海交通大学学报，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]安军社，刘艳秋，孙辉先.软件的动态维护与实现[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]何熊文，张猛.遥控和遥测包应用标准在航天器中的使用方法[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]吴国伟，姚琳，岳峰.一种快速程序最坏执行时间分析方法研究[J].计算机工程与应用，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] 刘育芳，张立臣.两种基于符号的最坏执行时间分析方法的比较与分析[J].微电子学与计算机，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

国家重大科技专项工程

董振辉，男，工程师，从事航天器器载软件设计工作。Email：564760683@qq.com。

V446

A

10.3969/j.issn.1673-8748.2017.01.013