Zephyr 安全概述

简介

本文档是一份安全文档，概述了安全相关活动，以及 Zephyr 项目和 Zephyr 安全工作组 / 委员会希望实现的目标。

本概述面向对 Zephyr RTOS 功能安全开发感兴趣的读者，以及希望为项目安全工作作出贡献的项目成员。

概述

本节概述安全认证的总体目标、我们希望达到的标准，以及为获得此类安全认证而需要实施的质量标准和流程。

安全文档更新

本文档会持续更新，随着新要求、指南或流程的引入，其内容也可能随之调整。

  1. 相关方将通过拉取请求向 Zephyr 文档仓库提交更改。

  2. Zephyr 安全委员会将审查这些更改，并提供反馈或接受更改。

  3. 更改一经接受，便会成为本文档的一部分。

总体安全工作范围

安全委员会的总体工作范围是，针对限定范围的源代码（参见认证范围，待定），取得符合 IEC 61508 标准、安全完整性等级（SIL）3 和系统性能力（SC）3 的认证。由于代码库已存在，我们采用 IEC 61508 标准定义的途径 3s/1s 方法。

途径 3s

对不符合标准要求的开发进行评估。其本质上是针对现有源代码采用途径 1s。

途径 1s

符合标准要求的开发。遵循本标准关于避免和控制软件系统性故障的要求。

IEC 61508 标准概述

IEC 61508 是一项广泛认可的国际标准，涉及电气、电子和可编程电子安全相关系统的功能安全。以下概述了该标准在安全方面的一些关键内容：

  1. 危险与风险分析 ：IEC 61508 标准要求全面分析系统相关的潜在危险和风险，以确定将这些风险降至可接受水平所需的适当安全措施及其等级。

  2. 安全完整性等级（SIL） ：该标准引入了安全完整性等级（SIL）的概念，用于划分每项安全功能所需的风险降低程度。SIL 越高，所需的风险降低程度就越大。

  3. 系统设计 ：IEC 61508 标准要求采用系统化的系统设计方法，包括识别安全要求、制定安全计划，以及采用适当的安全技术和措施，确保系统达到所要求的 SIL。

  4. 验证与确认 ：该标准要求对安全相关系统进行严格的测试和评估，以确保其达到规定的 SIL 并满足其他安全要求。这包括验证系统设计、确认系统功能，以及持续监控和维护系统。

  5. 文档与可追溯性 ：IEC 61508 标准要求建立全面的文档编制流程，确保完整记录安全相关系统的各个方面，并确保从安全要求到最终系统设计和实现均具有完整的可追溯性。

总体而言，IEC 61508 标准为安全相关系统的设计、开发和实现提供了一个框架，旨在降低事故风险并提高整体安全性。遵循该标准，组织可以确保其安全相关系统按照最高安全完整性等级进行设计和实现。

为什么选择 IEC 61508？

选择 IEC 61508 标准，是因为它是一项适用于各行业领域的基础性功能安全标准。它提供了一个完善的框架，可作为各行业专用标准的基础。Zephyr 操作系统的通用性使其能够有效应用于广泛的行业领域，因此 IEC 61508 尤其适合 Zephyr。

下图展示了 IEC 61508 标准与其他相关标准之间的关系：

IEC 61508 relation to other standards

IEC 61508 与其他标准的关系

质量

在整个行业中，质量都是对软件的基本要求。项目代码库必须达到多项软件质量目标，才能从安全角度被视为可审计的代码库，并用于认证。但软件质量并不是功能安全标准带来的额外要求。功能安全将质量视为既有的前提条件，因此，无论功能安全目标如何，任何项目都应达到“质量受控”状态。以下列表说明了构建可审计代码库所需达到的质量目标：

  1. 基本软件质量标准

    1. 编码指南 （包括：静态代码分析、编码风格等）

    2. 安全需求 和需求追踪

    3. 测试覆盖率

  2. 软件架构设计原则

    1. 分层架构模型

    2. 封装的组件

    3. 封装的单一功能（如果其不适合纳入安全范围或无法在该范围内管理）

基本软件质量标准——安全视角

本章中，安全委员会将说明为什么需要将上述质量目标作为前提条件，以及从安全角度出发，需要做哪些工作才能使代码库具备可审计性。总体而言，所有这些与安全相关的质量措施都是为了尽量降低代码开发过程中的错误率。

编码指南

编码指南是工业软件产品形成共同理解、统一规则集和开发风格的基础。对于安全而言，编码指南必不可少，除了统一规则集之外，它还有另一个目的：必须证明开发人员遵循统一的开发风格，以防止软件开发过程中出现 系统性错误 ，从而尽量降低整个软件系统的总体 错误率 。

此外， IEC 61508 标准 也针对采用编码标准或指南提出了前提条件和建议，以降低出错的可能性。

项目 TSC 和项目安全委员会同意采用分阶段、渐进的方式，使代码符合一套编码规则（即编码指南），以提高代码库的质量和一致性。以下是商定的各个阶段：

阶段 I（已完成）

编码指南规则已可供遵循和参考，但尚未强制执行。CI 尚未强制执行这些规则，审查者或批准者也不能因违反规则而阻止拉取请求合入。

阶段 II

对于代码库中任何部分的拉取请求，如果违反编码指南，审查者或批准者可以阻止其合入。

开始在代码库的有限范围内强制执行规则，初始范围为安全认证范围。对于易于在整个代码库中应用的规则，不应将合规要求局限于初始范围。此步骤需要工具支持、CI 配置和强制执行策略。

阶段 III

重新审视编码指南规则，并根据前几个阶段的经验，对选定的规则进行完善和迭代。

阶段 IV

将强制执行范围扩展到代码库的更多部分。对于代码库中的某些部分，如果理由充分，可以允许例外。例外情况需要 TSC 批准。

备注

任何时候都可以通过提交 GH issue 或 RFC，提议移除或修改编码指南规则。

重要

当前阶段： 目前正在研究完成 阶段 II 所需的前提条件：工具正在评估中，CI 配置和 强制执行策略 的相关工作正在进行。

需求和需求追踪

需求和需求管理不仅对软件开发很重要，对安全也非常重要。一方面，它们从技术层面详细规定和描述了软件应实现的功能；另一方面，它们也是验证所描述功能是否按预期实现的重要且必要的工具。为此，需要将需求追踪到代码层面。借助需求管理和追踪，可以验证功能是否经过测试并正确实现，从而尽量降低系统性错误率。

此外，IEC 61508 标准也强烈建议采用需求和需求追踪（这实际上相当于认证的必备条件）。

Test coverage

高测试覆盖率可以作为安全证据，表明代码严格符合其开发目的，且不会执行任何未预见的指令。如果全部代码都经过测试，并且测试覆盖率很高（理想情况下为 100%），还可以快速发现有缺陷的改动，进一步降低错误率。不过，必须注意，安全对测试覆盖率有不同的要求，需要考虑 IEC 61508 标准针对 SIL 3 / SC3 目标规定的各种指标。其中，必须满足以下要求：

  • 结构测试覆盖率（入口点）100%

  • 结构测试覆盖率（语句）100%

  • 结构测试覆盖率（分支）100%

如果无法达到 100%（例如防御性代码的语句覆盖率），则需要在文档中说明未覆盖的部分，并给出合理依据。

Software architecture design principles

要创建和维护结构化的软件产品，还必须考虑各项软件架构设计，并按照安全标准加以实现，因为某些设计和实现不适用于安全场景。这样才能使整个软件及其代码库可供审计。不过，这些软件架构设计大多已在 Zephyr 项目中实现，需要由安全委员会／安全工作组以及安全架构师进行验证。

Layered architecture model

IEC 61508 标准 强烈建议采用模块化的软件架构。Zephyr 项目从一开始就通过分层架构遵循了这一方法。这种架构的思路是将功能相似的模块或组件组织到各个层中，从而为每一层分配其在系统中的特定职责。这种模型在安全方面的优势在于，可以从较高的抽象层次展示不同组件和层之间的接口，从而确定哪些功能与安全相关，并对其加以限制。此外，还可以基于此架构开展各类分析并编制文档，这些对于认证及负责认证的机构都很重要。

Encapsulated components

在这一阶段，封装的组件是安全架构设计的重要组成部分。其中最重要的是将安全相关组件与非安全相关组件分离，包括它们各自的接口。这可确保组件不会对其他组件产生 不良影响 。

封装单项功能（如果该功能在安全方面不合理且不可控）

对整个系统和软件环境的另一项要求是，能够禁用组件内的单项功能。这是因为，如果某项功能在安全方面完全不可接受（例如完整的动态内存管理），就应当能够关闭该功能。Zephyr 项目已经通过 Kconfig 及其灵活的可配置性提供了这种能力。

过程与工作流

Safety process and workflow overview

安全过程与工作流概述

该图描述了安全委员会为确保 Zephyr 项目开发过程中的安全而定义的大致流程。为便于理解，需要突出说明几点，并解释安全架构师和安全委员会在整个流程中的职责细节。该图仅描述变更与安全相关时可能采用的路径。

  1. 应在主分支上明确项目的安全范围，通常这只是整个代码库中的一小部分。随后，应在“main”分支的日常开发过程中，使这一部分代码达到可审计状态，也就是特别关注此范围内的质量目标（质量 ）和安全过程。安全架构师在这一领域与技术指导委员会（TSC）协同工作，监督开发过程，确保架构满足安全要求。

  2. 在这一阶段，安全架构师的作用愈发重要。对于安全范围内的 PR 或问题，理想情况下，安全架构师应参与该范围内小规模变更的讨论和决策，以便对不符合要求的安全相关变更作出响应。如果某个拉取请求或问题引入了重大且影响广泛的变更或改进，需要进一步讨论或决策，安全架构师应视情况将其提交安全委员会或技术指导委员会（TSC）审议，以便他们决定最佳行动方案。

  3. 这一部分描述认证方面的工作。此时，代码库必须处于“可审计”状态，理想情况下，代码库应不再需要或接受进一步的变更。主分支仍有一条通向此区域的路径。这条路径用于以下情况：在创建 LTS 分支和可审计分支之后，主分支的安全范围内发现了严重缺陷，或实施了重要变更。此时，安全委员会必须与安全架构师共同决定，是否将该缺陷修复或变更集成到 LTS 中，以便也能将其集成到可审计分支中。这种集成可以采取三种形式：仅变更代码、仅更新安全文档，或同时进行两者。

  4. 这里描述认证本身所必需的安全过程。在此阶段，将按照认证机构及所依据的认证标准的规定，完成认证过程中必须开展的最终分析和测试，并编制最终文档。如果认证机构在此阶段批准了所有内容，且安全过程已经完成，就可以创建并发布安全版本。

  5. 从可审计分支向主分支的这一流转只应在特殊情况下发生，具体而言，是指在认证过程中发现了必须在“可审计”分支上迅速调整才能获得认证的事项。为防止下一次认证时再次出现此问题，需要有一条路径将这些变更合并回主分支，以免变更丢失，并在必要时为下一次认证做好准备。

重要

安全要求不应以任何方式阻碍项目进展或压缩项目的发展空间。

重要

待办： 寻找并定义对维护者、审查者、贡献者以及安全架构师自身日常工作影响尽可能小，同时又满足安全要求的方法、指南和流程。