安全关键软件的非侵入式代码覆盖

商业航空电子设备的 DO-178B 等认证标准要求有证据表明系统源代码完全通过源自需求的测试来执行。传统工具通过代码检测来获取覆盖率数据，但这会使分析变得复杂，因为被测试的代码并不是最终将执行的代码。

主机驻留两部分技术提供了一种高效且具有成本效益的替代解决方案：目标仿真器与非侵入式覆盖分析器相结合。模拟器不是解释器；相反，它将目标代码动态转换为本地主机指令。因此，测试套件通常比在实际目标硬件上执行得更快。覆盖分析器从从模拟器上的程序执行中检索到的对象分支信息中获取源覆盖数据，并执行符合最严格覆盖要求所需的任何附加分析。

简化目标平台的最终验证；它需要重新运行测试并显示结果与模拟器上的相同。这种方法完全支持 DO-178B 及其即将修订的 DO-178C 的所有级别的安全认证。

验证挑战

DO-178B 等安全认证标准中规定的一项主要验证活动是测试覆盖率分析，这涉及证明每个软件需求都得到满足，并表明基于需求的测试完全覆盖了源代码。覆盖率分析提出了几个问题：

· 插装：一种常见的方法是使用生成应用程序源代码的修改（插装）版本的工具，或者使用特殊开关编译应用程序以生成插装目标代码。添加的代码包含对适当日志记录函数的调用。但是，检测代码不是将在最终系统上运行的代码。要使用覆盖数据，开发人员必须证明它也适用于未检测的可执行文件。这不一定是一项简单的任务。

· 目标硬件：虽然最终的软硬件集成测试必须在实际部署的配置上进行，但在组件开发过程中需要目标板既昂贵又不方便。基于主机的解决方案更简单且更具成本效益。

· 源代码与对象覆盖率： DO-178B 要求源代码覆盖率，但覆盖率数据是根据执行程序计算得出的。在最高安全关键性（A 级）下，可能需要进行特殊分析来证明修改后的条件/决策覆盖率 （MC/DC）。

此处描述的技术解决了这些问题。它基于从运行未检测版本的应用程序软件的主机驻留目标仿真器生成的执行跟踪数据中获取源覆盖率指标。

DO-178B 测试覆盖率分析

DO-178B 规定了两种类型的测试覆盖分析 ［1， §6.4.4］：

· 基于需求的测试覆盖分析：开发人员必须展示从每个需求到实现需求的源代码以及测试套件的可追溯性，该套件的执行提供了正确实现需求的信心。

· 结构覆盖分析：开发人员必须证明代码结构已经完全通过基于需求的测试。如果这些测试没有完全覆盖源代码，那么开发人员必须添加更多需求、添加更多测试和/或删除代码——称为“死代码”（DO-178B）或“无关代码”代码”（DO-178C）——不能追溯到需求。

所需覆盖范围取决于软件组件的安全关键级别。在 C 级，只需要声明覆盖率；即程序中的每条语句必须至少执行一次。

在 B 级，需要决策覆盖。在 DO-178B 用语中，决策是一个完整的布尔表达式，由原子布尔项（条件）和布尔运算符组成。例如，以下布尔表达式是具有三个条件的决策：

（B1然后B2）或者B3

此示例使用 Ada和 then和或 else短路形式，仅在必要时评估其右操作数，分别对应于 && 和 || C 中的运算符。决策覆盖要求程序中的每个决策都通过真假测试来执行。

在 A 级，需要 MC/DC：

· 程序中的每个条件都必须通过真假测试来执行。

· 程序中的每一个决定都必须经过真假测试。

· 必须证明每个条件独立地影响决策的结果（该条件变化，而所有其他条件保持不变）。

MC/DC 并不要求每个决策都使用其构成条件的每个可能的真值组合进行测试。这对于复杂的决策是不现实的，并且在条件耦合时（当相同的输入变量出现在多个条件中时）可能是不可能的。

图 1 显示了一个程序片段，说明了各种结构覆盖之间的差异。MC/DC 具有一些微妙的特征，在 Hayhurst等人［2］ 的教程和Chilenski ［3］ 的详细研究中进行了全面讨论。

图 1：程序片段显示了不同种类的 DO-178B 结构覆盖。

源与对象覆盖

DO-178B 中一个通常被误解的要求涉及必须在 A 级证明的覆盖类型（源代码与目标代码）。第 6.4.4.2 节指出：

可以对源代码执行结构覆盖分析，除非软件级别为 A 并且编译器生成的目标代码不能直接追溯到源代码语句。然后，应该对目标代码执行额外的验证，以建立这些生成的代码序列的正确性。目标代码中编译器生成的数组绑定检查是不能直接追溯到源代码的目标代码示例。

这一要求（其措辞在 DO-178C 中正在修订）并不是说必须为 A 级证明对象覆盖。相反，它解决了源语言构造的问题，其编译的目标代码包含条件分支或从源代码。在这种情况下，开发人员必须验证生成的代码，例如通过解释每个不可追踪的目标代码序列的效果。但是覆盖分析仍然必须与源代码结构相关。仅显示目标代码覆盖率是不够的，除非进一步分析可以证明其与源代码覆盖率等价。

通过虚拟化进行目标仿真

在主机系统上模拟目标处理器的概念并不新鲜，但虚拟化技术的最新进展催生了一种高效且可移植的方法，例如开源 Quick EMUlator （QEMU） 工具。QEMU 支持客户操作系统的完整系统仿真，并允许通过机器描述模拟特定的嵌入式设备。它在主机平台上运行，并在一个两阶段的过程中，使用缓存方案将目标代码动态转换为本地主机指令以提高效率。该工具首先将目标代码翻译成中间语言，然后将中间表示编译成主机二进制指令。

动态翻译器一次对未插桩的目标代码段进行操作，将翻译（或高速缓存提取）与翻译后的指令的执行交错。当 QEMU 开始处理一段目标代码时，它会将指令转换为宿主代码，直到它到达下一个分支。翻译后的目标代码（称为翻译块）存储在缓存中（如果尚未存在），并执行其相应的主机指令。QEMU 然后继续翻译它停止的地方。由于缓存，目标指令块只需要解码一次。在实践中，由于主机处理器通常比嵌入式目标硬件更快，QEMU 的虚拟化方法提供了比直接在目标上执行更好的性能。

QEMU 是可以扩展以提供附加功能的开源技术。为了处理 DO-178B 要求的结构覆盖分析，一个有用的增强是支持生成执行跟踪。两种跟踪信息是相关的：

· 摘要跟踪：输出标识已执行指令的地址范围，以及对于条件分支，哪些分支被（被）采用。输出数据的大小是有限的（实际上与目标程序大小呈线性关系），因为它只显示执行了哪些指令/分支，而不是整个执行历史。

· 指定地址范围的完整历史跟踪：除了指示已执行的指令外，输出还显示了在每次评估相关条件表达式时采用了哪个分支。输出数据的大小取决于执行历史。

生成这些执行跟踪的 QEMU 的改编版本是覆盖分析技术的关键组成部分。

覆盖分析

尽管执行跟踪数据提供了对象指令覆盖率和对象分支覆盖率信息，但仍需要进一步分析以满足 DO-178B 的覆盖率目标：

· 跟踪必须映射到源代码结构，尤其是源代码中具有覆盖要求的结构（语句、决策、条件）。

· 必须评估所达到的覆盖水平——声明、决定、MC/DC。

为了启用这种分析，编译器可以在对象控制流图中保留源程序的决策结构并生成两种输出：

· 调试信息（DWARF），它将每个目标代码指令与源代码位置（文件、行、列）相关联。

· Source Coverage Obligations （SCO），它提供了计划结构的简洁表示，需要证明实现某些覆盖目标的证据。SCO 捕获程序中所有决策的结构。

使用来自仿真器的跟踪数据以及编译器提供的 DWARF 和 SCO 信息，覆盖分析工具可以推断测试的执行是否达到了所需的覆盖级别（语句、决策、MC/DC）。

确定执行跟踪数据是否暗示 MC/DC 存在一些挑战。一个问题是如何从对象分支覆盖范围推断源条件评估。如果程序统一使用短路形式（“然后”、“或其他”）而不是非短路运算符（“和”、“或”），则可以处理此问题。根据选项的指示，编译器在生成的目标代码中保留源代码的条件结构。第二个问题是，出于效率原因，是否可以仅使用摘要跟踪而不使用完整的历史跟踪。一般来说，答案是“不”，一个相对简单的决定说明了原因：

（B1然后B2）或者B3

该决策的目标代码可以仅由三个测试用例覆盖，如表 1 所示。

表 1：（B1 和 B2）或 B3 的对象分支覆盖测试。

但是，当有n 个独立条件时， MC/DC 至少需要n+1次测试，因此这里需要进行 4 次（再次参见图 1）。这意味着跟踪摘要数据（对象分支覆盖率）是不够的；需要完整的历史跟踪数据。Bordin等人和 Comar等人［7］给出了何时对象分支覆盖足以推断 MC/DC 的数学表征。

当提出目标代码覆盖率作为 MC/DC 的证据时要解决的其他问题记录在多个认证机构报告中［8，第 20 节］。

把它们放在一起

目标虚拟化方法已作为 Couverture （Coverage） 项目 的一部分实施，旨在为安全关键型软件开发的覆盖分析提供一个开放框架。AdaCore 的 GNATemulator 工具是对 QEMU 的改编，用于收集执行跟踪数据。GNAT 编译器编译带有开关的应用程序源程序，这些开关保留目标代码中的条件控制流并生成 DWARF 和 SCO 数据。然后在 GNATemulator 上运行未检测的可执行文件，生成执行跟踪数据。使用编译器和仿真器生成的信息，GNATcoverage 工具评估是否已实现所需的结构覆盖。如有必要，该工具会分析完整的历史跟踪数据以验证 MC/DC。图 2 描述了一个典型的开发场景。

图 2：虚拟化和覆盖分析准确评估结构覆盖。

这些工具目前适用于用 Ada 编写的应用程序，Ada 是一种在安全关键领域中经常使用的语言。未来版本将支持其他语言，包括 C。目前支持的目标架构包括 PowerPC 和 LEON。

高效的目标虚拟化，再加上一个从执行跟踪数据中推断出精确的源级覆盖率指标的工具，用于非仪器化/未修改的用户程序，标志着现有技术的进步。该技术在安全关键环境中特别有价值，支持各级安全认证，同时简化认证工作。

审核编辑：郭婷