一、安全启动概述：什么是安全启动、为什么需要安全启动、ATF中的安全启动架构

大家好，我是你们的ATF移植实战讲师。今天咱们来聊聊安全启动这个话题。说实话，安全启动这个概念，在我刚入行那会儿，总觉得它离我很远——不就是上电后检查一下代码签名嘛，有什么好讲的？直到有一次，我在一个IoT项目里亲眼看到设备被刷入了恶意固件，整批产品差点报废……嗯，从那以后，我再也不敢小看安全启动这回事了。

1.1 什么是安全启动

安全启动，说白了就是一套机制。它保证设备从上电那一刻起，执行的每一行代码都是可信的、未被篡改的。

你想想看，一个嵌入式设备上电后，最先跑的是什么？是BootROM里的代码。然后BootROM加载BL1，BL1加载BL2，BL2加载BL31、BL32、BL33……这一条链路上，任何一个环节被动了手脚，整个系统就沦陷了。

安全启动的核心逻辑其实很简单：信任链。每一级固件在加载下一级之前，都要验证它的签名或哈希值。验证通过，才把执行权交出去。这就是所谓的「逐级验证，链式信任」。

1.2 为什么需要安全启动

这个问题我问过不少学员，有人回答「防病毒」，有人回答「防破解」。都对，但不够全面。

我个人习惯把安全启动的需求归纳为三个层面：

• 防篡改： 防止攻击者通过物理手段（比如JTAG、SPI Flash编程器）直接改写固件。我在一个车机项目里就遇到过，有人把Flash拆下来用编程器刷了第三方固件，结果整个娱乐系统变砖了——如果当时有安全启动，这种事根本不会发生。
• 防回滚： 防止攻击者把设备降级到有漏洞的旧版本固件。我记得有个路由器漏洞，就是利用回滚攻击，把固件降级到三年前的版本，然后利用已知漏洞提权。安全启动配合版本号检查，就能堵住这个口子。
• 防恶意代码注入： 防止攻击者在启动过程中注入恶意代码。比如通过USB、网络等接口，在系统还没完全起来之前塞入恶意载荷。

1.3 ATF中的安全启动架构

好了，前面铺垫了这么多，咱们来看看ATF里具体是怎么做的。

ATF的安全启动架构，我习惯把它理解成一个「洋葱模型」——一层包一层，每一层都验证下一层。

下面这张图是我自己画的，能帮你快速理解整个信任链的流转过程：

这张图里，BootROM是信任根（Root of Trust）。它固化在芯片内部，物理上不可修改。BootROM里硬编码了公钥哈希，用来验证BL1的签名。BL1验证通过后，再去验证BL2，以此类推。

这里有个关键点：信任根必须是不可变的。如果BootROM能被改写，那整个信任链就崩塌了。我在做一款车规级芯片移植时，芯片厂商特意把BootROM做成了OTP（一次性可编程），就是为了防止这个。

1.4 ATF安全启动的核心组件

ATF里跟安全启动相关的组件，我列个表给你看：

组件	作用	所在层级
Trusted Boot	验证固件镜像的完整性和真实性	BL1/BL2
FIP (Firmware Image Package)	打包所有固件镜像，附带签名和证书	BL2
Certificate Database	管理公钥证书链	BL1/BL2
RoT (Root of Trust)	提供不可变的信任锚点	BootROM

这里我想特别提一下FIP。FIP说白了就是一个容器，把BL1、BL2、BL31、BL32、BL33以及它们的证书打包在一起。BL2在启动时，会从FIP里解析出各个镜像，然后逐一验证。

1.5 安全启动的两种模式

ATF支持两种安全启动模式，我简单对比一下：

• Trusted Boot： 只验证镜像的完整性（哈希校验），不验证签名。适合开发阶段或对安全性要求不高的场景。
• Authenticated Boot： 验证镜像的数字签名，确保镜像来自可信的发布者。这是生产环境的标准配置。

我个人建议，哪怕是在开发阶段，也尽量开启Authenticated Boot。为什么？因为我在一个项目里吃过亏——开发时一直用Trusted Boot，结果到了量产阶段才发现证书链配置有问题，差点导致延期。早点把签名验证跑通，后面会省很多事。

1.6 避坑指南

好了，安全启动的基本概念就讲到这里。下一节我们会深入ATF的代码，看看这些验证逻辑具体是怎么实现的。记住一句话：安全启动不是功能，是习惯。养成从第一天就开启签名验证的习惯，后面会少很多麻烦。

---