ARM Trusted Firmware深度解析：从启动链路到安全审计与平台移植

做固件和BSP这行做的项目多了以后你会发现基于ARMv8/AArch64的系统无论盒子、服务器还是工控板启动链路上都少不了一个东西Arm Trusted FirmwareATF。它由ARM官方维护运行在EL3是整个系统里特权级别最高的一段代码。我接触过的不少新板子bring-up早期都是把ATF当“跑通Linux之前的一个坎”来绕直到需要安全启动、TEE、休眠唤醒时才被迫回来啃它。这篇内容算是一份结合源码评测和工程实战的总结。我会从ATF的整体架构讲起把BL1到BL33的链路拆开然后聊聊做安全固件工程审计时该盯哪些关键代码点最后给出一条可复现的平台移植路径包含构建命令、最小改动清单和排错思路。适合正在啃ATF源码的BSP工程师、做固件安全评估的同学以及准备把ATF移植到新板子上的团队参考。为了让不同背景的读者都能跟上我尽量把每个环节的背景、原因和坑都写清楚而不是只给结论。1. 先说结论ATF在ARM系统里到底扮演什么角色1.1 从按电源键那一秒说起现代ARMv8/AArch64的SoC一上电CPU通常处于EL3状态。如果说整个系统是一栋大楼EL3就是物业管理中心顶层那间不对外开放的机房而ATF就是这间机房里常驻的管理员。它在操作系统还没有影子的时候就开始运行负责建立最初的信任根、装载并验证后续启动镜像、提供运行时安全服务、处理电源状态转换。这四件事听起来好像各自独立本质却是一条线系统里所有的关键资源切换都想找一个最高权限、相对独立、不被普通软件干扰的地方来完成这个地方就是EL3而ATF就是EL3上的标准实现。很多人第一次看到ATF是在编译U-Boot或Linux内核时遇到BL31、FIP、TRUSTED_BOARD_BOOT这些词。它解决的是一个“谁来证明所有东西都可信”的破冰问题CPU内部固化的BootROM把BL1加载起来BL1验证并加载BL2BL2再验证并加载BL31、BL32可信OS比如OP-TEE和BL33普通世界的bootloader一般是U-Boot或UEFI每一级都校验下一级的签名最终形成一条完整信任链。没有这条链ARM系统在安全启动和安全世界切换这两件事上就没有地基。1.2 ATF不是“一个bootloader”那么简单如果你把ATF理解成“又一个小bootloader”后面会走不少弯路。它由Boot阶段和Runtime阶段两部分组成。Boot阶段的BL1和BL2确实像引导程序看起来就是在搬运镜像、校验签名、然后跳转。但Runtime阶段的BL31是长期存活在EL3的常驻服务框架Linux内核起来之后每一次CPU上下电、系统休眠、重启关机用户看着是内核在做决策内核实际是调用BL31通过PSCIPower State Coordination Interface暴露的标准接口。当普通世界的软件想跟TrustZone安全世界通信时也是通过SMC指令陷入EL3由BL31分发到OP-TEE或其它安全服务。从这套机制能看出来ATF在绝大多数ARM服务器、手机SoC、嵌入式板卡里其实都在默默工作。对搞BSP、固件、系统安全的工程师来说能不能看懂并改好ATF基本决定了你能不能把一块新板子从“能跑Linux”推进到“能安全启动能休眠唤醒能顺畅对接TEE”。这也是我写这篇源码评测和移植总结的原因。2. ATF源码架构全景把整个仓库按功能切成三块2.1 仓库结构与BL1到BL33的完整链路ATF源码仓库第一眼看上去目录很多但如果按职责划分可以分成三大块启动阶段代码、运行时服务代码、平台抽象代码。启动阶段对应bl1/和bl2/运行时对应bl31/、bl32/平台相关集中在plat/而drivers/、lib/、include/则是它们的公共支撑。理解这个大分层比死记某个文件路径重要得多。目录/模块主要职责在启动/运行链中的位置bl1/第一级启动固件被BootROM加载建立安全环境验证BL2后跳转bl2/第二级启动固件从FIP中加载并验证BL31/BL32/BL33bl31/EL3运行时固件常驻EL3提供PSCI、SMC分发、上下文管理bl32/安全世界OS的dispatcher承载OP-TEE等TEE的入口例如opteedplat/平台相关代码每个SoC/板级自己的实现ATF通过它能跨平台迁移drivers/驱动代码GIC、UART、认证、加密、IO等lib/核心库异常级别上下文xlat_tablesPSCI库el3_runtime等以BL1为例它是最早运行的固件负责设置异常向量表、初始化内存、加载BL2。BL1代码量不大但极其依赖平台相关逻辑没有串口你连调试信息都看不到没有MMU和内存映射你连BL2镜像都放不到内存里。这也是为什么ATF把几乎所有操作都抽象成平台接口真正硬核的芯片相关逻辑都被隔离在plat/里。BL2则比BL1更复杂一些它要解析FIP镜像包、处理镜像描述符、执行证书验证然后按顺序把BL31、BL32、BL33加载到各自约定的内存地址。BL31是运行时固件的核心常驻在EL3负责响应SMC请求、PSCI电源管理、安全世界与普通世界的切换。BL32本身不是一个固定的OS而是“安全世界OS的入口”例如opteed目录里就是用来加载和切换OP-TEE的dispatcher。整个链路中还有一个容易被忽略的BL33它通常不是ATF仓库里的代码而是编译ATF时通过BL33路径传进去的U-Boot或UEFI固件。正经项目里ATF团队很少关心BL33内部实现只约定一个加载地址和入口点。2.2 关键数据流镜像加载、验证与SMC世界切换ATF整个运行过程可以抽象成两条关键数据流一条是启动阶段的镜像加载链另一条是运行阶段的SMC分发链。启动阶段BL2通过IO框架drivers/io/从存储介质读取FIP镜像包。FIP全称Firmware Image Package是一个把BL2之后的多个镜像打包在一起的容器格式用ATF自带的tools/fiptool/fiptool生成和维护。BL2解析FIP里的镜像描述符拿到每个镜像的UUID、加载地址和大小然后调用认证框架drivers/auth/逐一校验。校验通过后BL2把控制权交给BL31BL31在EL3完成运行时环境布置最后跳转到普通世界的BL33。这个过程中镜像的存放位置、加载地址、内存边界全部由平台代码提供。运行阶段的SMC分发链同样关键。普通世界的内核或用户态软件执行smc指令后CPU陷入EL3的异常向量表ATF根据SMC Function ID找到对应的运行时服务例如std_svc处理标准服务、psci处理电源管理、opteed处理TEE请求。服务处理完毕通过上下文管理模块lib/el3_runtime/aarch64/context_mgmt.c恢复普通世界的寄存器状态再eret回到EL1或EL2。这个“保存上下文、切换世界、恢复上下文”的过程就是ATF作为Monitor的看家本领。很多安全审计者喜欢盯这段逻辑是因为普通世界传入的参数本质上不可信一旦EL3侧对参数校验不全就可能被恶意构造的SMC调用带偏。2.3 信任链设计TBBR安全启动是怎么落地的ARM定义了一套TBBRTrusted Board Boot Requirements规范ATF是这套规范最典型的开源实现。信任链的根是ROTPKRoot of Trust Public Key也就是一把烧在SoC OTP/efuse里的公钥对应私钥由设备厂商自己保管。启动时BL1用ROTPK验证BL2证书BL2用BL2证书中的公钥继续验证下一级镜像的证书密钥层级像树一样向下展开。每一级证书都包含镜像的哈希值只要中间任何一级的镜像被篡改证书校验就会失败。在实际工程里密钥管理和防回滚往往是两块最容易翻车的部分。ATF通过TRUSTED_BOARD_BOOT1 GENERATE_COT1开启证书生成和信任链验证开发阶段可以用tools/cert_create生成一组临时密钥。但生产环境必须换成真正的HSM或安全密钥管理制度来保管私钥。防回滚则依赖NV计数器每次新固件完成验证并准备激活时递增对应的计数器值。如果攻击者想刷回一个有漏洞的旧版本固件NV计数器的值对不上BL1/BL2就会拒绝启动。这个设计思路本身不复杂但计数器更新的“时机”非常讲究更新太早可能导致验证失败后计数器已经增加把板子永久变砖更新太晚又可能被攻击者跳过回滚保护。3. 安全固件工程审计源码评测里最值钱的环节3.1 审计的开局思路别从main函数开始读拿到ATF源码做安全审计很容易犯一个错误打开bl31/bl31_main.c一行行往下读。这样读两周你对整个工程的理解可能还是散的。更有效的做法是按“信任边界”切分先问自己哪些数据是从外部进入EL3的这些数据的输入点在哪解析这些数据的代码在哪错误路径是否安全我习惯先列输入面清单。ATF最主要的输入面有四个FIP镜像包BL2解析、X.509证书BL2用Mbed TLS解析、SMC请求参数BL31运行时接收、以及BL32/SPM传来的数据。除此之外调试接口、固件更新接口、实际项目里自定义的可信应用接口都算额外攻击面。把“哪些数据不受信任”搞清楚之后再带着问题去读代码效率会高很多。3.2 我审计时重点盯的代码点如果按文件说话drivers/auth/auth_mod.c是第一个要仔细看的地方。它负责整个认证流程核心逻辑是调用不同认证方法逐项验证证书和镜像哈希。这里最常见的漏洞模式是逻辑分支处理不当某个校验失败后错误状态没有层层返回后续代码继续往下走最终导致“验证失败但流程继续”。我在一些第三方平台的定制ATF代码里见过类似问题社区上游版本通常问题不大但下游厂商修改过的代码就不一定了。第二类高危代码点是所有涉及长度计算的解析逻辑。比如FIP镜像头解析、证书扩展字段解析、设备树解析common/fdt_wrappers.c这些地方只要size字段、offset字段是外部可控的就一定要确认有没有做上下界检查。经典错误是“先复制再判断长度”或者整数溢出导致检查被绕过。第三类重点关注PSCI路径lib/psci/下的psci_cpu_on、psci_cpu_off、psci_suspend等操作会接收目标CPU编号、入口地址等参数如果平台代码没有对CPU编号合法性做校验恶意普通世界软件理论上可能让EL3操作一个并不存在的CPU。为了方便记录我一般用下面这张清单逐项过代码检查项重点关注常见风险FIP/镜像解析长度字段、偏移量、加载地址越界读写、整数溢出证书解析X.509字段、ASN.1长度解析器崩溃、绕过验证SMC分发FID解析、参数个数、来源安全世界参数校验缺失、错误服务访问PSCI操作CPU编号、亲和层级、入口地址非法CPU、非法状态转换上下文切换保存/恢复寄存器列表、栈地址上下文破坏、信息泄露错误路径验证失败后的处理逻辑失败继续执行、计数器更新异常3.3 构建期安全选项审计结果再好配置错了也白搭源码审计只是安全工程的一半另一半是构建配置。ATF的Makefile里有大量和安全性直接相关的选项审计时不能只看默认值还要看目标产品的实际构建命令。DEBUG1会关闭编译优化并开启丰富日志这种固件只适合开发调试绝不能进量产。LOG_LEVEL同样需要控制我见过有厂商拿LOG_LEVEL40甚至50的固件出厂的内部地址、内存映射信息全部通过串口暴露等于把系统内部结构直接告诉攻击者。ENABLE_STACK_PROTECTOR建议在支持该选项的平台上打开虽然会增加一点运行时开销但对栈溢出的防护是实打实的。如果SoC支持ARMv8.3-A的指针认证Pointer AuthenticationATF还提供ENABLE_PAUTH选项可以给关键跳转地址加一层保护。另外一个常被忽略的点是日志本身的内容。即便LOG_LEVEL控制住了有些错误打印还是会输出寄存器地址、内存地址或证书解析细节。审计时要顺带扫一遍所有ERROR和NOTICE日志确保出厂固件里不会无意间泄漏敏感信息。做安全固件工程产品形态和威胁模型决定配置不是拿一份“通用安全配置”套上去就完事。4. 平台移植落地把ATF从官方板挪到你自己的板子上4.1 移植前的准备参考平台、工具链和常见误区前几年我见过不少新手工程手里只有一块x86开发机却要在一周内把ATF跑在一颗没接触过的ARM SoC上。先说结论强烈建议先在官方FVPFixed Virtual Platform或QEMU的sbsa-ref/virt机型上把ATF整条链路跑通再碰真实板子。FVP是ARM官方的指令级/系统级仿真模型x86主机上就能跑AArch64全系统QEMU则更轻量适合快速验证BL1/BL2/BL31与U-Boot的联动。很多平台问题本质上是内存布局和驱动地址问题这些逻辑在仿真平台上同样能暴露出来成本比烧板子低太多。工具链方面ATF需要一个能输出AArch64代码的交叉编译器常见选择是aarch64-none-elf-或aarch64-linux-gnu-一般Linux发行版的软件源里都能装到。这里要特别说一个常见误区热搜里经常有人搜“arm compiler 5.06 u7下载”那是Keil MDK里捆绑的Arm Compiler 5AC5主要面向Cortex-M单片机和裸机工程输出的是传统ARM指令集或Thumb指令不能用来编译ATF这种运行在AArch64状态的EL3固件。ATF的交叉编译思路更接近“在x86上交叉编译aarch64版Linux内核”工具链选对后面才不折腾。4.2 最小改动清单一个新平台从零到FIP假设你已经选好参考平台通常是plat/arm/board/fvp或plat/arm/board/juno下一步就是建立自己的平台目录。一个最小的ATF平台至少包含platform.mk、platform_def.h、plat_setup.c这几个文件。platform.mk是平台的构建入口定义平台名称、依赖的驱动、编译选项platform_def.h里放内存布局、基地址、编译宏等常量plat_setup.c实现平台初始化函数。有一些钩子函数是ATF底层框架会调用的平台必须实现或者复用默认弱实现。以BL31为例bl31_early_platform_setup2()负责最早期平台配置通常在这里完成串口初始化、内存布局准备bl31_platform_setup()负责常规平台初始化包括GIC配置、电源域描述、中断路由plat_get_next_bl_params()则决定BL31跳转到BL33时使用什么上下文和入口地址。不要把这些函数当成“必须照抄官方”而是要理解每个函数被调用的时机以及它对后续启动步骤的依赖。经常有开发者把UART初始化放在bl31_platform_setup()里结果BL31前期的报错全看不到。内存相关配置是最容易出现“能编译但跑不起来”的区域。你需要确认platform_def.h里的PLAT_PHY_ADDR_SPACE_SIZE、PLAT_VIRT_ADDR_SPACE_SIZE、BL31大小、BL32加载地址、BL33加载地址不会互相重叠。曾有团队把BL33加载地址设置得和BL2的堆栈区域重叠U-Boot一开始正常跑几分钟后随机死机查了整整两天才发现是ATF阶段的堆栈被U-Boot踩掉。GIC和UART驱动配置也要和硬件原理图一一对应GICv3需要GICD和GICR基地址UART如果是PL011还要关注时钟频率。每个基地址都来自SoC手册别凭感觉填。4.3 与BL33和可信OS的对接平台代码写完接下来是镜像打包。最简单的链路是只带BL33不带TEEmake CROSS_COMPILEaarch64-linux-gnu- PLATmyboard DEBUG1 \ BL33../u-boot/u-boot.bin fip这条命令会生成build/myboard/debug/bl1.bin、bl2.bin、bl31.bin和fip.bin。量产场景里通常还需要把BL1烧到BootROM引导位置把FIP放到存储介质的固定偏移处。BL2在启动时会根据平台代码定义的位置去读取FIP。如果要接入OP-TEE需要在构建时指定SPDSecure Payload Dispatcher和BL32镜像。ATF通过SPD机制把某个安全世界OS“挂”到EL3运行时框架里以OP-TEE为例构建命令会类似make CROSS_COMPILEaarch64-linux-gnu- PLATmyboard SPDopteed \ BL32../optee_os/out/arm-plat-myboard/core/tee-header_v2.bin \ BL32_EXTRA1../optee_os/out/arm-plat-myboard/core/tee-pager_v2.bin \ BL33../u-boot/u-boot.bin fipOP-TEE的镜像通常分成header和pager两部分ATF负责把它加载到约定地址并启动。SPD文件本质上是“中间调度层”它定义OP-TEE怎么被加载、世界切换时上下文怎么保存、SMC调度规则是什么。如果没有SPDATF就只保证“有一个安全世界”但不知道该往里面放什么东西。当需要打开TBBR安全启动时构建命令会加入一组密钥参数。合理的开发流程是先用GENERATE_COT1让ATF生成开发密钥跑通链路再逐步切换到受控密钥体系。别一上来就烧正式ROTPK到OTP调试阶段一旦密钥错了芯片就永久锁死。FIP打包和TBBR相关参数在不同ATF版本里略有差异老版本和较新版本诸如2023年以后的分支命令风格已经有一些变化动手前先跑一下make help看看当前版本支持的选项。5. 构建、调试与常见问题速查5.1 常用构建选项速查ATF的构建系统做得相当规整所有可配置项集中在make_helpers/defaults.mk里不查代码也能看到大部分默认值。我整理了一份常用选项速查表方便做平台移植时快速对照。构建选项作用典型值/说明PLAT指定平台目录名PLATmyboardDEBUG调试构建开关0/1生产环境必须0LOG_LEVEL控制日志详细程度10/20/30/40/50量产建议20BL33普通世界bootloader路径通常是U-Boot或UEFIBL32安全世界OS路径OP-TEE的header镜像SPD安全负载调度器opteed、tspd等TRUSTED_BOARD_BOOT打开TBBR安全启动0/1GENERATE_COT生成证书链0/1配合TBBR使用ROT_KEY信任根私钥路径生产密钥务必妥善保管ENABLE_STACK_PROTECTOR开启栈保护0/1ENABLE_PAUTHAArch64指针认证需要硬件支持5.2 常见问题与排查思路移植ATF时踩过的坑十有八九逃不出下面这几类。我把它们整理成速查表方便现场排错。现象可能原因排查思路编译报错找不到头文件PLAT名字写错、平台目录缺失检查plat/下目录是否存在make PLAT... help能否正确打印编译报错mbedtls缺失子模块没有初始化更新时用git submodule update --init拉全子模块或配置使用证书验证相关组件fiptool打包失败BL33路径不存在、镜像文件格式不对确认BL33指向真实存在的U-Boot镜像必要时用file查看格式串口完全无输出UART基地址/时钟配置错误或BL1没有被引导确认BootROM启动介质偏移确认platform_def.h中的UART地址与原理图一致启动卡在BL2加载阶段FIP偏移或存储介质配置错误检查BL2读取FIP的IO驱动配置确认FIP烧录位置和代码读取位置一致BL31跳转BL33后无输出BL33入口地址错误、或BL33镜像损坏核对plat_get_next_bl_params中的跳转地址检查BL33是否确实加载到该地址休眠唤醒后系统异常PSCI ops未正确注册、GIC配置错误确认平台实现了PSCI相关回调GICR/GICD基地址是否被正确映射OP-TEE起不来SPD未指定、BL32加载地址不对确认构建时SPDopteed确认BL32地址不与其他镜像重叠调试时有个小技巧先用DEBUG1 LOG_LEVEL50构建一版固件把所有日志打开确认ATF自身的启动链路正常再去关日志降级。这样能快速区分问题是ATF平台代码、BL33还是安全OS引入的。我还习惯在平台代码里临时增加串口打印把关键函数入口和关键变量值打出来定位到问题后再删掉。这类“临时调试代码”虽然不入库但在bring-up阶段往往比任何高级调试器都管用。最后再分享一点个人体会做了这么多年的固件我越来越觉得ATF这类EL3代码和普通嵌入式代码最大的区别不是技术难度而是“不可调试性”。普通驱动出问题加打印、断点、重启就能看到EL3出问题可能整个系统直接挂掉连一句日志都没有。所以我移植新平台时一定先把串口配置和日志系统调到最可靠的状态再去做复杂功能。串口不亮后面全是盲人摸象。另一个感受是ATF源码别看官方文档多很多平台细节只有自己读代码才能真正验证。如果让我给刚入门的工程师一个建议先在FVP或QEMU上把手动构建、FIP打包、TBBR开启这一整条流程亲手跑通再碰真实板子。这一步能替你省下大量烧板子、猜问题的折磨。