安全关键应用中的
操作系统平衡

执行摘要

作为开源软件，Linux已经成为全球技术基础设施的核心支柱。它支撑着全球大多数服务器和超级计算机，并通过Android运行在移动设备上，在现代数字生态系统中无处不在。

复用已有成果、基于集体知识进行构建，并通过通用技术实现规模经济是合理的。这使企业能够加快开发进程，并避免传统方法中的问题。

这种借鉴其他行业成熟成果的思路，推动了Linux在汽车领域应用的讨论。这种做法在一定程度上是合理的。

但在功能安全应用场景中，传统Linux并不适合作为核心操作系统。过去十多年中，尝试将Linux应用于此类场景的努力效果有限。

因此，汽车企业应采用能够针对不同需求选择合适技术的软件架构。Linux可用于非功能安全系统，Android已广泛应用于车载信息娱乐系统，而经过验证和认证的实时操作系统（如风河开物RTOS）更适用于功能安全场景。这种最佳适配方式还可以通过风河开物Hypervisor在单一SoC上实现。

重要的是，这种混合架构同样能够满足企业在新一代软件架构和云原生模式中的需求，并以更适合功能安全场景的方式利用其他行业的发展成果。

理解Linux与功能安全

功能安全应用在汽车、医疗及工业自动化等行业中至关重要，一旦系统失效，可能导致人员伤亡、重大经济损失或环境破坏。

操作系统（OS）在这些应用中发挥关键作用，包括管理硬件资源、保障实时性能以及维持系统可靠性与稳定性。适用于功能安全环境的操作系统需要具备完善的安全机制、支持实时运行，并能够支持认证流程以满足ISO 26262或DO-178C等严格标准。通过对这些因素进行平衡，操作系统能够确保功能安全应用在各种条件下稳定运行，从而降低风险并保障用户与环境安全。

风河在Linux领域拥有20年的经验，其中包括20年面向嵌入式系统发布Yocto Linux，以及10年面向企业系统发布CentOS Linux和Debian Linux。2024年，我们发起了一个基于Debian（企业与边缘方向）的社区项目eLxr。我们还是多个Linux开源项目的联合发起方，包括Open Handset Alliance（即后来的Android Linux）、Yocto Linux、eLxr Debian Linux以及基于Debian Linux的StarlingX。这一传承凝聚了数十年的开源贡献与引领。真正的开源原则、领导力与Linux已深植于风河的基因之中。

这意味着我们对Linux的优势有深入理解，并且是其积极的倡导者。我们不断为客户提供更丰富的Linux操作系统产品组合。我们重视Linux庞大且活跃的开发生态、跨行业开发者之间的协作能力，以及避免厂商绑定的优势。基于这些优势，我们认为Linux在软件定义汽车中扮演着重要角色。

同时我们也清楚，Linux在功能安全认证方面存在明显挑战。这些包括：

• 认证复杂度： 将Linux应用于ISO 26262等功能安全标准的认证过程非常复杂。Linux内核规模庞大，包含数百万行代码，因此对每个组件进行安全合规验证具有较高难度。认证需要严格的文档、测试与验证，这对于Linux这类大型通用系统来说较为困难。Linux内核包含超过3000万行代码，随着每次版本发布，新功能增加、缺陷修复以及旧代码移除，这一数量也会变化。相比之下，实时操作系统通常仅约100万行代码。
• 缺乏预认证发行版：不同于部分已具备预认证或按功能安全标准设计的专有RTOS，主流Linux发行版本身并不直接满足ISO 26262或类似安全标准。企业需要投入大量时间与资源进行认证，通常需要自行开发符合功能安全要求的Linux版本或使用特定变体，这些方案往往最终形成单一来源的定制版本。
• 长期维护与支持： 在功能安全认证环境下，为特定内核版本提供长期支持与安全更新具有挑战。许多Linux发行版无法提供功能安全行业所需的长期支持周期，通常需要10年以上。
• 持续认证需求：Linux，尤其是其上游及社区版本，更新频繁。这些更新通常包括安全补丁、新功能以及缺陷修复。在功能安全场景中，每一次更新都需要进行充分评估、测试，并可能需要重新认证，以确保不会引入新的风险或影响系统安全。ISO 26262认证要求对系统的任何修改都必须重新评估其对安全性的影响。这意味着每次内核更新或补丁（即使是安全相关），系统集成方都需要评估其对功能安全的影响，从而可能形成持续认证或重新验证的循环，增加成本并延缓系统更新。
• 非确定性时序： Linux默认并不是实时操作系统。如果未通过实时补丁进行配置，可能表现出非确定性行为，这不适用于需要稳定时序保障的功能安全应用。

在功能安全认证环境中，还存在一些难以管理的信息安全风险，包括：

• Linux的开源特性：Linux的开源特性意味着其代码对所有人可见且可修改。虽然这种透明性在一般信息安全场景中是优势，因为Linux能够受益于社区的审查与贡献，但同时也使其成为攻击者分析漏洞的目标。在功能安全认证系统中，这一点可能带来问题，因为安全漏洞可能影响功能安全。更优的方案是在提供源代码的同时，对其进行受控管理，而非完全公开。
• 缺乏集中化的安全治理：不同于由单一厂商统一管理安全补丁和更新的专有操作系统，Linux采用分布式开发模式，依赖全球社区贡献。这可能导致对安全威胁响应不及时，以及不同发行版之间补丁应用不一致，从而难以保证用于功能安全系统的Linux内核在长期运行中的安全性。
• 对认证的影响：ISO 26262等功能安全认证要求严格的验证与确认流程，以确保系统在包括安全威胁在内的各种条件下均能稳定运行。为了满足这些严格的安全要求，Linux需要进行大量测试与风险评估。每一个安全补丁都可能改变系统行为，从而需要重新验证，这将带来较高的成本与时间投入。

尽管存在这些挑战，仍有多种尝试使Linux适用于功能安全应用。我们认为这些方式难以满足汽车功能安全要求。这些方法包括：

• 强行认证： 在不改变实现的前提下，为每个API定义“安全使用方式”，并通过传统软件认证方法对Linux内核及其组件进行认证。问题在于，认证成本会随着开源Linux代码规模显著增加。如果无法在多个项目中复用这些认证成果，这种成本通常难以承受，并且已有企业在实践中遇到困难。
• 精简裁剪： 通过减少Linux内核及所需组件的代码规模，仅保留运行设备所需部分，从而降低认证工作量。但这通常意味着创建Linux分支，创建针对特定硬件或应用定制的内核和根文件系统，从而引入技术债务并带来长期维护成本。每当Linux社区发布更新时，都需要重新分析、定制补丁与修复，并重新进行认证。
• 内核修改： 功能安全系统通常需要确定性行为，这意味着需要对内核进行实时性改造。但每一次修改都会引入新的潜在风险，需要重新评估和测试，从而增加开发与认证复杂度。
• 专有锁定：许多功能安全认证系统试图通过固定特定Linux内核版本并冻结更新来维持认证状态。但这种方式可能导致系统长期无法获得关键安全补丁与漏洞修复，从而带来长期风险。同时，这种方式最终会演变为一种专有操作系统，而这恰恰是他们本想避免的 -- 如今却更加复杂度且成本更高。
• 长期使用证明：部分功能安全标准允许基于长期运行的历史数据进行“已验证使用”申报。虽然这种方式通常适用于低复杂度软件，但理论上也可能应用于Linux。然而目前尚未成功实践，并且这种方式绕过了严格的认证流程。
• 安全监控机制：一种方式是使用经过认证的“安全监控模块”来监控运行在未认证Linux上的应用。虽然该方案近期有所发展，但风河在10年前已实践类似方案，并发现其存在一些问题：首先，安全监控本身复杂且通常为专有实现；其次，会影响性能；第三，需要在Hypervisor中增加额外驱动，同样具有专有属性。

功能安全标准的调整

另一种方式是通过调整或修订认证标准，以降低在功能安全环境中使用开源软件的风险。其中一个备受关注的方向是ISO 26262（第三版）的更新工作。该提案（ISO/PAS 8926）旨在为ISO26262中处理开源软件定义一套替代性方法论。

该公开规范（PAS）的核心在于，根据软件来源与复杂度对“既有架构组件”进行分类，并据此制定软件认证指导原则。理论上，由于Linux具有长期使用历史与广泛测试基础，可被评估为具备较高可信度，从而在ISO 26262认证中减少对“新软件”所需的完整认证流程。

虽然该方法可能提供一条更经济高效的开源软件使用路径，但现有功能安全标准之所以存在自有其道理，并已被证明能够有效使业界相信软件功能安全是可以实现的。修订标准可能动摇业界对软件功能安全的信心。包含上述修订内容的ISO 26262标准更新版本预计将于2027年正式批准。

成本问题

那么，Linux是否可以用于功能安全认证系统？答案是可以。风河在历史上曾为相关行业开发过此类系统，并持续支持定制Linux方案。但这些实践也表明，将通用Linux用于功能安全系统往往成本高、复杂度高、可行性较低。

最终，我们认识到，通过“最佳适配”的方式构建功能安全系统，可以更有效实现新一代软件开发环境的目标。

实现相同的收益

让我们退一步来思考，在面临诸多挑战的情况下，行业为何仍然推动将Linux应用于功能安全环境。企业希望通过这种方式实现哪些收益？这些收益是否可以在不改变Linux的情况下实现？

• 开发者熟悉度：Linux因在各行业的广泛应用而对开发者具有吸引力。但这种熟悉度同样可以通过POSIX接口实现。此外，自2020年以来，实时操作系统也已支持广泛使用的OCI标准容器和Kubernetes。
• 多用途能力：Linux被认为能够同时处理多种工作负载，包括信息娱乐、连接和人工智能等非功能安全任务。我们认可这一点，但需要说明的是，功能安全相关任务更适合运行在RTOS上。
• 开源驱动的成本优势：Linux通常被认为是“免费的”，用户可以自行构建或选择商业支持版本。但如前所述，在功能安全系统中使用Linux时，这种“免费”便荡然无存。采用最佳适配方式，可以适合的非功能安全场景中合理利用Linux的成本优势。
• 持续创新能力：Linux被认为是一个创新迭代迅速的平台，这得益于大量开发者的共同贡献。因此，风河认为Linux在整体架构中具有其价值。但在功能安全应用中，同样的创新能力也可以通过在RTOS中采用OCI标准容器、Kubernetes和云原生微服务来实现。

风河方案：基于认证RTOS的混合架构

一种将Linux、Android和RTOS结合，并运行在Type 1 Hypervisor之上的混合架构，是满足现代功能安全系统需求的有效方式。该架构充分发挥各自优势，Linux用于通用能力，风河开物RTOS用于硬实时和功能安全场景，Android用于信息娱乐和用户界面应用。

通过在Hypervisor管理的独立虚拟机中运行Linux、Android和RTOS，可以实现功能安全与非功能安全任务的隔离。系统结构如下：

• Hypervisor提供系统间隔离，使Linux或Android发生故障或安全问题时，不易影响运行功能安全应用的RTOS。
• RTOS提供功能安全应用所需的硬实时能力（例如ISO 26262 ASIL-D级别要求），确保系统满足时序与可靠性需求。
• Linux提供健壮的网络能力、设备支持以及云连接能力。
• Android在用户界面和应用生态方面具有优势。

通过将Linux用于连接与云服务、Android用于用户界面、RTOS用于关键时序控制，该架构可以扩展应用于从消费设备到高端汽车系统等多种场景。

系统隔离使Linux和Android可以独立更新或打补丁，而不会影响RTOS。这有助于在提升安全性的同时保持功能安全系统的稳定性。

该架构支持混合关键性负载，可在同一硬件上运行高性能消费类应用与功能安全任务，从而避免使用多套硬件，降低系统复杂度与成本。这在汽车行业尤为有价值，有助于显著降低硬件成本。

简而言之，与其将Linux强行应用于所有场景，不如采用最佳组合的系统化方案，充分利用各类技术的优势。

未来展望

通过Type 1 Hypervisor整合Linux、Android和RTOS的混合架构，为需要高级用户界面和连接能力的功能安全系统提供了强大且灵活的解决方案。RTOS的实时能力与Linux和Android的丰富功能相结合，兼得两者之长。

风河方案使功能安全认证的整体成本在产品生命周期内更加可控、合理且可预测。同时，它契合汽车行业将多种功能集成到更少计算平台上的发展趋势，并可基于现有成熟软件实现，已在多个项目中得到认证机构认可。

随着技术发展，可以通过OCI标准容器和Kubernetes等Linux生态技术，实现嵌入式系统的“云化”。在该混合架构中，Android、Linux和RTOS均支持容器及Kubernetes工作节点功能（通过Kubelet实现），在开发、部署、扩展和生命周期管理方面具有明显优势。这种方式本质上构建了统一的类云架构，并通过Kubernetes实现编排管理。

该路径避免了直接改造Linux所带来的复杂挑战，同时实现嵌入式系统与云原生架构的融合，适用于需要同时管理功能安全实时任务、信息娱乐以及AI应用等多样化负载的行业。