Cover image for Safety-Critical Linux: What Certifying It Actually Takes

Raghu Bharadwaj

安全关键型 Linux 指的是运行于故障可能造成人身伤害场景的 Linux：汽车、工业机器人以及医疗设备。 由于无法像小型安全控制器那样对整个内核进行认证，行业采取了不同的做法。它将定义好的 Linux 配置作为“上下文外安全元件”进行认证，同时记录关于其使用方式的假设，用小型高完整性监控器和硬件分区进行封装，确保故障不会扩散，并在代码变更时保持认证持续有效。对于嵌入式工程师而言，这造就了一项持久的新技能组合，其核心是安全架构而非仅限于内核代码。

在历史上很长一段时间，Linux 都被排除在可能造成人身伤害的产品部分之外。它运行仪表盘而非制动系统，运行医院显示器而非输液泵的剂量回路。如今这条界限正在移动。软件定义汽车、外科手术机器人以及工业自动化希望在整个设备中使用一个功能强大的操作系统，而这个操作系统越来越可能是 Linux。安全关键型 Linux 正是为了让 Linux 承担这些角色，同时不降低安全标准所做的努力。本文将解释为什么这项工作具有挑战性、实际如何实现，以及这一转变对嵌入式和内核工程师意味着什么。

为什么安全关键型 Linux 突然成为现实

最明确的证据是一张证书。在 2024 年和 2025 年，Red Hat 基于 Red Hat Enterprise Linux 打造的 In-Vehicle Operating System 获得了 exida 认证机构颁发的 ISO 26262:2018 ASIL-B 阶段性功能安全认证，并于 2025 年实现全面可用。功能安全标准定义了分级的完整性等级：汽车领域的 ISO 26262 从 ASIL-A 到最严格的 ASIL-D，IEC 62304 适用于医疗设备软件，DO-178C 涵盖机载系统，IEC 61508 是工业领域的基础标准。几年前，通用 Linux 发行版获得任何汽车 ASIL 等级认证听起来都不太可能。

这一里程碑背后是社区的共同努力。Linux 基金会“Linux 安全应用使能”（ELISA）项目汇聚了汽车、半导体和工业领域的成员，共同定义构建和认证基于 Linux 的安全关键系统所需的共享工具和流程，并直接与认证机构和标准组织合作。

💡 核心洞见： 问题已从“Linux 是否能安全？”转变为“对于哪种定义好的配置、在何种上下文中、配合何种监控，我们才能提出安全论证？”正是这一重新定位让近期认证成为可能。

为什么无法用传统方式认证 Linux

传统安全认证假设的开发流程是 Linux 从未遵循过的。经典安全组件遵循需求驱动的 V 模型构建：每项需求都被记录、追踪到设计、追踪到代码、追踪到测试，通常还需进行 MC/DC 等结构覆盖率分析。这对仅为单一目的编写的数万行代码是可行的。而 Linux 内核有数千万行代码，由数千人贡献，每周都在变化，且从未针对完整、可追溯的需求集进行编写。此外，也无法通过构建方式保证某个组件出现故障时不会破坏其他组件。

因此，你无法简单地让整个内核通过 V 模型审计并获得证书。安全关键型 Linux 的现实路径是改变认证对象和论证方式。

💡 核心洞见： 安全不等于安全。安全关注攻击者是否能入侵；安全关注系统在发生故障（包括普通硬件故障和自身缺陷）时能否进入安全状态。一个系统可以经过加固，但仍可能不安全，相应的标准、证据和技能也各不相同。

实际如何实现

安全关键型 Linux 通过结合多种技术实现，其中任何一种都不是“证明整个内核正确”。

上下文外安全元件（SEooC）。 供应商不会对通用的 Linux 进行认证，而是针对特定配置和假设的使用上下文进行认证，并记录必须满足的使用假设。Red Hat 的认证正是遵循这一路径：它是一个针对预定义目标硬件的 ASIL-B SEooC，使用 ISO 26262 第 6 部分作为评估框架，并与 ISO/PAS 8926:2024（针对已有软件建立信心的规范）保持一致。随后，集成商负责遵守这些假设。

安全监控器承担完整性。 设计中不会信任基于 Linux 的大型功能，而是增加一个小型、简单、高完整性的组件，用于检查结果并在出现问题时强制进入安全状态。由于该监控器很小，可以用传统方式开发和认证，从而将高完整性要求从 Linux 转移到它身上。这就是混合关键性模式，通常由实时操作系统在一个核心上处理关键回路，而 Linux 在另一个核心上运行丰富功能。

无干扰性。 安全部分与非安全部分必须防止互相破坏内存、时序和执行。这通过硬件和分区来实现：独立的核心、内存保护或管理单元，或如 Xen 这样的管理程序，其安全工作是 ELISA 内部的活跃课题。

持续认证。 由于 Linux 不断变化，认证不可能是一次性事件。证据和论证会随着代码库的变动而持续维护，这就是为什么供应商将自己的产品描述为“持续认证”而非“一次性认证”。

ELISA 正在构建什么

ELISA 的贡献是任何单一公司都不愿单独重建的共享基础。其工作组涵盖汽车、医疗设备、航空航天以及横跨系统和工程流程的领域，并产出开源工具和文档：描述内核配置的方法、将需求追踪到测试的方法、分析安全论证依赖哪些内核特性和子系统的方法，以及记录工程流程本身的方法。最近的社区工作包括 Xen 管理程序的安全分析以及面向医疗软件的开源质量管理系统。该项目正在扩展，2026 年将有新的工业和学术成员加入。

这对嵌入式和内核工程师意味着什么

安全关键型 Linux 催生了对介于内核工程与安全工程之间的技能组合的需求，目前同时掌握两者的人非常少。这些有价值的能力是具体的：使用分区和管理程序设计无干扰性；架构安全监控器，使完整性要求落在小型组件而非整个系统上；规范的内核配置和需求可追溯性，以实现可重现和可审计的构建；理解 ASIL 分解和使用假设；运行混合关键性设计，让 RTOS 和 Linux 共享同一 SoC。了解内核是基础；知道如何围绕它提出可辩护的安全论证才是稀缺的能力。对于愿意同时学习这两方面知识的工程师而言，这是未来十年将带来回报的更持久的专业化方向之一。

关键要点

  • 安全关键型 Linux 已在实际生产中落地：Red Hat 的 In-Vehicle OS 于 2025 年获得 ISO 26262 ASIL-B 认证，由 exida 作为上下文外安全元件进行认证。
  • 无法用传统的、需求驱动的 V 模型对整个内核进行认证；它太大、变化太快，且从未按照这一流程编写。
  • 可行的路径是定义好的配置加上使用假设、承载完整性的小型安全监控器、通过分区实现无干扰性，以及持续认证。
  • 安全是一门不同于安全的学科，采用不同的标准（ISO 26262、IEC 62304、DO-178C、IEC 61508）和不同的证据。
  • 新兴且稀缺的技能组合是围绕 Linux 的安全架构，而不仅仅是 Linux 内核本身。

常见问题

Linux 内核本身能否通过 ISO 26262 认证？
无法以传统方式对整个内核进行认证。获得认证的是针对特定上下文的特定配置，作为上下文外安全元件，并附带记录的使用假设，同时由其周围的监控和分区提供支持。Red Hat 的 In-Vehicle OS 正是以这种方式获得 ASIL-B 认证的。

安全关键型 Linux 与安全或加固的 Linux 相同吗？
不相同。安全关注抵御攻击者；安全关注在发生故障（包括硬件故障和软件缺陷）时能否进入安全状态。它们使用不同的标准和证据，加固后的系统仍可能不安全。

什么是安全监控器，为什么它重要？
它是一个小型、简单、高完整性的组件，用于检查基于 Linux 的功能，并在出现故障时强制进入安全状态。由于它很小，可以用传统方式进行认证，从而将高完整性要求从庞大的 Linux 系统转移出去。

什么是 ELISA？
Linux 基金会的“Linux 安全应用使能”项目。其成员构建创建和认证基于 Linux 的安全关键系统所需的共享工具和流程，并与汽车、医疗和航空航天领域的认证机构和标准组织合作。

延伸阅读

Originally published on TECH VEDA。