4. 启动流程详解：Boot ROM → SPL → U-Boot → Kernel 的链式验证
安全启动的链式验证，说白了就是一条信任链。每一级都验下一级的签名，验不过就停。我刚开始接触这个机制时，总觉得它有点啰嗦——每次启动都要验好几遍，不嫌慢吗？后来在项目中吃过亏，才明白这每一道检查都是必要的。
今天我们就来拆解这条链。从芯片上电的第一条指令，到操作系统跑起来，一共四步：Boot ROM、SPL、U-Boot、Kernel。每一步都有它的职责，也有它的坑。
核心思想：信任链的起点是硬件固化的 Boot ROM，它不可篡改。后续每一级都由前一级验证，形成一条从硬件到软件的信任传递路径。
4.1 Boot ROM：信任链的根
芯片一上电，CPU 会从固定地址开始执行。这个地址指向的就是 Boot ROM。Boot ROM 是芯片出厂时固化的，你改不了它。嗯，这就是信任链的根。
Boot ROM 做的事情很简单：
- 初始化最基本的硬件（时钟、SRAM、看门狗）
- 从预定的存储介质（NAND、eMMC、SD 卡、SPI NOR）读取下一级镜像
- 验证该镜像的签名或哈希
- 验证通过后跳转执行
我个人习惯把 Boot ROM 比作「看门大爷」。它不干重活，但必须可靠。它手里有一把公钥，这把公钥存在 eFuse 或 OTP 里，芯片出厂时烧进去的。你想想看，如果这把公钥被人改了，整个信任链就塌了。
避坑指南：我曾经在一个项目中，发现 Boot ROM 读 eMMC 时总是超时。查了两天才找到原因——eMMC 的初始化时序和 Boot ROM 预期的不一致。后来我们在硬件设计阶段就提前和芯片厂商对齐了启动介质的参数，再没出过类似问题。
4.2 SPL：轻量级加载器
SPL（Secondary Program Loader）是第二级加载器。为什么需要它？因为 Boot ROM 通常只有很小的 SRAM 可用，比如 64KB 或 128KB。这点空间放不下完整的 U-Boot。所以 SPL 的任务就是：初始化 DDR，然后把 U-Boot 从存储介质加载到 DDR 中。
SPL 本身也是被 Boot ROM 验证过的。它必须包含合法的签名，否则 Boot ROM 不会放行。SPL 的验证流程大致如下：
- Boot ROM 从固定偏移读取 SPL 镜像头
- 解析镜像头中的签名信息和镜像大小
- 用公钥验证签名
- 验证通过后，将 SPL 复制到 SRAM 并跳转
这里有个细节：SPL 的签名算法通常是 RSA-2048 或 ECDSA。我建议使用 ECDSA，因为它的签名更短，在存储空间受限的场景下更友好。
注意：SPL 运行在 SRAM 中，SRAM 通常没有 ECC 保护。如果 SRAM 受到单粒子翻转（SEU）影响，SPL 可能跑飞。在安全关键系统中，建议在 SPL 中加入 CRC 校验，或者在硬件层面启用 SRAM ECC。
4.3 U-Boot：完整的引导加载器
U-Boot 是嵌入式 Linux 中最常用的引导加载器。它功能丰富，支持文件系统、网络启动、环境变量等。但在安全启动场景下，U-Boot 的角色被严格限制——它必须验证内核的签名，然后才能加载内核。
U-Boot 的验证机制通常通过以下方式实现：
- Verified Boot（vboot）：U-Boot 内置的签名验证框架
- FIT Image：一种包含镜像、配置、签名的统一镜像格式
- 环境变量保护：防止攻击者通过修改环境变量绕过验证
我记得有一次调试一个启动失败的问题，发现 U-Boot 总是报「Bad hash」。查了半天，原来是内核镜像的哈希算法和 U-Boot 配置的不一致。U-Boot 里配的是 SHA-256，但签名工具用的是 SHA-512。这种低级错误，一旦踩过就再也不会犯了。
下面是一个典型的 FIT Image 配置示例：
/dts-v1/;
/ {
description = "FIT Image with signed kernel";
#address-cells = <1>;
images {
kernel-1 {
data = /incbin/("Image");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "none";
hash-1 {
algo = "sha256";
value = <0x...>;
};
signature-1 {
algo = "rsa2048";
key-name-hint = "dev-key";
value = <0x...>;
};
};
};
configurations {
default = "config-1";
config-1 {
kernel = "kernel-1";
signature-1 {
algo = "rsa2048";
key-name-hint = "dev-key";
value = <0x...>;
};
};
};
};
关键点：U-Boot 在加载内核前，会先验证 FIT Image 中的签名。如果签名无效，U-Boot 会拒绝启动。这个验证过程是强制性的，不能通过环境变量跳过——除非你故意关闭了安全启动功能。
4.4 Kernel：操作系统的安全启动
内核被 U-Boot 验证通过后，加载到内存中开始执行。但安全启动到这里还没结束。内核本身也有自己的安全启动机制，比如 Linux 的 IMA（Integrity Measurement Architecture） 和 Kernel Lockdown。
IMA 会在内核启动后，对关键文件（比如可执行文件、动态库）进行哈希度量，并将度量值扩展到 TPM 的 PCR 中。这样，即使攻击者篡改了文件系统，TPM 也能检测到。
Kernel Lockdown 则更进一步——它限制了一些高危操作，比如：
- 禁止加载未签名的内核模块
- 禁止修改内核代码（如 kprobe、ftrace）
- 禁止访问 /dev/mem、/dev/kmem
说白了，Kernel Lockdown 就是把内核「锁死」，不让它被动态修改。这在安全启动的最后一环非常重要。
个人经验：我曾经在一个项目中启用了 Kernel Lockdown，结果发现某个驱动模块加载失败了。查了半天，原来是这个模块没有签名。后来我们给所有内核模块都签了名，问题就解决了。记住：Lockdown 模式下，未签名的模块一律拒绝加载。
4.5 链式验证的完整流程
把上面四步串起来，就是完整的链式验证流程。我整理了一张表格，方便你对照：
| 阶段 | 存储位置 | 验证者 | 验证对象 | 失败后果 |
|---|---|---|---|---|
| Boot ROM | 芯片内部 ROM | 硬件逻辑 | SPL 签名 | 芯片锁死，无法启动 |
| SPL | SRAM | Boot ROM | U-Boot 签名 | SPL 停止，进入错误处理 |
| U-Boot | DDR | SPL | Kernel 签名 | U-Boot 拒绝加载内核 |
| Kernel | DDR | U-Boot | 内核模块签名 | 内核拒绝执行未签名模块 |
你可能会问：如果中间某一级被攻破了怎么办？比如攻击者修改了 U-Boot 的验证逻辑？嗯，这个问题问得好。U-Boot 本身是被 SPL 验证过的，而 SPL 是被 Boot ROM 验证过的。只要 Boot ROM 是安全的，整条链就是安全的。所以，保护 Boot ROM 和 eFuse 中的公钥，是安全启动的命门。
重要提醒：千万不要在生产环境中使用测试密钥。我见过不止一个团队，开发时用了一套测试密钥，发布时忘了换。结果产品上市后，攻击者用公开的测试密钥就能签名恶意镜像，整条信任链形同虚设。生产密钥必须严格管理，最好存储在 HSM 中。
4.6 实际部署中的常见问题
链式验证说起来简单，部署起来坑不少。我列几个常见的：
- 签名工具链不一致：开发机上的签名工具和产线上的版本不同，导致签名格式不兼容。建议统一工具版本，并在 CI/CD 中固化。
- 密钥轮换：公钥一旦烧进 eFuse 就改不了了。如果密钥泄露，只能换芯片。所以密钥管理要提前规划好。
- 启动时间：签名验证需要计算，会延长启动时间。在性能敏感的场合，可以考虑使用硬件加速引擎（如 CAAM、SA2UL）来加速 RSA/ECDSA 运算。
- 调试与生产分离：开发阶段可以关闭签名验证，方便调试。但生产版本必须强制开启。我建议在 U-Boot 中通过 GPIO 或 eFuse 位来控制是否启用验证，这样既灵活又安全。
好了，链式验证的原理和部署就讲到这里。记住一句话：信任链的强度，取决于它最弱的一环。保护好你的根密钥，其他环节按部就班地做，安全启动就不会出大问题。