4. 安全启动流程：信任链建立、BootROM与BL1/BL2/BL31/BL33
安全启动，说白了就是给系统装一把「防伪锁」。从芯片上电的第一条指令开始，每一步都要验证下一阶段的代码是可信的。我在早期做IoT设备时，见过太多因为跳过这一步而被逆向的案例——嗯，从那以后我再也不敢轻视安全启动。
4.1 信任链的起点：BootROM
芯片复位后，CPU会从固定的物理地址取指。这个地址指向的就是BootROM——一块只读的、出厂固化的代码区。为什么必须是ROM？因为任何可篡改的存储介质，都不配做信任根。
信任根（Root of Trust, RoT）：BootROM是整条信任链的锚点。它不可更改，不可绕过。芯片厂商会在流片前把这段代码验证到极致——我见过一个团队为了修复BootROM的一个时序bug，直接重新流片，成本几百万。
BootROM做的事情其实不多，但每件都关键：
- 初始化最基本的硬件（时钟、SRAM、看门狗）
- 从预定义的启动介质（eMMC、NAND Flash、UART等）读取BL1
- 验证BL1的签名或哈希值
- 验证通过后，跳转到BL1
你想想看，如果BootROM有后门或者漏洞，整条信任链就全垮了。所以ARM在TrustZone的规范里，对BootROM的设计要求极其严格——它必须足够小、足够简单、足够安全。
4.2 BL1与BL2：第一、第二阶段的Bootloader
BootROM加载并验证BL1后，控制权就交给了BL1。BL1通常存放在片上SRAM或固定的安全存储区。它比BootROM大一些，但依然很精简。
BL1的主要任务：
- 初始化DRAM控制器（因为BootROM通常只用SRAM）
- 从存储介质加载BL2到DRAM
- 验证BL2的完整性
- 跳转到BL2
BL2则更复杂一些。它负责：
- 初始化更多的外设（比如存储控制器、时钟树）
- 加载BL31（EL3的运行时固件）和BL33（非安全世界的Bootloader）
- 建立初步的内存布局和安全分区
我的经验：BL1和BL2的代码量要严格控制。我曾经在一个项目里把BL1塞了太多功能，结果导致它超过了片上SRAM的大小——最后只能砍功能，重新布局。记住：BL1越小越安全，能放在BL2做的事，别往BL1塞。
4.3 BL31：EL3的运行时固件
BL31是TrustZone安全启动流程中承上启下的关键一环。它运行在EL3（异常级别3），也就是最高特权级。说白了，它就是安全世界的「大管家」。
BL31的核心职责：
- 提供安全监控模式调用（SMC）的处理
- 管理安全世界与非安全世界的上下文切换
- 处理电源管理、PSCI（电源状态协调接口）
- 为BL33提供启动参数
我记得在调试一个多核SoC时，BL31的SMC处理函数出了个bug——非安全世界调用SMC时，参数传递错了寄存器，结果安全世界的服务直接崩溃。排查了两天才找到问题，从那以后我养成了习惯：所有SMC调用必须做参数校验。
避坑指南：BL31的代码通常使用ARM Trusted Firmware（ATF）框架。ATF虽然成熟，但配置项极多。我曾经因为一个宏定义没开，导致安全中断无法正确路由到EL3——系统在运行时莫名其妙地挂死。建议你在移植ATF时，先把所有中断路由的配置项过一遍。
4.4 BL33：非安全世界的Bootloader
BL33就是大家熟悉的U-Boot、GRUB或者EDK II。它运行在非安全世界的EL2或EL1。到了这一步，信任链已经建立完毕，BL33可以放心地加载操作系统内核了。
BL33的启动流程：
- 从BL31接收启动参数（设备树、内存布局等）
- 初始化非安全世界的外设（网卡、USB、显示等）
- 加载操作系统内核（如Linux、Android）
- 跳转到内核入口
你可能会问：既然BL33是非安全的，那它怎么保证加载的内核是可信的？答案是：信任链已经在前四步完成了。BL33本身是被BL2验证过的，而BL33再去验证内核——这就是信任链的传递。
4.5 信任链的完整流程
下面这张图展示了从BootROM到BL33的完整信任链。每个环节都环环相扣，缺一不可。
4.6 各阶段的对比
为了方便你理解，我把四个阶段的关键差异整理成了表格。这个表在我做安全启动设计时经常参考。
| 阶段 | 运行位置 | 特权级 | 主要功能 | 存储介质 |
|---|---|---|---|---|
| BootROM | 片上ROM | EL3 | 信任根，加载BL1 | 只读ROM |
| BL1 | 片上SRAM | EL3 | 初始化DRAM，加载BL2 | 片上SRAM |
| BL2 | DRAM | EL3 | 加载BL31和BL33 | DRAM |
| BL31 | DRAM | EL3 | SMC处理，上下文切换 | DRAM |
| BL33 | DRAM | EL2/EL1 | 加载操作系统 | DRAM |
4.7 安全启动的常见陷阱
做了这么多年嵌入式安全，我踩过的坑不少。这里列几个最常见的，你遇到了可以少走弯路。
陷阱1：签名验证的密钥管理
我曾经在一个项目里，把签名用的私钥直接硬编码在代码仓库里——结果代码泄露，整个产品线的安全启动形同虚设。正确的做法是：私钥离线保存，只在签名服务器上使用；公钥可以放在BootROM或BL1中，但必须确保其完整性。
陷阱2：回滚攻击
攻击者可能把系统降级到有漏洞的旧版本。我见过一个案例：攻击者刷回了三年前的固件，而那个版本的安全启动验证有bug——结果整个系统被攻破。解决方案是：在BL2中实现版本号检查，拒绝加载低于当前版本的固件。
我的建议：安全启动不是一锤子买卖。在产品生命周期内，你可能需要更新公钥、升级签名算法。设计时就要考虑密钥轮换机制——别等到需要更新时才发现架构不支持。
4.8 实践：如何验证安全启动是否生效
理论说完了，来点实际的。你怎么确认你的安全启动真的在工作？
- 检查启动日志：大多数Bootloader会打印验证结果。搜索"Authentication passed"或"Signature OK"之类的关键字。
- 人为破坏签名：修改固件的一个字节，然后刷入设备。如果设备无法启动，说明验证生效了。
- 使用JTAG调试：在BL1的验证函数处设置断点，单步跟踪签名验证流程。我习惯在验证通过和失败的分支都打上断点。
- 检查安全状态寄存器：ARM的SoC通常有安全状态寄存器，可以读取当前是否处于安全启动模式。
核心要点：安全启动的本质是「信任的传递」。从BootROM这个不可篡改的信任根开始，每一级都验证下一级的完整性和真实性。任何一级验证失败，启动流程立即终止——这就是TrustZone安全启动的底线。