Linux内核闯入功能安全圈：ISO/PAS 8926:2024实战解读

本文围绕"复杂预存软件的功能安全适配方法"展开。当软件定义汽车把Linux、Android这类庞大预存软件推进整车架构，ISO 26262的V字模型开始"水土不服"。从而梳理了一条全新的认证通道——ISO/PAS 8926:2024。

一、SDV浪潮下ISO 26262面临的新挑战

汽车行业的功能安全标准ISO 26262是一道不可逾越的红线。它的核心是V字模型，每一行代码都必须能精确映射到某一项安全需求——这种完全可追溯性曾守护分布式ECU时代十多年。

但2020年前后，SDV浪潮把单颗HPC推到舞台中央。Linux内核2700万行、Android千万行级代码涌入车规架构，标准一下子撞上四重冲突：

可追溯性缺失——Linux是先有代码、后补规格说明

代码规模庞大——无法穷尽做ASIL B以上结构化测试

治理模式冲突——开源去中心化，无法提供企业内严格评审的安全证据

变更频率倒挂——CVE补丁天天推，传统认证周期月月做

二、既有机制：SEooC与软件组件认定的局限

面对"重用现有软件"的需求，ISO 26262推出了SEooC——供应商可提出使用假设/环境假设独立开发，加速供应链并行协作。

但SEooC的根本假设是"从写下第一行代码开始"就严格遵循V字模型。这对Linux这种在非功能安全领域演化多年的庞然大物完全失灵。第8部分第12节的软件组件认定原本是为小规模COTS库设计的避风港，对千万行级黑盒也无力。

于是8926登场——不再执着于追溯代码的过去，转而聚焦当下：当黑盒上车那一刻，如何让系统依然安全？

三、ISO/PAS 8926:2024的核心机制

8926是ISO在2024年1月颁布的公开可用规范（PAS），背后是Linux基金会ELISA项目多年工程探索的成果。其核心思想预计将并入2027年的ISO 26262第三版。

8926有一条贯穿始终的主线——以确定制约不确定：用外部安全岛MCU、hypervisor、隔离监控来兜底，抑制底层复杂软件的不确定性。

它围绕一个对象：PSAE（Pre-existingSoftwareArchitectureElement，预存软件架构元素），按两个维度量化不确定性：

投到P×C矩阵后，智能汽车所需的绝大部分技术软件都不可避免地落入Class II——必须走完整套防护机制+强制验证活动。

四、Class II预存软件的四步工程落地

把PSAE塞进车之前，遵循四步——

第一步：影响分析→划定危害边界把PSAE放进目标架构，看ASIL等级、外部接口、并发上下文。同样一份Linux代码，在中控屏跑ASIL QM就好，在自动驾驶决策路径却要ASIL D——同样的组件在不同语境下，安全责任天差地别。这一步的核心目标是明确「最坏情况下能造成多大危害面」。

第二步：外部安全机制→以确定制约不确定开源组件的内部不确定性无法消除，必须在外部筑防线。除了主核心，旁边一定有一颗独立的安全岛MCU，跑严格流程开发的监控代码。主内核一旦死锁、内存泄漏，安全岛的看门狗会立即切断底层控制指令，让车辆进入安全停靠状态。Red Hat In-Vehicle OS的实战组合：cgroups+实时调度+SELinux+容器=FFI（Freedom from Interference，免干扰）完整闭环。

第三步：适用性评估与裁剪→做减法的工程艺术如果把整套Linux原封不动搬进汽车，等于买了无数个随机炸弹。通过精密的调用链分析识别目标环境必需接口，仅保留最精简子集；编译阶段剔除无关代码，把改动控制在最小范围。它的反直觉点在于：不证明代码没问题，只证明「用不到的那部分」不会影响系统安全。

第四步：故障注入+持续认证验证思路彻底转变——从证明代码没错，到证明代码错了也不能让车出事。Red Hat与认证机构Exida推动的「持续功能安全认证」模式，把架构影响扫描、测试用例、故障注入全部接入CI/CD：补丁打入主线时，构建系统立即跑完全部验证，每日生成增量证据链。功能安全审核的脚步终于跟上了敏捷代码迭代的节奏。

五、三个落地建议

三件事，分别对应三类工作：

摸清代码家底——明确PSAE分类

安全机制兜住下线——做好隔离+FFI

把检查卡进CI/CD——建立持续认证流水线

8926真正教会行业的，是让标准学会妥协和务实——重要的不是把每一个代码块都变得完美，而是让整个系统在不完美的代码面前，依然保持安全。

六、精选问答

技术分享画出了一张工程蓝图，分享结束后社友们也提出了很多自己实际工作中的困惑，以下四个问题覆盖"距离量产/工程妥协/路径选择/横切议题"四个维度。

Q1：Linux内核的ASIL D认证，距离真正量产还有多远？

答：Red Hat最早2024年通过的是数学库ASIL B，2025年5–6月才拿到整个OS的ASIL B。目前业界公认单Linux认证的天花板就是AISL B。若要达到整车系统的AISL D，通常必须配合外部安全岛MCU或ASIL D认证的Hypervisor/微内核做安全分解。业界目前不存在商业化通过AISL D认证的宏内核Linux。从认证证书到真正上车，中间还有OEM集成验证、长周期路试、售后质量闭环——认证是质量门槛，量产是产品门槛，不能画等号。

Q2：未使用的旧代码不能完全禁用，与Linux内核如何共存？

答：完全禁用对内核不现实——某些"未使用"代码可能承担复杂内部调用。工程方案：把用户动态遗留代码/第三方库封装进容器，运行QM业务，容器内失效触发外部安全机制接管，让系统进入安全降级；另外对于内核未使用代码进行工程裁剪。不在不安全代码上追求百分百验证，而是系统层面做到"出问题也不影响整车安全"。

Q3：已认证的OSEK/微内核OS还能套用ISO8926吗？

答：OSEK微内核、Type-1hypervisor代码量小、可从零构建——走ISO 26262正向设计就够了，不需要套8926。8926真正适用的是继承大量历史代码、无法走完整正流程的复杂预存软件。能从零写的、就走ISO 26262；不能从零写的复杂预存软件，就走ISO 8926。

Q4：功能安全（FS）与信息安全（CS）在内核层面的"异同"？

答：FS防"系统自身故障"，CS防"恶意外部攻击"——失效模式、验证手段、应急响应链都不同。FS与CS应建立联合review机制，而不是把内核生硬地切割给两个独立团队——这将是下一个十年汽车安全的核心议题。

七、结语

这场直播最大的感受是：汽车功能安全过去十年最大的变化，不是标准越来越严，而是大家想问题的方式变了——从过程合规走向结果可证明，从「消灭每一行危险代码」走向「用确定机制去兜住不确定」。

Linux 这种开源底座上车已经不可逆，标准学会与不确定性共处，才是真正务实的方向。

审核编辑 黄宇