2. 安全启动基础
安全启动（Secure Boot）并不是一个单一功能，而是一套贯穿设备上电到操作系统接管之间的完整性验证机制。它的核心目标可以概括为一句话：确保设备每一次启动时，所执行的每一段代码都是经过授权且未被篡改的。理解安全启动，必须同时掌握四个基础概念——安全启动的定义、信任链、信任根以及启动阶段划分，它们共同构成了后续多阶段安全启动与故障恢复的理论地基。
一、安全启动的定义与本质
从工程角度看，安全启动是一种基于密码学的启动时验证流程。设备上电后，每一级即将运行的固件或软件在被执行之前，都要先验证其数字签名或度量值是否与预期一致；只有验证通过，控制权才会被移交。若验证失败，则根据策略进入阻断、降级或恢复流程。
需要强调的是，安全启动解决的是“启动代码的来源可信与完整性”问题，而不是运行时的全部安全问题。它通常依赖非对称密码算法（如 RSA、ECC）和哈希算法（如 SHA-256），并配合一次性可编程存储（如 eFuse、OTP）来固化信任起点。安全启动的本质，是把“信任”从不可验证的硬件锚点，逐级传递到可验证的软件实体。
二、信任根：信任的起点
信任根（Root of Trust, RoT）是整个安全启动体系中最先被执行、且被无条件信任的组件。它之所以可信，是因为它被固化在芯片内部，无法被外部软件修改。常见的信任根包括：
- 硬件信任根：如 Boot ROM、eFuse 中固化的公钥哈希、OTP 区域。
- 密码学信任根：如内置的根公钥（Root Public Key）或密钥派生种子。
- 度量信任根：如 TPM/TPM2.0 的 CRTM（Core Root of Trust for Measurement）。
信任根的关键属性是不可变性和最小化。它越小、越简单，被攻击面就越小。Boot ROM 通常只有几 KB 到几十 KB，却承担着验证第一级引导程序（如 BL1、SPL）的重任。一旦信任根被攻破，整条信任链都会失效，因此它必须由硬件保证其只读与不可绕过。
三、信任链：逐级验证的传递机制
信任链（Chain of Trust）是安全启动的核心逻辑：每一级代码在运行前，先验证下一级代码的签名，验证通过后再把控制权交给它。这样，信任就从信任根开始，像链条一样一环扣一环地传递下去。
信任链通常分为两个方向：
- 验证链（Verification Chain）：前一级验证后一级的签名，确保只有授权代码能运行。
- 度量链（Measurement Chain）：前一级对后一级做哈希度量并记录到 TPM/PCR，用于后续远程证明。
信任链的断裂点往往出现在“验证者与被验证者边界”上。例如，若 BL2 验证了 BL31，但 BL31 未验证 BL33，则 BL33 就成为信任链的缺口。因此，设计时必须明确每一级的验证责任，避免出现“验证真空”。
四、启动阶段划分：从 Boot ROM 到操作系统
典型的多阶段安全启动可划分为以下几个阶段，每一阶段都有明确的验证对象与执行主体：
| 阶段 | 执行主体 | 验证对象 | 信任来源 |
|---|---|---|---|
| Stage 0 | Boot ROM | BL1 / SPL 签名 | eFuse 中根公钥哈希 |
| Stage 1 | BL1 / SPL | BL2 / U-Boot SPL | Boot ROM 验证通过 |
| Stage 2 | BL2 | BL31、BL32、BL33 | BL1 验证通过 |
| Stage 3 | BL31 / BL33 | 内核、设备树、initramfs | BL2 验证通过 |
| Stage 4 | 内核 | 根文件系统、内核模块 | Bootloader 验证通过 |
在 ARM Trusted Firmware 体系中，BL1、BL2、BL31、BL32、BL33 是常见的阶段命名；在嵌入式 Linux 中，则常表现为 Boot ROM → SPL → U-Boot → Kernel → RootFS。无论命名如何，其本质都是分阶段移交控制权，并在每次移交前完成验证。
五、案例与场景：一次典型的启动验证流程
假设一台基于 ARM 的物联网设备上电，其安全启动流程如下：
- Boot ROM 读取 eFuse 中的根公钥哈希，验证 BL1 的签名；
- BL1 验证通过后运行，并验证 BL2 的签名；
- BL2 验证 BL31、BL32、BL33 的签名；
- BL33（U-Boot）验证内核与设备树；
- 内核验证根文件系统或 dm-verity 哈希树；
- 全部通过后，系统正常启动；任一环节失败则进入恢复模式。
对应的启动日志片段可能如下：
NOTICE: BL1: Booting BL2
NOTICE: BL2: Loading BL31
NOTICE: BL31: Secure boot verification passed
NOTICE: BL33: U-Boot SPL 2023.07
NOTICE: Kernel: dm-verity verified rootfs
如果 BL2 验证失败，日志中通常会出现 Authentication failed 或 Image hash mismatch，此时设备可能停在 Boot ROM 阶段，或跳转到备用分区恢复。
六、常见误区与复盘
误区二：忽略信任根的不可变性。 若根公钥存储在可写 Flash 中，攻击者可替换公钥后重新签名，安全启动形同虚设。
误区三：只做验证链，不做度量链。 验证链保证“能启动”，度量链才能支撑远程证明与审计。
误区四：阶段划分过粗。 若 Boot ROM 直接验证整个系统镜像，会导致验证逻辑臃肿、启动慢、恢复困难。
复盘时，建议围绕三个问题检查：信任根是否真正不可变？每一级是否都验证了下一级？失败后是否有明确的恢复路径？ 这三个问题，正是后续多阶段安全启动与故障恢复设计的出发点。
掌握以上四个基础概念后，就能理解为什么安全启动必须“分阶段、可验证、可恢复”。信任根提供起点，信任链提供传递，阶段划分提供秩序，而失败策略提供韧性——这四者缺一不可，也正是多阶段安全启动与故障恢复设计的核心骨架。