内容提要：此文为该连载系列的“第二”篇章，在之前的“连载（一）”中已经介绍了相关问题描述、范围及方法论，并具体阐述了本专题连载感兴趣的基本技术主题。接下来，在连载（二）中，我们将具体评估Linux在安全关键环境中的适用性的相关工作。

《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第二”篇章，在之前的“连载（一）”中已经介绍了相关问题描述、范围及方法论，并具体阐述了本专题连载感兴趣的基本技术主题。接下来，在连载（二）中，我们将具体评估Linux在安全关键环境中的适用性的相关工作。

3. 最先进的技术

本章涵盖了旨在评估Linux在安全关键环境中的适用性的相关工作，首先概述了与安全标准相关的安全关键应用程序中软件重用的主要挑战。然后，研究了克服已确定的挑战的不同方法，以将COTS软件用作操作系统，并进一步研究GNU/Linux的引入。最后，探讨了软件安全机制的实现，以在安全关键型应用中适当使用GNU/Linux。

3.1 软件和安全标准的重用

最近，汽车行业对软件重用的需求不断增加，目的是降低开发成本和时间，从而缩短上市时间并提高最终产品的质量。在安全关键系统中，质量的提高应该会带来更可靠的系统，而更短的上市时间应该会带来更高的生产力；这是任何安全关键系统的主要目标。

然而，在安全关键系统中引入重用软件—被视为商用现成 (COTS) 软件—带来了新的挑战，很难证明系统实际上足够安全。这仅仅是因为很难保证所使用的组件满足其开发过程要求，从而满足其预期应用的安全要求。特别是，当COTS用作黑盒组件时(这是大多数情况)；用户/购买者可以获得的有关其行为规范的信息非常少。因此，安全标准通过设定严格的要求，允许COTS在安全关键环境中运行，限制了COTS在安全关键应用中的使用。事实上，很少有标准隐含地解决COTS的使用问题，并明确以这种方式使用开源开发的软件，例如ISO 26262，这为软件安全工程师在如何定制指定的要求以使其匹配的问题上造成了差距。在安全关键环境中使用开源软件。这仅仅是因为安全标准是以灵活的方式设计的，以适应新兴技术，同时仍然能够保留其基本概念。此外，大多数标准都是基于目标的，这意味着它们没有指定实现符合已定义要求的方法，而是指定了预期目标，并对如何实现这些目标保持相对开放的态度。以下子章节研究了与COTS（特别是安全关键环境中的OSS）重用相关的潜在问题和建议的解决方案。

3.2 COTS软件在安全关键应用中的使用

为了解决在高度确定性的安全关键应用中使用COTS的困境，Skramstad-Torbjorn提出了以下建议：(1)人们可以简单地实现经过认证的COTS，如VxWorks或OSE，但它们可能成本非常高，并且仍然需要进一步评估来检查COTS认证的环境，这违背了降低软件重用的开发成本和时间的目标。(2)将系统的确定性建立在从现场收集的统计数据的基础上。这被称为“经使用验证”方法，但事实证明这几乎不可能，因为它需要多年的无故障运行才能认证SIL2应用程序。(3)对已实施的COTS执行详尽的测试和验证流程，以提供有关系统安全运行的预期程度的保证。(4)实施隔离和保护机制，使系统减少失效的发生并保持可接受的安全状态。第3点和第4点是本专题的重点，将分别在后续连载中的第4章和第5章中详细讨论。

然而，在进一步讨论之前，了解执行功能安全评估流程的重要性非常重要，以便在安全关键应用中成功实施COTS。因为这将有助于在早期阶段确定对潜在使用的COTS的安全要求，从而可以相应地定义已实施的COTS的预期用途，从而成功选择COTS。此外，如果有意的话，在早期阶段考虑安全问题将有助于COTS产品的成功集成过程，并简化最终系统的认证程序。这将有助于克服在选择合适的COTS产品以成功实施COTS的过程中定义的挑战，这些挑战如下：

1.识别并记录预期COTS功能的安全要求。

2.根据安全要求定义一套评估标准。

3.根据已定义的评估指标对系统安全的相对重要性进行优先排序。

4.通过执行验证过程来识别收集到的证据的相关性，从而对结论进行论证。

他们还建议根据安全要求而不是功能要求来选择流程—考虑到如果COTS 未能满足定义的安全要求而需要重复安全评估所需的时间和资源。确定COTS的预期用途同样重要，因此COTS的评估高度依赖于其实施环境。如Nancy G.Leveson所述，如果要实施的组件没有影响系统安全临界性（不是高临界性），但存在于安全关键环境中，则评估应侧重于保证其重要性。另一方面，如果要实施的组件是关键的，这意味着它与安全关键功能相互作用，可能会造成危害，那么目标应该是使用前面提到的系统设计技术，如冗余、监控和包装，来减轻或避免这种失效。而对于第三种情况，当COTS组件正在实现安全关键功能时，实现针对该组件任何潜在行为的保护机制是不够的。因此，必须有足够的信息，以便执行充分的系统危害分析，从而能够确定其在所设计的系统中的使用是否满足所描述的安全要求。

同样，软件可能非常可靠—满足其功能要求，但仍然不安全。事实上，该软件可以满足其预期用途所需的所有要求，但仍然以危害系统安全的危险方式运行。指定的需求还可能缺少软件的特定或非预期行为，这对于系统的安全性具有重要意义。因此，标准建议不仅要对软件的开发过程进行全面的评估，还要通过彻底的测试和验证程序对软件的行为进行进一步的评估，以提供足够的确定性，确保COTS组件可以或正在保护系统免受任何潜在的不安全行为的影响。然而，确保COTS组件提供系统所需的可行可接受风险的保证是一项关键任务，尤其是对于尚未在内部开发的产品而言。

为了确定系统可接受的风险，系统必须进行系统危害分析(SHA)，以便：

1.确定软件组件中的失效如何导致或促成危害失效模式。

2.如果可能的话，从系统设计中消除危险，或者如果使用标准系统工程技术无法消除危险，则至少进行限制。

3.识别并解决设计目标与安全相关设计约束之间的冲突。

“由于所有与软件相关的危害事件都涉及系统性失效，并且基于系统危害分析只涉及外部行为，理论上，软件的黑盒规范足以执行详尽的SHA。只要黑盒的行为符合规范，内部组件的设计并不相关。”COTS组件行为的黑盒行为规范必须指定所有重要或相关的外部可见行为，以提供足够的信心，确保组件的危害行为不存在或与系统安全性的相关度极低。此外，软件的黑盒子行为规范将允许理解其适当性和能力，以充分满足预期应用的安全完整性要求。

然而，这里的主要挑战在于如何获得潜在COTS的行为规范，尤其是在大多数情况下，人们对已实现的COTS的开发过程和内部结构知之甚少；供应商也无意随软件提供此类规范。理论上，软件的规范可以通过广泛的测试、验证和检查流程来获得；这不是一项简单的任务，特别是对于像操作系统这样的复杂组件来说，这可能会导致创建此类规范的成本非常高或不切实际。这种方法将在后续连载中的第4章进行更详细的评估，其中提出了一种关于如何解决（克服）这一困境及其已确定的缺点和局限性的方法。

在此基础上，有相关研究在确定要评估的关键标准，以评估操作系统在安全关键环境中的适用性，并通过提供以下证据进行论证：

1.必须足够准确地了解操作系统的行为，操作系统的预期行为与实际行为之间的任何不匹配都可能导致安全相关应用程序的危害行为。

2.操作系统的行为必须适合安全相关应用程序的特征。换句话说，操作系统必须提供与预期安全相关应用程序的特征相匹配的所需行为。

3.操作系统必须足够可靠，以满足应用程序的安全完整性要求，其中发生失效的可能性必须足够低。

应通过执行涵盖操作系统以下行为特征的分析来评估所有三个标准：调度、资源管理、内部-外部通信、活力、分区、实时、安全性、用户界面、稳健性和安装。这将允许对应用程序和操作系统之间的交互进行充分的危害分析。因此，请确保操作系统的使用不会在应用程序级别引入任何新的危害事件。因此，该报告认为，作为黑盒实现的COTS操作系统（无法获得软件源代码和设计信息）可以达到的最高完整性级别是IEC 61508背景下的SIL 1。进一步认为，如果根据执行的系统安全评估实施保护和分区机制，则可以实现SIL 2。

遵循这些标准，有人提出了一种实现方法，其目的是通过限制组件对其余部分的影响，在高完整性设计中实现低完整性COTS组件功能。这是通过首先对可能导致或促成系统危害失效模式的操作系统的安全功能进行危害分析来实现的，并基于开发的安全相关代码来保护系统免受可能影响系统安全的已识别失效的影响——实现了预期安全。并在列车控制系统来实施，该系统包括列车控制系统(TCS)以及分别SIL 0和SIL 2的监视器显示，两者都在同一个COTS操作系统上与单独的安全关键计算机一起执行。基于SIL 4的接口，负责联锁轨旁基础设施。COTS操作系统是Microsoft Windows XP PC。显示单元负责验证TCS发出的联锁请求，然后将其实际发送到基于计算机的联锁系统；因此需要达到SIL 2或更高等级。

因此，基于前面提到的方法，针对SIL 0和SIL 2功能之间的干扰确定了五种危害及其原因，从而定义了为实现安全内核的SIL 2，而需要实施的九项安全要求遵循EN 50128标准。通过基于故障树分析满足这些安全要求，可以证明所识别的安全内核的完整性符合EN 50128 SIL 2要求。

当然，还存在一些局限性和问题，其中之一是缺乏失效安全状态操作。对于安全关键应用来说，这是一项至关重要的要求，以保证处于不存在任何不合理风险水平且不会造成任何危害的状态。此外，组件之间的交互受到交换数据量的严重限制，如果要交换丰富的数据，则应对COTS失效模式进行进一步分析。此外，其实施高度依赖于人为因素作为检测系统失效并正确执行操作的证实（确认）机制。然而，这在某种程度上降低了系统按预期运行的可靠性。除此之外，在引入操作系统配置或防病毒保护系统的更改时面临的限制，因为这将需要重新评估系统以确保它们不会影响内核的安全性。影响操作系统的调度并中断正在执行的进程。虽然之前所有的努力都集中在描述安全关键应用中使用COTS的挑战，但很少致力于遵循特定标准并满足（讨论和）要求。这是后续连载中第4章的重点，其中将详细讨论ISO 26262背景下重用软件的资格要求，目的是使它们适合安全关键环境中GNU/Linux的实现。此外，正如结论，如果根据执行的系统安全评估来实施保护和分区机制，COTS操作系统可以获得更高的完整性级别。这些机制是第3.4节的重点；但首先，将GNU/Linux引入安全关键环境的相关工作将在下面的子章中介绍。

3.3 GNU/Linux在安全关键应用中的使用

在评估GNU/Linux对于安全关键环境的适用性时，前面提到的使用COTS的挑战也同样存在。然而，开源软件被认为更适合（更有资格）接受确认和验证程序，旨在为其适用性提供所需的证据。这仅仅是因为该软件的源代码和某些规范可以被公众获取和验证。尽管如此，重要的是要认识到使用开源软件是一个基本决定，必须在项目生命周期的早期阶段考虑，不仅要考虑前面提到的要点，还要考虑其开源本质—基于OSS的项目是否成功。

有人做了研究，首先提供了有关GNU/Linux在系统规模和系统复杂性方面的适用性的证据，论证了GNU/Linux在IEC 61508背景下的适用性。他的理由基于社区遵循的严格文档级别及其广泛的平台支持，这反过来使软件的大小可追踪和可管理，特别是在引入GIT之后。他们进一步讨论了内核软件生命周期的进步、Linux内核版本2.6中引入的元素的高级管理，以及通过3000多个可用测试用例测试和确认Linux 内核的不断增长的平台。尽管引入的这些进步并不是为了使Linux适应安全关键应用程序，但它们无疑为建设性和有组织的开发过程提供了良好的证明，该过程遵循有关源管理和软件修改的严格规则。最后，他们提出了几种可能的方法，将GNU/Linux集成到61508的上下文中，其中相关的方法如下：

1.为纳米内核构建符合61508标准的程序安全案例，该纳米内核将GNU/Linux作为其（用户空间）任务之一运行，在纳米内核的直接控制下运行安全关键应用程序。

--->然而，这是一种非常受限的方法，它不能免除指定纳米内核行为的必要性，也不能免除执行功能安全评估以确定系统满足所需安全级别的能力;导致GNU/Linux没有安全责任，并且整个系统是SIL 0。

2.遵循61508-6附录E，通过将61508的要求映射到纳米内核来关注操作系统层的多样性，并提供GNU/Linux作为通用操作系统(GPOS)的全部优势，以进行维护非安全相关的任务。

--->虽然这可能很实用，但它并没有实现让Linux负责安全相关任务的目的，也没有为GNU/Linux的行为提供足够的保证。

3.建立一个符合61508标准的COTS论点，这将在很大程度上基于“经使用验证”的方法。

--->但是，有人认为，根据“Linux的使用如此之多”的现场数据来论证是“天真的”，这不仅是因为没有一个是安全相关系统，而且还因为该论点需要多年的无故障运行才能认证为SIL2应用程序。

此外，如何实现这些方法的详细流程也不是很清楚，因为它们只是为了粗略地了解可能的方向，而不是满足（履行）61508定义的要求所需的确切程序。必须提供关于挑战、所需安全措施和将面临的限制的更详细的信息。

这是开源自动化开发实验室(OSADL)的主要目标之一，其目标是通过遵守所需的法律要求、安全和防护标准，使开源软件可持续用于工业用途。他们的主要项目之一是SIL2LinuxMP，旨在创建程序和文档，以促进基于Linux的产品的安全认证。

在他们的网站上，他们提出引入一种新的发展策略，称为“合规-非合规发展”，通过该策略“将收集所采用的开发和合规开发之间某种等价性的论据，并在需要时制定补充这些论据的方法。此外，系统将接受特定测试，以补充无法获得足够证据证明标准符合性的领域。”他们表示，这将是SIL2LinuxMP认证策略。

作为他们工作的一部分，他们描述了一种开发策略，该策略结合了现有软件的方法和上下文外安全元素（SEooC），利用GNU/Linux符合POSIX标准规范来定义软件的要求和规范。该策略已在后续连载的第4章中进行了调查、完善和解决，目的是使ISO 26262定义的软件资格要求适合GNU/Linux。

此外，他们还支持SIL4linux项目所做的工作，该项目旨在探索构建满足SIL 4完整性要求的Linux系统的可用方法。所执行的方法涉及集成一些内核跟踪/分析工具来支持正式分析系统并创建所需的报告，为Linux在安全关键环境中的适用性提供证据。基于系统限制，包括运行特定应用程序、固定系统调用和固定内核函数；该系统通过ctags和ftrace等正式工具进行跟踪和分析。此外，可以通过其他分析工具（例如kgcov和gcov）监视和分析内核函数中最常执行的行或块。通过这些工具，收集所需的数据（包括系统调用、内核函数、系统调用的调用树和内核函数的代码块），并将其传递到数据库，数据库保存数据并能够通过结构化查询语言和一个接口，用于缓冲数据并创建跟踪结果，例如最大时间、平均时间等。因此，根据收集的数据和分析方法，生成失效模式和影响分析(FMEA)和故障树分析(FTA)等报告，作为满足SIL4要求的可能性的证据。该项目方法的结构如下图9所示。

当然，由于其复杂性，监控整个Linux内核听起来是不可能的，然而，这里的想法是找出出现频率较高的代表性树，并将它们与某个具有特定功能的应用程序相匹配。因此，允许通过运行特定的测试套件（例如POSIX测试套件）来覆盖和测试这些特定的树或系统调用。

图9：SIL4linux架构

该策略可以通过查找和收集有关内核性质、其行为以及任何系统失效是否存在的关键数据来帮助改进Linux。然而，一些文章讨论的结果并未说明该方法是否真正满足或符合SIL4定义的标准。

另一方面，像ftrace这样的工具的使用，引入了如何跟踪特定内核函数并跟踪其执行周期的想法。这是后续连载中第6章用来验证所实现的软件分区机制的策略。在下一连载篇章中，将评估有关不同软件分区机制的相关工作，以适应GNU/Linux的实现；命名实施的机制。

3.4 软件安全机制

软件安全机制旨在实施解决方案来检测或避免失效，以实现或维持所需的安全状态。例如，安全状态可以是正常/预期操作、降级操作甚至关闭系统，具体取决于错误/失效的类型，旨在实现没有任何不合理风险级别的失效安全系统。容错系统是一种能够检测错误发生或能够通过转换到指定的安全状态来恢复错误而不会发生故障和/或造成任何危害的系统。这是经典的方法。然而，随着高安全关键系统可靠性的增加，需要实现更高的鲁棒性和可用性，而失效安全操作模式是不够的。因此，必须执行进一步的机制，以避免/减轻失效的发生。这些机制可能包括故障避免和故障消除技术，它们共同旨在实现无故障系统。所有机制以递归方式组合对于为安全操作提供高水平的保证是必要的，因为所有机制都是不完善的。

软件失效是指元件无法执行所需/指定的功能，可能是由非安全相关元件影响安全相关元件导致其故障造成的。因此，对于功能安全概念来说，重要的是要遇到安全相关和非安全相关元素的相互作用，以避免任何可能导致违反安全要求的不良干扰。这在ISO 262626的上下文中称为不受干扰。同样，可以通过考虑所需的安全措施（特别是软件安全机制）来避免或检测此类干扰，这些安全措施可以实现或维持系统所需的安全状态。

本专题连载的重点是基于分区或虚拟化技术的软件安全机制的实现，旨在通过安全管理不同应用程序之间的资源来实现免干扰。这也可以通过避免或检测此类干扰来实现，这在不同关键性的组件之间至关重要。这些技术包括：

·Hypervisor方法

通过引入位于硬件层之上的嵌入式虚拟化层，为在其之上运行的不同操作系统虚拟出一个完整独立的硬件平台，将允许每个操作系统在其自己的隔离分区中安全地运行，同时调节每个操作系统的资源访问。

图10：Hypervisor 层架构实现

这种架构设计在工业控制系统中众所周知，因为它允许两个不同的操作系统共存，而不会干扰另一个操作系统的资源使用。例如，RTOS控制时间关键型任务，而GPOS运行用户界面软件。这里的保护是通过阻止GPOS访问RTOS所需的资源来实现的，因为GPOS只识别其资源的存在。此外，虚拟化层还可以在看门狗的帮助下检测其他故障的存在，通过看门狗可以根据检测到的故障类型使系统进入其预期的安全状态。

我们开展了类似的工作，旨在通过监督层根据系统调用规范检查计算结果来检测错误，从而使系统进入安全状态。正如作者所认为的，通过在导致任何危害事件之前检测到错误，比试图避免它们发生更容易满足安全目标。因此，直接促进安全性而不是可靠性和可用性属性。然而，这需要将架构的较低层开发到与监督层（包括硬件）相同的完整性级别，以保证计算和决策不会基于这些较低层的错误结果。

其他工作也在相同的基础上进行，但目的不同，其中包括分析和改进Linux作为虚拟机管理程序层的实时能力。因此，在实时域中扩展虚拟机管理程序层的可用性的可能性，在过去几年中已经变得更加令人感兴趣。以更好的确定性确保任务的正确执行时间有助于提高系统的可靠性，从而适合在安全关键环境中使用它们。然而，这是另一个关于Linux实时能力的话题，这不是本专题的主要焦点，但它很好地理解了干扰对执行时间的影响。这在后续连载的第6章中作为验证过程的一部分进行了更详细的演示，但通过分组策略的实现。

·微服务方法

基于微服务的方法的思想借鉴了操作系统的微内核架构思想，其中关键性非常高的任务由微内核执行，而关键性较低的任务由内核执行。因此，减少了极其关键的代码量。遵循这种方法，我们不再信任操作系统和底层系统软件，而是将其方法建立在对设计的应用程序组件给予信任的基础上。这是通过将应用程序的状态（数据）保存在封装的内存中来实现的，即使操作系统和管理程序层也无法访问安全关键应用程序的数据，如图11所示：微内核架构。因此，消除了正式尝试证明“Linux”的正确性的负担（这似乎是不可能的），而是通过开发的组件确保完整性、机密性和正确执行。

图11：微内核架构

主要目标是将操作系统堆栈拆分为一组微服务，其中每个微服务专注于某个方面，同时松散耦合并支持弹性扩展。在发生崩溃或性能失效的情况下，通过引入新服务来替换崩溃的实例来实现容忍。CPU寄存器、主存储器、文件、网络通信都是应该透明封装的数据示例，以确保系统的机密性和完整性。然而，实现的方法相当适合失效停止应用程序，并且仍然需要进一步研究它如何支持失效运行应用程序。此外，将所有任务划分为更小的服务可能会影响整个系统的性能，因为这会在调度和同步每个服务时引入延迟。

·分区方式

另一种软件安全机制是软件分区方法，它基于操作系统的能力，通过在分区中执行来允许多个独立进程的存在。每个分区中运行的进程只能看到操作系统分配给各自分区的资源。Linux可以通过其控制组功能来实现这一点，利用将任务分组到层次树中的思想，通过层次树可以将CPU资源分配给特定任务。可以根据配置允许或拒绝某些资源（例如CPU时间、系统内存、网络带宽，甚至这些资源的组合）。此外，重新配置可以在运行时动态发生，甚至子进程也会继承其父进程的属性。因此，例如，非安全关键应用程序将给予在存储器和CPU时间方面非常有限的资源，而对于安全关键应用程序将被授予所有所需的资源。因此，始终保证安全关键应用程序的资源可用性，并确保不会被非安全关键应用程序接管。下图描述了软件分区的实现，其中包含故障的较低关键性的任务A.2保持隔离，并且对较高关键性应用程序的任务没有影响。

图12：软件分区方法

这种方法的主要优点是受益于现有的内核功能，无需引入虚拟化层，也无需重组操作系统服务——正如以前的方法所证明的那样；使其实现相对简单。通过这种方法，可以实现故障（干扰）避免，但如上所述，对于高系统可靠性来说这可能还不够。高度关键任务可以被授予所需的CPU时间，但由于存在相同优先级的其他任务，而无法在所需的时间范围内获得CPU时间，从而导致错过其周期时间。因此，仍需要进一步的规定才能使系统达到所需的安全状态。该方法已在后续连载的第5章中作为软件安全分区机制实现并介绍，用于管理两个不同关键性应用程序之间的资源使用情况；其中的结果、其评估和局限性将在专题连载（三）中介绍。

更多内容，请关注“自适应AUTOSAR系统安全评估（三）：ISO 26262背景下GNU/Linux的评估”，关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

会议及培训咨询更多信息及洽谈，详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！