2、ATF安全状态机：安全状态机模型，状态转换规则，固件版本管理基础
好，我们直接进入正题。ATF里的安全状态机，说白了就是一套规则——它规定了系统在什么时候能干什么事，什么时候绝对不能干别的事。我刚开始接触ATF时，觉得这东西就是个状态图，后来踩了坑才明白，它其实是整个回滚保护机制的“交通警察”。
2.1 安全状态机模型
ATF的安全状态机，核心就三个状态：BL1、BL2、BL31。嗯，你可能还听过BL32、BL33，但那是后话了。我们先把这三个搞清楚。
核心模型：ATF的安全状态机是一个有限状态机（FSM），它定义了固件在启动过程中的合法状态和转换路径。每个状态对应一个特定的固件执行阶段。
我个人习惯把这三个状态理解为“三级火箭”：
- BL1（一级火箭）：这是最底层的启动代码，通常固化在ROM里。它负责最基本的硬件初始化，然后验证并加载BL2。我遇到过一些项目，BL1里连串口都没初始化，出了问题只能靠LED灯闪烁来调试——那叫一个痛苦。
- BL2（二级火箭）：这是可信启动的“大管家”。它负责验证后续所有固件的镜像，包括BL31、BL32、BL33。说白了，它就是安全启动的守门员。
- BL31（三级火箭）：这是运行时固件，负责处理安全监控调用（SMC），管理安全和非安全世界的切换。它一旦跑起来，就不再退回去了。
你想想看，这三个状态是严格串行的。不可能从BL1直接跳到BL31，中间必须经过BL2。为什么？因为安全启动的信任链就是这样一级一级建立起来的。
2.2 状态转换规则
状态转换的规则，其实就一句话：只能向前，不能后退。但这里面有几个关键点，我得跟你掰扯清楚。
注意：状态转换是单向的、不可逆的。一旦从BL1进入BL2，就再也回不到BL1了。这是安全设计的基本要求——防止攻击者通过回退到旧版固件来利用已知漏洞。
具体的转换规则如下：
| 当前状态 | 下一状态 | 触发条件 | 关键动作 |
|---|---|---|---|
| BL1 | BL2 | BL1完成基本初始化，验证BL2镜像通过 | 加载BL2到SRAM，跳转到BL2入口 |
| BL2 | BL31 | BL2完成所有镜像验证，包括BL31、BL32、BL33 | 配置内存管理，建立异常向量表 |
| BL31 | （运行态） | BL31初始化完成，进入主循环 | 处理SMC请求，管理电源状态 |
这里有个坑，我曾经踩过：BL2在验证BL31时，如果发现版本号不匹配，应该怎么办？很多新手会直接panic，但实际项目中，我们通常会根据策略来决定——是直接拒绝启动，还是降级运行。这取决于你的安全策略。
2.3 固件版本管理基础
版本管理，是回滚保护的核心。没有版本管理，状态机再完美也没用。
ATF里，每个固件镜像都有一个版本号，通常存储在镜像头的特定字段中。版本号的设计，我建议遵循以下原则：
- 单调递增：版本号只能增加，不能减少。这是防止回滚攻击的第一道防线。
- 非易失性存储：版本号必须存储在非易失性存储器中（比如eFuse、OTP），不能存在RAM里。为什么？因为掉电就没了，攻击者可以轻松绕过。
- 最小版本策略：系统会记录一个“最小可接受版本”，任何低于这个版本的固件都会被拒绝加载。
个人经验：我在一个项目中，客户要求支持固件降级（用于调试），但又不能影响安全启动。最后我们设计了一个“双版本号”机制：一个安全版本号（存储在eFuse中，只增不减），一个调试版本号（存储在Flash中，可读写）。调试模式下，系统允许加载调试版本号对应的固件，但安全版本号依然会记录最高版本。这样既满足了调试需求，又保证了安全底线。
版本管理的核心数据结构，通常是这样定义的：
/* 固件镜像头中的版本信息 */
struct fw_version {
uint32_t major; /* 主版本号 */
uint32_t minor; /* 次版本号 */
uint32_t build; /* 构建号 */
uint32_t reserved; /* 保留字段，可用于存储安全版本 */
};嗯，这里要注意：reserved字段在有些实现中被用来存储“安全版本号”（也叫抗回滚版本号）。这个安全版本号是独立于主/次版本号的，它只用于回滚保护，不用于功能标识。
2.4 状态机与版本管理的结合
现在我们把状态机和版本管理串起来看。整个流程是这样的：
- BL1阶段：读取eFuse中的最小安全版本号，验证BL2的版本号是否大于等于这个值。如果小于，直接死循环或重启。
- BL2阶段：验证BL31、BL32、BL33的版本号。同时，BL2会检查自己的版本号是否被篡改。
- BL31阶段：运行时，如果收到SMC请求要求更新固件，BL31会调用平台特定的接口，将新的版本号写入eFuse。
我曾经在一个项目中，发现BL2验证BL31时，版本号检查通过了，但BL31运行时却崩溃了。查了两天才发现，是BL31的镜像在加载过程中被破坏了，但版本号字段恰好没变。从那以后，我坚持在版本检查之外，还要做完整的哈希校验。
关键点：状态机保证了执行流程的合法性，版本管理保证了固件内容的新鲜度。两者缺一不可。
2.5 安全状态机流程图
下面这张图，是我根据实际项目经验画的。它展示了ATF安全状态机的完整流程，以及版本管理在其中的作用点。
这张图里，你可以看到版本检查点贯穿了整个启动流程。我个人觉得，这张图最核心的信息是：版本检查不是一次性的，而是分阶段、分层级的。每个阶段都有自己的检查职责，共同构成了完整的回滚保护体系。
避坑指南：我曾经在一个项目中，把版本检查只放在了BL2阶段，结果攻击者通过物理手段绕过了BL2，直接加载了旧版本的BL31。后来我们改成了“每级固件验证下一级固件”的模式，才彻底堵住这个漏洞。记住：信任链的每一环都要自己验证下一环，不能依赖上一环代劳。
好了，关于安全状态机和版本管理的基础，我们就聊到这里。这些概念虽然看起来简单，但实际落地时细节非常多。下一节我们会深入讨论具体的回滚保护实现技术，包括eFuse编程策略、镜像签名验证等。嗯，到时候再细聊。