自适应AUTOSAR系统安全评估（三）：ISO 26262背景下GNU/Linux的评估

专栏作者 2023-09-18

内容提要：此文为该连载系列的“第三”篇章，在之前的“连载（二）”中已经具体评估了Linux在安全关键环境中的适用性的相关工作。在本连载（三）中，我们将详细评估GNU/Linux作为ISO 26262背景下安全关键环境中自适应平台操作系统的适用性。

《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第三”篇章，在之前的“连载（二）”中已经具体评估了Linux在安全关键环境中的适用性的相关工作。在本连载（三）中，我们将详细评估GNU/Linux作为ISO 26262背景下安全关键环境中自适应平台操作系统的适用性。

4. ISO 26262背景下GNU/Linux的评估

本章旨在评估GNU/Linux作为ISO 26262背景下安全关键环境中自适应平台操作系统的适用性。虽然ISO 26262并未解决以这种方式使用开源开发软件的问题，但提出了一种拟议的方法，以符合ISO 26262定义的资质流程要求，从而评估GNU/Linux的引入。本章最后提出了已发现的差距，并讨论了在安全关键环境中采用GNU/Linux的进一步限制。

4.1 软件层面的产品开发

ISO 26262定义了开发安全关键系统时应考虑和满足的要求，以避免系统失效和随机硬件失效带来的风险。虽然本章的重点是在软件级别的系统开发过程中定义的需求，但目的是避免软件系统失效引起的风险——前提是软件引起的风险仅适用于系统故障，其中软件要么不符合其功能规范，要么其规范没有充分描述系统功能。

因此，区分ISO 26262定义的功能安全要求和功能要求非常重要，功能要求是专注于系统执行其指定功能的能力的特定应用要求。功能安全要求主要侧重于显著减少由于系统相对于其设计意图的失效或故障行为而导致的不合理风险。它们是根据执行危害分析和风险评估程序后定义的所需安全目标来识别的（如图7所示）。

根据安全生命周期，技术安全需求和系统设计规范启动软件开发过程，遵循V模型开发流程，如图13所示。它从形成软件架构设计的软件安全需求规范开始，旨在实现这些规范(6-7.1)。

图13：软件层面的V模型开发流程

在软件的架构设计过程中，根据需求以及重用软件组件提供预期功能的适用性，决定是新开发还是重用软件组件。因此，ISO 26262把每个安全相关的软件组件分为是新开发的、经修改后重用或未经修改而重用的(6-7.4.6)。对于经过修改的重用，ISO 26262将软件视为仍处于开发中，其开发过程必须根据标准获得合规性。这是因为引入的修改可能会导致软件在重用时影响其性质（功能、行为）的变化，因此必须重新评估其合规性。然而，由于其开源开发性质，重新评估GNU/Linux的整个开发过程是不可能的。因此，我们目的是通过应用ISO 26262定义的软件资格要求来评估GNU/Linux的重用，而无需引入修改。

为了提供重用软件对于安全相关应用的适用性的证据，ISO 26262在ISO 26262-8中定义了其他支持流程，应采用第12条定义的“软件组件鉴定”或第14条规定的“经使用验证”方法（6-7.4.8）。“经使用验证”论点适用于重复使用定义和条件与已发布软件相同或具有高度通用性的现有相关项（软件）的情况，并且在运行中。为了论证的有效性，需要提供在用证明数据—在ISO 26262中也称为在用证明信用—作为重复使用软件可靠安全运行的证据（8-14.4.2）。这些数据应包括配置管理文档、变更管理记录以及有关重用组件使用期间安全相关事件的相关现场数据。然而，基于“经使用验证”论点来论证GNU/Linux的能力是一种不明智的做法。首先，在安全关键应用中GNU/Linux运行的现场数据缺乏或不足，该论点完全依赖于这些数据作为可靠安全运行的证据。其次，由于论证要求对已发布并正在运行的单个特定软件进行监控，因此，由于错误修复或社区引入新版本软件而引起的任何更改都会对软件产生重大影响，并需要重新收集现场数据。对于像GNU/Linux这样的开源开发来说，这将非常耗时且非常不可行。

总而言之，尽管GNU/Linux广泛用于不同的应用程序，但经过使用证明的论点不足以证明其可以重用于安全关键型应用程序，在这些应用程序中，软件必须为其适用性提供更多保证。这可以通过应用ISO 26262-8第12条定义的鉴定流程来完成。资格要求将在下面的子章中讨论。

4.2 软件资质要求

在审查了“经使用验证”方法在开源软件开发中的不可行性后，ISO 26262-8第12条规定了对软件组件资格的某些要求，这些要求可以作为重用软件适用性的证据，它们要么是由第三方供应商作为商用现货（COTS）软件提供的，要么是未根据ISO 26262（8-12.2）开发的内部开发的软件组件。由于目的是评估GNU/Linux，而不因上述原因进行修改，在这种情况下，GNU/Linux可以被视为COTS，由社区作为第三方供应商提供。这开启了通过应用ISO 26262定义的软件资格要求来评估GNU/Linux适用性的可能性。

对于软件组件的认证，ISO 26262-8第12条定义了作为认证程序应遵守的以下要求：

1.软件组件的规范应可从外部来源获得，其中应包括：

a.软件需求指定功能需求、响应时间、资源使用和运行时环境

b.软件组件在发生失效和过载情况下的行为规范

c.软件组件配置、接口和集成的描述

d.与其他软件组件的依赖关系

e.异常运行条件下功能的反应

2.软件组件符合其要求的证据，根据ISO 26262-6第9条的验证程序应包括：

a.低于ASIL D级别的应用程序的需求覆盖率，主要基于需求的测试 (8-12.4.3.2)

b.ASIL D级别应用程序的需求覆盖率和结构覆盖率，用于评估测试用例的完整性并确保意外的功能 (8-12.4.3.3)

3.软件符合其预期用途的验证结果以及软件符合其使用需求的证据

4.组件的软件开发过程基于适当的国家或国际标准的证据

以上是ISO 26262-8第12条定义的软件资格的文字要求，在描述旨在满足GNU/Linux的这些要求的方法之前，值得一提的是，以下提案并不是声明GNU/Linux可以适用于所有情况，对安全关键应用程序没有任何限制。但是这对于在ISO 26262的背景下管理GNU/Linux来说是一个颇有说服性的理由—就像管理任何安全组件的情况一样。GNU/Linux使用的进一步限制将在第4.4节中单独讨论。

4.3 裁剪GNU/Linux的资格要求

ISO 26262没有明确解决开源软件开发(OSS)的重用问题，因此，正如ISO 26262 (8-12.4.1)所指出的，在重用现有软件的资格审查过程中，可以进行一些逆向思维和重新设计活动。下面描述的方法旨在提供一种定制方案，以使前面提到的要求与GNU/Linux相匹配。

正如前一子章节所提到的，软件资格的第一个要求—如第12条所定义，要求为重复使用的软件提供软件规范。重用软件组件的规范应解决软件需求的定义，这些软件需求是由开发人员定义的独立于应用的软件需求，描述功能需求、响应时间、资源使用和运行时环境。这些规范可以根据系统设计开发过程中确定的应用需求来交付。

另一方面，软件组件在发生失效和过载情况下的行为规范、其在异常运行条件下的反应以及其接口的描述，代表了安全使用GNU/Linux或任何其他软件组件的主要挑战。这只是因为对于开源软件开发，社区不一定在开发软件的文档中包含软件的行为规范。此外，在软件组件包含多个软件单元的情况下，说明书还应当包括对每个软件单元的配置的描述。然而，这对于GNU/Linux来说可能不容易实现，因为社区不提供每个软件单元的配置描述。

对于前面提到的挑战，GNU/Linux将被视为黑盒软件组件，而不知道其行为规范和软件单元配置描述。只要COTS组件的黑匣子行为规范提供了所有重要或相关的外部可见行为，以证明组件的危害行为不存在，或与系统的整体安全性极低相似性，就足够了。

下面提出的使GNU/Linux规范可用的方法是从OSADL小组所做的类似工作中采用的，该小组旨在对嵌入式GNU/Linux RTOS的基本组件进行认证。此外，西门子也开展了类似的工作，旨在为轨道交通项目的Linux验证提供验证流程。该方法执行以下步骤：

1. 将GNU/Linux视为黑匣子

2. 利用其与POSIX等其他标准的一致性

3. 运行已经可用的测试用例，例如POSIX测试套件

4. 分析结果及其与预期规格的相关性

5. 识别未涵盖的规范中缺失的差距

6. 创建或扩展测试用例以识别缺失的规范

为了使方法论符合AUTOSAR所规定的应用需求的初衷，其核心思想是利用符合POSIX应用程序编程接口标准的GNU/Linux。POSIX标准，特别是IEEE Std 1003.1，是IEEE委员会与Open Group合作定义的一系列标准化，专门描述了实时和嵌入式操作系统的运行环境。该标准旨在通过指定有关进程和线程管理、基本进程间通信（IPC）以及信号和中断处理程序的通用定义，实现不同操作系统之间的可移植性。当软件提供符合这些定义的证据时，这些定义可以用作软件的规范。可以通过运行社区创建的现有测试用例（例如POSIX测试套件）来授予合规性证据，通过该测试用例，测试结果可以确保软件实际上符合标准定义的声明规范。然后应对结果进行分析，以评估其与预期所需规格的相关性。最后，应确定测试套件未涵盖的所需规范，并相应地创建进一步的测试套件以涵盖ISO 26262为软件资格定义的所有所需规范。

为了更好地了解所执行的过程，下面给出了有关所有POSIX 1003.1声明的兼容操作系统的优先级调度机制的示例。标准规定，操作系统的FIFO（先进先出）调度策略控制着每个进程的执行优先级。通过函数sched_setparam()，将函数调用中指定的进程的优先级修改为参数实参指定的优先级。为了验证这一点，Open Group的实时测试套件（称为VSRT）提供了一个测试用例，用于测试SCHED_FIFO调度算法是否按照有关调度进程的计时和排序的指定运行。结果仅说明测试是否通过。如果测试通过，则可以使用SCHED_FIFO调度策略来描述GNU/Linux中进程的调度策略，从而进行相应的指定。如果测试失败，则GNU/Linux不支持SCHED_FIFO调度策略，因此应在相同的基础上执行进一步的测试，甚至在未提供时生成测试，以便测试并可能指定GNU/Linux的调度策略。

因此，这里的问题是，从标准规范中可以获得什么，也可以与ISO 26262的要求相匹配。此外，考虑到GNU/Linux不是一个完全符合POSIX的操作系统，操作系统是否真的完全符合这些非常精确的规范也是另一个问题。这种方法的这些限制和差距将在下一分章稍后讨论，但首先，让我们确定POSIX标准及其相应的测试套件可能涵盖的ISO 26262定义的规范要求是什么。

为了更好地说明这一点，下表描述了第12条定义的左侧ISO 26262规范要求、匹配要求的可能方法以及相应的验证流程：

表2：匹配ISO 26262定义的规范要求以适应GNU/Linux

如上表所述，重用软件组件的软件需求解决了依赖于应用程序的软件需求，例如功能需求的响应时间、资源使用和运行时环境，这些是由开发人员定义的特定于应用程序的需求，指定了软件的预期功能。这些规范是在系统设计的开发过程中确定的，例如某些任务的响应时间不应超过40ms，以满足50ms的设定周期。这可以通过已经存在的开源测试用例（例如POSIX实时测试套件扩展（VSRT））中采用的测试进行测试和验证，通过该测试可以验证实时信号、异步输入和输出、内存锁定和优先级调度符合预期的功能。如果现有测试用例未涵盖特定的软件需求，则必须生成进一步的测试用例以验证所有软件需求。

同样，可以在出现失效或过载情况下对行为规范进行处理，其中可以应用Open POSIX压力测试套件，该套件通过使用大量系统对象或大量数据为软件创建压力情况，或者通过将软件置于外部条件下，例如低存储器或高CPU利用率。

同样，GNU/Linux的接口描述可以通过其符合POSIX标准来获得，该标准定义了进程和线程管理、基本进程间通信（IPC）以及信号和中断处理程序，这可以通过运行POSIX线程测试套件（VSTH）和Open POSIX功能测试套件来再次验证。此外，为了识别软件功能在异常操作条件下的反应，可以应用Linux测试项目（LTP）提供的测试用例；它们是专门为改进和验证Linux内核的可靠性、健壮性和稳定性而设计的。必须记录先前运行的测试用例的结果，并根据ISO 26262-6第9条生成可追溯性报告，作为软件单元测试验证程序的一部分，以跟踪软件单元级别上软件的功能要求和安全要求的实现情况。

在V型模型开发过程之后，为了完成ISO 26262（12.4.3.1）定义的表中提到的规范要求的匹配，软件组件集成描述可以从软件架构设计文档的工作产品中得出，其可以通过根据ISO 26262-6的第10条执行软件集成测试程序来验证。类似地，由于软件与其他软件组件规范的依赖性也是依赖于应用的规范，这些规范在软件架构设计过程中根据预期应用进行记录，可以通过软件集成测试程序使它们可用并进行验证，以证明形成特定软件体系架构设计的软件依赖性的实现。

话虽这么说，在V模型的这个级别上，讨论了集成测试程序来验证不同软件组件的软件依赖性的实现，确保不同软件组件之间的安全交互也很重要。虽然假设ASIL B是应用程序可以达到的最高完整性级别；这是由于硬件受到限制，无法提供所需的高完整性处理能力。由于高度复杂性和极端的开发工作，将整个软件堆栈开发到如此高的完整性水平也非常困难，因此只需要实现软件分区机制。这创建了一个混合关键性系统，将不同的安全完整性级别分配给不同的软件组件。因此，必须实现不同安全完整性级别的软件组件之间的安全共存。这种安全共存可以通过应用进一步的安全措施来避免或控制影响安全相关软件的系统失效的发生，从而实现不受干扰（参见ISO 26262-6附录D）。这些措施实施了检测或避免干扰的安全机制，以实现容错系统。安全机制的实现将在实现章节中进行彻底讨论，其中使用实际用例演示容错技术，该用例超越了简单的Hello World应用程序以实现免受干扰。根据ISO 26262-6第10条，这些安全机制将在软件安全要求的验证过程中再次得到验证。

最后，如果没有社区参与创建错误报告来帮助识别已知异常，并描述通过某种持有开源理念的通用平台来改进Linux的解决方法，这一切都是不可能完成的。然而，事情并不像听起来那么容易，这种方法的一些缺点值得一提，并将在下一子章节中讨论以及进一步的限制。

4.4 限制

尽管前面描述的方法过于笼统，无法声称任何OSS或特别是GNU/Linux都适合安全关键应用程序，但可以生成足够的证据来适当使用它。尽管这些证据的生成是主要挑战，但考虑到记录GNU/Linux规范的时间和任务的复杂性，还应考虑以下进一步的限制（缺点）：

(1)由于并非GNU/Linux的所有功能都可以通过POSIX标准驱动或引用，因此GNU/Linux不是完全符合POSIX标准的操作系统，这就需要采取变通措施来指定和验证这些功能。这些措施必须包括识别操作系统使用的可通过POSIX标准驱动的每个功能，并通过相应的可用测试用例对其进行测试和验证。此外，如果未验证未使用的功能，应利用内核整体性将其停用，以减少验证工作。这还需要更深入地了解软件的内部结构，例如线程如何通信和交互；以免影响操作系统的预期功能，从而再次导致非常复杂且细节的任务。

(2)可用测试用例的覆盖范围也需要进一步调查，例如，并非所有提到的测试套件都是完整的（彻底的），例如Open POSIX压力测试套件。除此之外，并非所有测试用例都可以直接追溯到GNU/Linux行为规范—这意味着必须生成扩展测试用例才能识别和验证GNU/Linux的所有预期规范。

(3)此外，通过运行测试用例的结果定义软件规范，会提出这样的问题：应如何记录这些规范以及它们应满足哪些质量标准，以便将结果可靠地映射到预期规格。

(4)尽管如此，假设已成功指定GNU/Linux的所有使用功能—所执行的验证程序仅对软件组件未更改的实现有效，这意味着所执行的鉴定程序的结果仅可信于GNU/Linux的特定版本。如果社区引入较新版本的软件，则必须重复验证程序，以便为成功的资格认证提供充分的证据。最后，应该为开源软件开发找到一个通用的资格认证程序，在引入新版本软件的情况下，只需要小的适应性调整就可以使资格鉴定程序有效，以确保其成功重用。

图14：Linux组件架构

放松这些限制的一种可能方法是根据依赖这些功能的每个应用程序的失效特征，对操作系统进行功能失效分析(FFA)。如果应用程序要提供预期的功能，这仍然需要确定操作系统必须提供的一组功能，以识别特定的失效点，以便采取进一步的安全措施来实现所需的安全状态。然而，这让我们重新完全理解了软件的内部结构及其内核函数调用，这推翻了前面所说的黑盒方法。

前面提到过，在安全关键型应用程序中使用GNU/Linux的另一个主要限制是Linux单片内核架构，如图14所示，其中设备驱动程序和其他内核模块由内核在同一地址空间中集成和执行。当将数据从内核空间写入用户空间时，设备驱动程序可能会损坏内存。因此，作为操作系统的核心组件，它们必须提供某种关于其完整性的保证。这将要求设备驱动程序模块继承相邻模块的ASIL—这是它无法实现的。这与QNX等所谓的微内核操作系统形成鲜明对比，其内核服务是分离的，并位于微内核架构的不同层中。因此，在这种情况下，设备驱动程序不一定需要提供如此高水平的完整性。

最后，必须提供进一步的证据来证明系统失效时的异常运行条件，而不仅仅是函数调用失败，软件必须接受进一步的监控以检测内核崩溃、内存泄漏和驱动程序不当行为。针对这些所描述的约束的可能方法将在后续连载中介绍。

更多内容，请关注“自适应AUTOSAR系统安全评估（四）：在Linux中实现软件安全机制”，关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。