软件故障注入方法-电子工程专辑

软件故障注入方法

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

摘要

软件故障注入是功能安全验证的重要技术手段。本文旨在为软件故障注入提供一个基本概述，以及简介现有的故障注入技术。

故障注入方法简介

在功能安全相关关键场景中，密集的测试活动对于确保新系统和内置容错机制按预期运行至关重要。确保系统在出现故障时正常运行（Fail Operational）是一个需要比传统测试内容复杂的问题。在系统中引入故障以评估其行为并测量容错机制的效率（即覆盖率和延迟）的过程称为故障注入。

故障注入方法的发展是随着数字化的发展同步进行的。

最开始，数字系统只使用了简单的硬件系统。因此，第一种故障注入方法包括通过假设简单的硬件故障模型（如位翻转或位卡死）将物理故障注入目标系统硬件（例如，使用辐射、引脚电平、电源干扰等）。

硬件的日益复杂使这些物理方法的使用变得相当困难，甚至不可能，一个新的故障注入方法，即基于通过软件（软件实现的故障注入SWIFI）对硬件故障进行运行时仿真，变得非常流行。

随着关键系统在其他应用领域的扩展，我们看到这些系统的软件部分越来越复杂，这成为系统故障的一个不可忽视的原因。阿丽亚娜5号火箭的第一次试飞（1996年6月4日）就是一个例子。在试飞过程中，火箭偏离了飞行路线，在起飞后不到一分钟就发生了爆炸，造成了5亿美元的损失。爆炸是由软件中的错误数据转换引起的，从64位浮点到16位有符号整数表示。该漏洞源于对以往任务中软件子系统的重用，而没有进行实质性的重新测试，开发人员认为该任务与新系统兼容。

SWIFI工具用于在程序状态（例如，数据和地址寄存器、堆栈和堆内存）和程序代码（例如，在程序执行之前或期间存储代码的内存区域）中注入错误。不幸的是，在复杂的软件密集型系统中，通过SWIFI无法准确模拟真实软件故障的影响。因为在过去三十年中，汽车中使用的代码行的规模从数万行呈指数增长到数亿行。

与第一种故障注入方法相比，使用故障注入来模拟真实软件故障（即bug）的影响，即软件故障注入（SFI），是相对较新的方法。实际上，软件故障的注入包括在目标程序代码中引入小的更改，创建不同版本的程序（每个版本有一个注入的软件故障）。

ISO 26262标准规定了软件中错误检测和处理机制的使用，以及通过故障注入进行验证。

软件故障注入是一种假设实验，它可能起源于软件开发过程的任何阶段，包括需求分析、设计和编码活动。在给定的工作负载下执行目标，并将故障插入目标系统的特定软件组件中。主要目标是观察系统在存在注入故障的情况下的行为，考虑到这些故障会重现可能在运行期间影响系统给定软件组件的合理故障。

故障注入方法关键特性

故障是系统状态不正确的判定或假设的原因，称为错误。故障是在提供错误服务时发生的事件，即用户或外部系统感知到错误状态。

故障注入活动获得的结果的准确性在很大程度上取决于实验的几个关键特性，即：

代表性

是指故障负载和工作负载代表系统在运行期间将经历的真实故障和输入的能力。通过定义一个真实的故障模型，并在实验过程中准确再现该故障模型，可以实现故障的代表性。

非侵入性

要求故障注入过程中采用的仪器（如故障插入和数据收集）不应显著改变实际系统的行为。例如，执行额外的代码来破坏软件状态可能会导致侵入。

重复性

是指当在同一环境中使用同一程序多次执行故障注入活动时，可确保统计结果等效的特性。由于计算机系统中存在许多不确定性的来源，例如线程调度和事件计时，要实现这一特性并非易事。

实用性

是指故障注入在成本和时间方面的有效性。这些因素包括实现和设置故障注入环境所需的时间、执行实验的时间以及分析结果的时间。该属性要求实验由自动工具支持，以满足时间和预算限制。

可移植性

要求故障注入技术或工具能够轻松地应用于不同的系统，以便进行比较。故障注入工具的可移植性还指该工具支持多个故障模型并用新的故障模型进行扩展的能力。

软件故障特征

软件故障的注入需要对要注入的故障进行精确定义，这反过来又需要对软件故障进行清晰的理解和描述。这并不容易实现，因为软件故障是由于开发过程中发生的人为错误造成的，这些错误会以程序中错误指令的形式影响软件工件。

为了提高软件可靠性，人们提出了几种故障分类模式。在故障分类模式中，正交缺陷分类（Orthogonal Defect classification，ODC）是研究人员和实践者最广泛采用的模式之一，并已在多个研究中用于定义软件故障注入的故障模型。ODC是一个对软件故障进行分类的框架，目的是获得软件开发过程的度量和定量反馈；

软件故障注入技术

许多SFI技术和工具是在20多年的时间里发展起来的。这里，我们通过区分两种基本方法来说明和讨论这些工作：注入故障效应（也称为错误注入），其中通过扰动系统状态引入错误，以及注入实际故障，其中更改程序代码以模拟代码中的软件故障。以下小节分别回顾了软件故障注入技术：

· 数据错误注入的方法最早，这些方法基于当时存在的硬件故障注入技术；

· 接口错误注入方法，旨在测试组件与其他组件交互的稳健性；

· 注入实际故障的方法，在程序代码中引入小的故障更改。

4.1数据错误注入

早期注入故障效应的方法是在通过SWIFI研究硬件故障的背景下发展起来的。SWIFI旨在通过软件干扰内存或硬件寄存器的状态，再现硬件故障（如CPU、总线和内存故障）的影响（即错误）。根据以下标准，SWIFI方法将内存位置或寄存器的内容替换为损坏的值：

· 注入什么。内存位置或寄存器中单个位、字节或字的内容已损坏。通过对电气或门级故障产生的错误的分析，定义了错误类型。常见的错误类型是用固定值（卡在0和卡在1故障）或相反值（位翻转）替换位。

· 注入的地方。由于内存位置众多，注入内存的错误通常针对位置的子集。注入可以集中在特定内存区域中随机选择的位置（例如堆栈、堆、全局数据）或用户选择的位置（例如内存中的特定变量）。在寄存器中注入的错误可以针对那些可以通过软件访问的寄存器（例如，数据和地址寄存器）。

· 何时注入。错误注入可能与时间或事件有关。在前一种情况下，在经过给定的实验时间后注入错误，该时间由用户或根据概率分布选择。在后一种情况下，当特定事件在执行期间发生时，例如在第一次访问或每次访问目标位置时，会注入错误。可以模拟三种类型的硬件故障，分别是瞬时故障（即偶然故障）、间歇性故障（即多次重复故障）和永久性故障。

值得注意的是，SWIFI工具注入的硬件错误可以在程序状态（例如，数据和地址寄存器、堆栈和堆内存）和程序代码（例如，在程序执行之前或执行期间存储代码的内存区域）中注入。这是软件故障注入的一个重要区别：程序状态中的损坏旨在反映软件故障的影响，即错误程序的执行导致的错误，例如错误的指针、标志或控制流，SWIFI工具可以直接引入此类错误；相反，程序代码中的故障旨在反映代码中的实际软件故障。

4.2 接口错误的注入

在输入参数处注入错误旨在模拟目标外部故障产生的影响，包括外部软件组件中软件故障的影响，并评估目标检测和处理损坏输入的能力。以类似的方式，输出值的损坏被用来模拟故障部件的输出，并可用于评估故障对系统其余部分的影响。

输入参数的故障可能会揭示目标的错误检测和恢复机制（例如，输入处理代码）的设计和实施中的缺陷。它通常在稳健性测试中采用，该测试评估“系统或组件在存在无效输入或压力环境条件下能够正确运行的程度”。应该注意的是，健壮性测试和接口错误注入的目标不同于功能测试技术，例如黑盒测试：健壮性测试旨在评估软件模块在面对无效输入时的健壮行为（例如，避免了进程崩溃，或产生了警告信号），它与目标的功能正确性无关。

接口错误注入可以通过两种方式执行。第一种方法基于链接到目标组件的测试驱动程序（例如，使用目标导出的API的程序），并通过提交无效输入来执行该程序。这种方法类似于单元测试，但在这种情况下，评估的是健壮性，而不是功能正确性。第二种方法包括拦截和破坏目标与系统其余部分之间的交互，即在调用目标组件时触发拦截器程序，并修改原始输入以引入损坏的输入。在这种情况下，目标组件将在集成目标的整个系统的上下文中进行测试。这种方法类似于SWIFI，因为流经系统的原始数据（在本例中为接口输入）被损坏的数据替换。

在接口错误注入实验中，在实验期间发生的几个输入参数和目标API的几个调用中，通常只有一个输入参数和一个调用被破坏。生成无效输入值的常用方法有三种：

· 模糊化：原始值被随机生成的值替换。

· 位翻转：通过反转原始值的一个或多个位的值来生成损坏的值。

· 基于数据类型的注入：原始值被替换为无效值，该值是根据被破坏的输入参数类型选择的，其中类型是从目标导出的API派生的。这种方法为每种数据类型定义了一个无效值池，这些值是从类型域的分析中选择的（例如，在C指针的情况下为“NULL”）。

4.3注入代码的更改

前面小节讨论的主要是通过使用SWIFI方法注入故障影响（即错误）来模拟软件故障。这些方法的一个公开问题是注入错误（如位翻转）的代表性，它不一定与软件故障产生的错误匹配。

为了解决代表性问题，最近对SFI的研究集中在程序代码中错误的注入（即代码更改）。即可以采用注入代码更改来模拟真实软件故障，因为注入的故障会产生与真实软件故障产生的错误和故障相似的错误和故障。一般可通过在进程的代码存储区或二进制可执行文件上应用SWIFI，在程序中注入错误。但要注意通过对这些程序进行彻底测试，需在有限的范围内注入软件故障，需要专门针对软件故障注入的工具和技术。

结论

在为系统选择方法时，应考虑所讨论的故障注入方法的特点。

错误注入通常用于评估单个组件的健壮性，并改进代码特定部分的错误处理。主要原因是，错误的注入允许对系统的特定部分进行实验，因为它可以评估错误对特定组件接口或程序变量的影响。事实上，错误注入不需要等待错误生成并传播到正在评估的程序状态的特定部分。此外，由于错误注入可以应用于单个组件，因此可以在软件验证的早期阶段执行。

相反，注入代码更改的目的是作为一个整体评估容错系统，并在备选设计选择之间进行定量评估和比较。代码更改更适合于这些目标，因为它们基于软件故障的代表性模型，并密切模拟故障软件的行为。这是定量评估和比较的一个重要要求，因为它们考虑了故障发生的相对概率，以反映系统在运行期间表现出的行为。这使得代码更改的注入更适合于软件验证的后期阶段，此时系统组件已经集成，开发人员的目标是评估系统在其运行寿命期间的预期容错性（以及衍生的度量，如可用性）。

作者：郑威，TÜV北德功能安全总监