ARM Trusted Firmware 深度源码评测ATF 架构全景梳理、安全固件工程审计与平台移植落地指南这两年我在嵌入式安全领域摸爬滚打接触最多、也最绕不开的一个基础组件就是 ARM Trusted FirmwareATF。不管是做手机 Secure Boot、平板固件安全升级还是边缘网关的可信启动链ATF 几乎都是绕不开的第一道关口。它跑在 Linux 内核之下、硬件之上负责把 CPU 从 EL3 安全世界带到 EL1 内核世界同时承担着 PSCI 电源管理、安全监控模式切换、可信启动认证这些底层脏活累活。这篇文章我准备从源码层面拆解 ATF 的架构全景聊聊做固件工程审计时应该重点盯哪些文件和调用链最后分享一下我在平台移植过程中的完整落地步骤和踩坑实录。内容主要来自这一年来基于实际项目对 ATF 源码的持续阅读和移植验证希望能帮到正在做 ARM 底层固件、Secure Boot 方案选型或正准备把 ATF 移植到新板卡上的朋友。先说明一下文章里的源码分析基于 TF-A 的 LTS 分支v2.8 系列同时我会穿插一些 master 分支上的新特性对比。如果你手头的代码版本不同行号和宏定义可能会有出入但核心架构和调用链基本一致。1. ATF 在 ARM 启动流程中的位置与核心价值1.1 ATF 解决了什么问题很多人第一次接触 ATF 时会被它的名字吓到觉得它是一个庞然大物。其实 ATF 的定位非常聚焦它是 ARM 平台上安全世界的固件参考实现提供了从片上 ROM 启动到内核运行之间那段真空地带的标准化方案。在 ATF 出现之前各家 SoC 厂商在 BootROM 之后几乎都是各搞一套安全监控模式的代码千奇百怪也没有统一的电源状态协调接口。ATF 的价值在于它把 EL3 异常等级下的安全监控模式、电源管理、可信启动这些能力做成了一个可复用的标准框架。用生活类比来理解如果 Linux 内核是一个公司的业务部门那 ATF 就是这家公司的保安系统和物业总管。保安系统负责验证每一个进入公司的人是否持有合法工牌Trusted Boot 认证物业总管负责在业务部门休息时管理大楼的照明和电力分配PSCI 电源管理。业务部门自己在正常工作时间做业务但上下班开关门、凌晨停电如何恢复这些都归物业和保安管。1.2 启动链路全景BL1、BL2、BL31、BL32、BL33 的接力赛我在刚开始读 ATF 源码时最大的困惑是它的启动流程里为什么会有这么多 BLBoot Loader阶段。后来跟着代码走了一遍才明白这其实是一场严格分工的接力赛。整个启动链路从 SoC 出厂固化的 BootROM 开始BL1存放在片上 ROM 或一次性可编程存储中是复位后的第一个可执行代码负责初始化最小硬件环境把 BL2 从外部存储加载到 SRAM 并完成安全认证然后跳转过去。BL1 的代码量最小但容错要求最高。BL2运行在 EL3 下的可信启动固件负责初始化 DDR、加载 BL31和可选的 BL32到内存执行镜像签名验证验证通过后跳转到 BL31。BL31常驻内存的 EL3 运行时固件包含 Secure Monitor、PSCI 电源管理实现、SMC 调度器是 ATF 中最核心的物业总管。BL32可选的 Trusted OS如 OP-TEE运行在 S-EL1通过 SMC 与 BL31 通信。如果你的产品不需要 TEE这个阶段可以跳过。BL33就是我们常说的 U-Boot 或 UEFI运行在 EL2/EL1最终引导 Linux 内核。关于 BL31 和 U-Boot 的关系很多做上层开发的朋友容易混淆。BL31 运行在 EL3U-Boot 运行在 EL2/EL1两者的职责完全不同。U-Boot 阶段如果需要做电源管理相关操作比如 CPU 热插拔、系统挂起唤醒必须通过 SMC 指令陷入 EL3由 BL31 里的 PSCI 实现来真正操作硬件寄存器。这也是为什么 ATF 经常和 U-Boot 一起出现在启动代链中——它们在异常等级上是上下级关系。1.3 异常等级与安全状态模型理解 ATF 绕不开 ARM 的异常等级模型。ARMv8-A 定义了四个异常等级从 EL0 到 EL3数字越大特权越高。系统复位后 CPU 默认进入 EL3ATF 的 BL1/BL2/BL31 都在这个等级运行。EL2 通常跑虚拟化层HypervisorEL1 跑操作系统内核EL0 跑用户态应用。ATF 架构里还有一个非常重要的概念安全世界Secure World和普通世界Normal World。这两个世界共享同一套 CPU 物理资源但通过 TrustZone 技术做了隔离。Linux 运行在普通世界TEE 运行在安全世界两个世界之间的切换必须经过 EL3 的 Secure Monitor也就是 BL31 里的bl31_main和上下文管理模块。每次切换都需要保存和恢复完整的 CPU 上下文这部分代码在context_mgmt.c里是 ATF 中极其考验细节的地方。2. ATF 源码结构全景与关键目录审计2.1 源码顶层目录速览我习惯拿到一份源码先看目录结构因为目录设计通常反映了整个工程的核心模块划分。TF-A 的顶层目录并不复杂但每个目录的职责非常清晰tf-a/ ├── bl1/ # BL1 阶段源码 ├── bl2/ # BL2 阶段源码 ├── bl31/ # BL31 阶段源码 ├── bl32/ # BL32TEE 入口相关代码 ├── common/ # 各 BL 阶段共享的通用代码 ├── drivers/ # 驱动串口、定时器、IO 存储、认证加密等 ├── lib/ # 核心库el3_runtime、psci、stack_protector 等 ├── plat/ # 平台移植代码核心工作区 ├── services/ # 运行时服务SMC 调度、std_svc、trng 等 ├── include/ # 全局头文件 ├── tools/ # 构建与镜像处理工具cert_create、fiptool 等 ├── makefile # 顶层构建入口 └── docs/ # 设计文档与移植指南从工程审计的角度看plat/目录是每次必看的因为这是芯片厂商和方案商修改最集中的地方。lib/el3_runtime/里的上下文切换代码、lib/psci/里的电源管理框架、services/里的 SMC 调度器则决定了这个信任根实现是否健壮。2.2 核心库源码审计要点el3_runtime这个目录下主要是 AArch64 的异常进入与退出实现以及上下文管理。context_mgmt.c负责维护安全世界和普通世界的上下文结构体每一个cpu_context都保存了通用寄存器、系统寄存器、SVE 寄存器状态。在做安全审计时我重点检查的是上下文切换时是否完整保存了所有相关寄存器尤其是vbar_el3、sctlr_el3这类影响安全策略的系统寄存器。psciPSCIPower State Coordination Interface是 ARM 定义的电源管理接口标准。ATF 里的实现分成两层上层是 PSCI 服务框架负责解析 SMC 请求、校验参数、分发调用底层是平台操作函数比如platform_cpu_pwr_down、platform_cpu_suspend这些需要移植时在平台代码里实现或者引入 scpi/sip 等协议与下游的电源管理处理器通信。做移植的朋友可以重点看psci_setup.c里的初始化顺序以及psci_cpu_on.c的启动流程。el3_common这里存放 EL3 阶段共用的初始化代码包括 cache 使能、MMU 配置、异常向量表设置。BL31 的入口bl31_entrypoint.S就在这里是整个安全固件运行起来的第一行汇编。我在审计时习惯先看这段汇编确认启动时 CPU 处于什么状态、需要规避哪些硬件 bug。2.3 运行时服务与 SMC 调度机制ATF 启动完成后主要工作就是响应普通世界的 SMC 请求。所有 SMC 请求进入 EL3 后都会先经过runtime_svc.c里的分发逻辑。这个逻辑非常精巧SMC 指令的函数 ID 编码里包含了服务类型、调用类型等信息ATF 根据这些字段决定将请求转给哪个运行时服务。标准服务std_svc通常处理 PSCI 请求比如PSCI_CPU_ON、PSCI_CPU_OFF、PSCI_SYSTEM_SUSPEND。SiPSilicon Provider服务则留给芯片厂商实现私有功能比如厂商特有的安全配置、温度读取、AB 分区切换等。这里有个容易忽略的审计点SMC 返回值是否对调用者做了合法检查。一个负责任的安全固件必须在进入具体服务处理前验证调用者位于普通世界还是安全世界、请求的服务 ID 是否被允许。在runtime_svc.c的runtime_svc_init和handle_runtime_svc流程里这些检查逻辑是否完整决定了整个系统安全边界的强度。3. 平台移植落地实操从零适配一块自定义 ARM 板卡3.1 移植前必须搞清楚的几个问题很多初学者拿到一块新板子第一反应是直接照抄参考平台的代码。这个思路没错但容易翻车。我建议在动手前先回答这三个问题板卡的 DDR 初始化由谁来负责如果是 U-Boot 负责 DDR 初始化ATF 的 BL2 在加载 BL31 时可能还没有 DDR 可用那就需要在 BL2 阶段将 BL31 加载到 SRAM 里等 U-Boot 起来后再做一次低功耗驻留。如果是 ATF 的 BL2 负责 DDR 初始化那么 BL2 中需要集成厂商提供的 DDR 驱动这通常是最费时的部分。串口控制器的具体型号和寄存器基址是什么ATF 的早期启动打印离不开串口你需要确认你的串口芯片是否被drivers/uart下的某个驱动支持如果用的是 SoC 内部定制串口可能需要自己写一个简单的字符输出驱动。板卡有没有独立的电源管理控制器PMC如果需要支持 CPU 热插拔和深度睡眠就要确认如何与 PMC 通信是 MMIO 寄存器访问还是通过 SCPI 协议与另一个 M 核处理器通信。我这次移植用的是一个基于 Cortex-A72 的定制板卡4 核 CPUDDR4 内存串口用的是 SoC 内部的 8250 兼容控制器。目标是把 ATF 跑在 FVP 和 QEMU 环境上验证流程再对接实际板卡。下面我以这套环境为例给出从零开始移植的完整路径。3.2 基于现有参考平台搭出属于你的 plat 目录ATF 的plat/目录里已经提供了大量参考平台比如arm/board/fvp、arm/board/juno、qemu、nvidia/tegra、rockchip/rk3399等。选择参考平台时优先选与你的目标 SoC 架构最接近的可以节省大量工作。我这个项目基于 QEMU 虚拟环境和一块定制的 A72 开发板参考的是plat/qemu的目录结构。每个平台目录下基本都有这些文件plat/vendor/board/ ├── plat.mk # 平台构建配置定义需要编译哪些源文件 ├── platform_def.h # 平台宏定义内存布局、串口地址、GIC 地址等 ├── bl31_plat_setup.c # BL31 阶段平台初始化 ├── bl2_plat_setup.c # BL2 阶段平台初始化 ├── plat_topology.c # CPU 拓扑结构定义集群、核心、线程 ├── plat_pm.c # 电源管理操作函数 ├── plat_console.c # 控制台输出配置 ├── aarch64/platform_common.c # 共享平台函数 └── include/plat_macros.h # 平台辅助宏创建一个新平台的 ATMAll-to-Make最快路径是先复制一份 qemu 的目录到你自己的厂商目录下然后逐文件修改。改到能编译通过、能启动再逐步清掉不需要的代码。3.3 平台内存布局与platform_def.h配置platform_def.h是移植最容易出错的地方。它定义了 ATF 各个镜像的加载地址和数据存放地址。我在做第一个移植板时因为 DDR 地址配置错误BL31 加载完成跳转后直接跑飞串口上什么都没有输出排查了很久。下面是核心宏的说明以我的板卡为例如下#define PLAT_PRIMARY_CPU 0x0 #define PLAT_CLUSTER_COUNT 1 #define PLAT_MAX_CPUS_PER_CLUSTER 4 /* 内存布局 */ #define ARM_TRUSTED_SRAM_BASE 0x04000000 /* SRAM 基址 */ #define ARM_TRUSTED_SRAM_SIZE 0x00040000 /* SRAM 大小 256KB */ #define BL31_BASE 0x04000000 #define BL31_SIZE 0x00040000 #define BL32_BASE 0x04200000 #define BL32_SIZE 0x00040000 /* 串口信息 */ #define PLAT_ARM_UART_BASE 0x09000000 #define PLAT_ARM_UART_CLK_IN_HZ 24000000 #define PLAT_ARM_UART_BAUDRATE 115200 /* GIC 信息 */ #define PLAT_ARM_GICD_BASE 0x2f000000 #define PLAT_ARM_GICC_BASE 0x2c000000这里的核心逻辑是SRAM 必须够放下 BL31以及 BL32 可选所以 SRAM 的基址和大小要根据芯片手册确定。如果 SRAM 太小就必须考虑 XIP片上执行或加载到 DDR 后运行的模式但这会牺牲启动早期阶段的安全性。一般 Cortex-A 系列的 SoC 至少会留 256KB 到 1MB 的 SRAM 给 ATF实测 256KB 跑最小配置的 BL31 已经比较紧凑如果还要用 TBBR 安全启动和 TRNG 那就得规划仔细。PLAT_ARM_UART_BASE和时钟频率必须和你的板子实际一致否则串口打印乱码或者完全没有输出。在最早阶段调不通串口时我只能靠逻辑分析仪抓波形。3.4 构建流程与编译命令解析TF-A 的构建顶层用的是makefile配合平台目录下的plat.mk。编译一个 AArch64 平台的命令如下make CROSS_COMPILEaarch64-linux-gnu- \ PLATqemu \ DEBUG1 \ LOG_LEVEL40 \ BL33./u-boot/u-boot.bin \ ARM_TSP_RAM_LOCATIONtdram \ all fip几个重要参数说明PLATqemu指定平台名对应plat/qemu/目录。DEBUG1打开调试选项会保存更多符号信息日志输出也可以用。产品发布时务必改成DEBUG0关掉多余日志。LOG_LEVEL40是日志级别40 对应LOG_LEVEL_INFO如果排查问题可以调到 50VERBOSE会打出非常详细的 EL3 运行路径。BL33...需要指定 BL33 镜像U-Boot 或 UEFI特别是生成fip镜像时必须带上。all fip表示编译所有 BL 阶段并用fiptool打包生成fip.bin这是烧录到板卡的主镜像。如果不想每次手动传 BL33也可以先把BL33路径写到plat/qemu/platform.mk里。交叉编译工具链的选择值得多说一句。ATF 的交叉编译工具链一般用aarch64-linux-gnu-gcc或arm-none-eabi-gcc取决于你是否使用 newlib我个人更推荐aarch64-linux-gnu-gcc因为 ATF 的某些测试和工具链依赖 Linux 头文件。注意不要用 ARM Compiler 5AC5来编译 ATF。AC5 是老旧的 ARMCC 产物它不会生成 AArch64 代码。网上那些关于arm compiler 5.06u7 下载的内容基本都是针对裸机 STM32 这类 Cortex-M 平台或老旧的 ARM32 平台的ATF 的 AArch64 世界完全用不上。在 aarch64 生态里标准工具链要么是 ARM 官方的aarch64-none-elf-gcc要么是发行版自带的aarch64-linux-gnu-gcc。如果你在某个资源站搜索 AC5 想拿来编 ATF属于走错大门了。3.5 BL31 平台初始化函数详解BL31 的启动入口在lib/el3_common/aarch64/bl31_entrypoint.S它完成最底层的基础设置后跳转到 C 函数bl31_main然后依次调用平台初始化函数。这里我挑最重要的三个函数剖析一下。bl31_early_platform_setup是第一个被调用的平台函数主要做非常早期的硬件准备void bl31_early_platform_setup(void *from_bl2, void *plat_params_from_bl2) { /* 从 BL2 传递过来的内存信息不能直接信任必须做校验 */ assert(from_bl2 NULL); /* 初始化串口这是后续所有日志的先决条件 */ console_16550_register(PLAT_ARM_UART_BASE, PLAT_ARM_UART_CLK_IN_HZ, PLAT_ARM_UART_BAUDRATE); /* 配置 GIC 安全中断 */ plat_gic_driver_init(); plat_gic_init(); }我在移植时踩过一个坑console_16550_register之后我没有做console_set_scope的配置结果串口打印一会儿有一会儿没有后来发现是 Linux 内核起来后console 被重定向了。在 BL31 阶段建议把 console 的作用域设为CONSOLE_FLAG_BOOT和CONSOLE_FLAG_RUNTIME都打开保证运行期也能看到 PSCI 相关日志。bl31_plat_arch_setup用来配置 BL31 运行时的 MMU 和内存属性void bl31_plat_arch_setup(void) { /* 构建页表映射 BL31 的代码段、数据段和设备区域 */ mmap_add(bl31_mmap); init_xlat_tables(); enable_mmu_el3(0); }这个函数正常的流程是用 xlat table 库把设备内存映射为 Device 属性、把普通内存映射为 Normal 属性。如果你的 MMU 配置里把一个只有 Device 属性的外设映射成了普通内存编译器可能会对寄存器读写做合并或重排导致硬件行为诡异。这里建议用mmap_add_region单独为每个外设配置类型而不是用一个大 WHERE 区域覆盖全部地址空间。bl31_platform_setup是通用的平台初始化收尾点一般放定时器初始化、安全外设配置、SIP 服务的准备等。这些其实比较简单主要看你的板级需求。4. 安全固件工程审计实战从代码到硬件的信任链构建4.1 可信启动链Trusted Board Boot如何设计与验证安全固件审计最核心的就是信任链设计。ARM 的可信启动链Trusted Board Boot简称 TBBR思路非常直白从 BootROM被 SoC 出厂固化信任开始每一级固件必须验证下一级固件的签名和完整性通过验证才允许被执行。LF 整个流程中平台证书是沿着链式结构逐级签名的。BL1 在片内 ROM 中它验证 BL2 的镜像BL2 验证 BL31、BL32、BL33。每级镜像都有对应的数字证书证书里包含镜像的哈希值、签名和授权信息。ARM 提供了tools/cert_create来生成这些证书同时提供了tools/fiptool把证书和镜像打包成 FIP。我在实际项目中验证这套信任链时发现两个非常有价值的审计点第一BL2 是否强制校验密钥属性。如果你的产品有生产密钥、开发密钥之分那么 BL2 在验证镜像签名时不能仅仅验证密钥能解开还要验证密钥是谁的。在 ATF 里这通过Trusted Key Certificate的场景来管理如果配置不完整攻击者完全可以替换成自己的开发密钥签名镜像绕过整个安全启动。第二镜像哈希算法和密钥长度。ARM 默认推荐 RSA-2048但随着算力提升很多产品已经切换到 RSA-3072 或 ECC。ATF 在 v2.6 之后也支持 ECC 曲线。如果你要过国密合规还要自己改造认证算法ATF 提供了独立的auth_mod框架把完整性校验、签名验证抽象成模块化接口重写drivers/auth/mbedtls或加入自己的 crypto engine 驱动都是可行的。4.2 镜像认证与签名验证的代码路径ATF 里的认证框架代码主要位于drivers/auth/你用auth_mod接口注册认证方法和存储方法。启动时每个 BL 镜像的加载都会经过认证流程这个过程在bl2_main.c中可以被看到static int load_and_auth_image(unsigned int image_id, image_info_t *image_data) { /* 1. IO 层从存储设备读取镜像 */ /* 2. 解析镜像头部提取元数据 */ /* 3. 调用 auth_mod 验证签名 */ /* 4. 验证通过后返回镜像信息给加载器 */ }看代码时会发现 ATF 对证书的解析、哈希计算、公钥比较做了非常细致的校验检查字段长度是否小于负载长度、公钥指数是否为 65537、签名长度是否与 RSA 模长匹配。这些都是防绕过的基础。我在审计时一般会加一段负面测试故意篡改一个字节的 BL33 镜像确认启动被拦截在可信边界之外。4.3 固件安全审计的检查清单做固件工程审计不能只看启动代码还要评估运行时的安全状态。根据我的经验一份最关键的安全审计清单包含以下内容SMC 调用入口检查runtime_svc.c中是否有非法服务处理返回错误码是否泄漏敏感信息中断管理安全中断和普通中断的配置是否合理在 EL3 中断异常向量中是否关闭了不必要的路由内存隔离BL31 的内存是否对普通世界完全不可见MMU 页表中是否误映射了 BL31 的代码段给普通世界调试接口是否屏蔽了 JTAG/SWD 接口相关 fuse 在烧录后是否应该熔断证书库BL1 中用于验证 BL2 的根公钥是否被硬编码到 BootROM 的 eFuse 中是否允许固件升级期间修改密钥随机数源安全固件里的随机数是否来自硬件 TRNG而不是使用不安全的伪随机算法这些检查项我会整理成表格每项都关联对应的源码文件和风险等级。下面给出简化版供参考审计项关键文件风险等级操作建议SMC 服务校验services/std_svc/std_svc_setup.c高检查服务 ID 是否白名单化上下文切换完整性lib/el3_runtime/aarch64/context_mgmt.c高检查是否保存sctlr_el3、vbar_el3BL31 MMU 映射plat/board/bl31_plat_setup.c高确认 BL31 代码段为 RO外设区域为 Device证书链验证drivers/auth/auth_mod.c高确认不需要的哈希算法已关闭调试接口控制plat/board/include/platform_def.h中量产板关闭 DEBUG 和调试串口硬件 TRNG 初始化drivers/arm/trng/trng_*中确保 BL31 启动阶段完成了熵源初始化4.4 TBBR 工具链与镜像生成实操要在自己的平台开启 TBBR首先确保platform_def.h中定义了TRUSTED_BOARD_BOOT : 1。然后在plat.mk中增加CRT_KEYS : $(BUILD_PLAT)/keys $(eval $(call add_define,TRUSTED_BOARD_BOOT)) # 获取证书生成工具 $(eval $(call MAKE_TOOL,cert_create))生成密钥与证书的命令大致为make PLATqemu \ TBBR_BOOT1 \ GENERATE_COT1 \ ROT_KEYplat/qemu/keys/rot_key.pem \ BL33./u-boot/u-boot.bin \ all fip首次运行时 ATF 会生成多级密钥和证书。升级密钥链表上是rot_key.pem根密钥下面是bl31_key.pem、bl32_key.pem、bl33_key.pem、non_volatile_counter等。生产环境里根密钥的私钥必须离线保存并且建议放到 HSM 里避免开发机被入侵导致信任根泄露。生成完fip.bin后可以用fiptool查看内容./tools/fiptool/fiptool info fip.bin如果在fiptool info的输出中看到BL33有Certificate字段说明 TBBR 的证书已经正确嵌入。启动时如果认证失败BL2 会打印一条Authentication failed或Failed to load image的日志并停在安全状态等待复位。5. 实际运行和常见问题排查记录5.1 把 ATF 跑在 QEMU 上我在真正接触物理板卡前习惯先在 QEMU 上验证 ATF 的启动流程。QEMU 对 ARM 安全固件的模拟相当真实而且还支持 TrustZone这就给调试提供了极大的便利。具体操作qemu-system-aarch64 \ -machine virt,secureon \ -cpu cortex-a53 \ -smp 4 \ -m 1G \ -bios ./build/qemu/release/bl1.bin \ -nographic \ -device loader,file./build/qemu/release/fip.bin,addr0x04000000-bios bl1.bin直接模拟片上 ROM 初始化-device loader把 FIP 放到 BL2 期望的地址。启动后正常会看到 BL1、BL2、BL31、BL33 的串口输出最后进入 U-Boot 命令行。我在 QEMU 上验证时发现很多问题都不是代码问题而是版本和启动参数不匹配。如果 QEMU 版本较老对armv8.5或RME特性支持不全ATF 编译时如果开了相关 feature 就会启动失败。这类问题看错误日志很关键但日志可能只停在PANIC at PC : 0x...。这时可以先把平台相关的ERROR日志级别调高在串口输出来找线索。5.2 常见问题速查表我把实际移植和调试中遇到的高频问题整理成表格方便大家对照问题现象可能原因排查方向串口完全没有输出UART 地址/时钟配置错误BL1 未执行Debug 等级太低检查PLAT_ARM_UART_BASE用逻辑分析仪看 TX 波形提高LOG_LEVELATF 打印到 BL31 后停止BL31 基址与链接地址不一致DDR 初始化未完成就跳转查看bl31.elf的 entry 地址与BL31_BASE确认 DDR 在 BL2 阶段已可用U-Boot 启动后系统无 PSCI 支持BL31 未提供标准 PSCI 接口U-Boot 配置与 ATF 版本不匹配在 U-Boot 中启用CONFIG_ARM_PSCI_FW检查 SMC 调用是否返回正确安全世界挂死TEE 未启动BL32 镜像未打包到 FIPTSP 配置错误用fiptool info查看是否含 BL32检查ARM_TSP_RAM_LOCATION执行PSCI_CPU_ON时 CPU 启动失败对应 CPU 的核心上电序列没实现电源控制地址错误检查plat_pm.c中 cpu_on 操作以及 PMC 寄存器地址BL2 报Authentication failed密钥不匹配BL33 镜像被篡改哈希算法配置不一致核对ROT_KEY与证书链重新生成 FIP进入 U-Boot 后 reboot 命令失效U-Boot 只调用 PSCISYSTEM_RESET但平台实现没接复位控制检查plat_reset或system_off实现确认复位寄存器地址编译时报缺头文件platform_def.h平台目录未正确指定或源文件包含错误确认PLATboard参数大小写检查plat.mk中 INCLUDES 路径启动时 hang 在plat_setup阶段GIC 初始化失败定时器配置异常用编译器输出 map 文件定位 hang 在哪个函数地址断点调试5.3 排查实录一次 BL31 跳转进入 Linux 失败分享一下我印象最深的一次排查经历。当时我已经把 ATF 跑在了 QEMU 上BL1、BL2、BL31 都正常BL33U-Boot也能启动并引导内核但内核启动到一半就重启了。反复试了几次最后发现根本原因在 U-Boot 与 ATF 的 PSCI 配合上。U-Boot 有两种引导内核的电源管理方式一种是自己直接操作 CPU 寄存器一种是调用 ATF 的 PSCI 接口。我移植的 U-Boot 版本里CONFIG_ARM_PSCI_FW没有开启导致 U-Boot 尝试自己去核间启动但它的启动序列和 ATF 的 BL31 驻留产生了冲突。开启这个配置后U-Boot 不再自己操办电源管理而是把CPU_ON、CPU_OFF、SYSTEM_RESET这些请求都委托给 SMC由 BL31 统一处理问题就消失了。这个案例给我的启发是ATF 移植不能只盯着 ATF 自己的代码还要关注它与 U-Boot、Linux 之间的接口约定。特别是在做平台移植的时候方案设计阶段就要把 PSCI 的调用方协议定清楚否则后面调试电源管理问题时你会同时面对内核、U-Boot、ATF、SoC 四个层面的信息噪音。5.4 arm 交叉编译和工具链选择建议关于交叉编译我刚才提过 AC5 不适用于 AArch64 的 ATF。再强调一遍arm compiler 5.06、5.06u7 这类 ARMCC 工具链是给 Cortex-M/A-R 32 位架构用的老编译器编译 ATF 或者任何 AArch64 固件都是不适用的。我看到不少嵌入式新手在这个问题上走了弯路有人甚至下载了 AC5 然后费劲折腾半天编译不过最后发现方向错了。如果你做的是 Cortex-A 系列 AArch64 固件建议直接用# 安装 aarch64 交叉工具链 sudo apt install gcc-aarch64-linux-gnu或者从 ARM 官网下载AArch64 GNU/Linux toolchain版本选择最新的 LTS 即可。ATF 对 GCC 的版本要求不算苛刻但太老的 4.x 版本在某些ATTR特性上可能会报错建议至少用 GCC 8 以上。另外如果你需要把 BL33比如 U-Boot也交叉编译出来U-Boot 用同一套aarch64-linux-gnu-gcc编译完全没问题。如果你构建一个小根文件系统放在 SD 卡或 virtio 盘上可以先用busybox搭一个最小的rootfs方便在板子起来后验证各种常用命令工具这也是排查系统是否真正稳定运行的关键一步。之前我在一个项目里靠着往 rootfs 里临时塞了i2c-tools、mmc-utils这些 arm 工具才发现板卡的 eMMC 在BL31跑完进入 OS 后存在时钟配置不对的问题。5.5 关于系统挂起唤醒与 PSCI 深度睡眠的移植注意点电源管理中的深度睡眠affinity suspend是我遇到过代码最绕的设计之一。它牵扯到多级低功耗状态core、cluster、system每一级都有对应的进入与退出回调。ATF 的 PSCI 框架在psci_suspend.c里实现了一套状态机的运行逻辑但底层跟 SoC 强相关有的 SoC 要求 CPU 进入 WFI 前刷新 cache有的要求关闭 L2 电源前先保存 GIC 状态这些细节都必须写进你在plat_pm.c里实现的pwr_domain_suspend和pwr_domain_suspend_finisher。做这套操作时最危险的是乱序。假设你按手册里的步骤配置了寄存器但时序错了系统大概率会在唤醒时 hang 住。遇到这种问题我的建议是先在底层加串口 trace在进入低功耗前打印before suspend在唤醒后打印after resume通过日志确认它到底卡在哪一步。如果打印完before suspend后就没有后续那说明唤醒路径没有执行的入口很有可能是 reset vector 配置错误导致 CPU 醒来后跳到了一个空地址或安全配置异常的区域。现在的 ARM 系统里系统级低功耗SYSTEM_SUSPEND通常还会关联SCMI协议与运行在其它处理器核上的电源管理服务通信这种方案下消息传递的握手确认逻辑也是移植时容易遗漏的点。6. 高级主题RME、FF-A 与 ATF 的未来方向6.1 机密计算与 Realm 管理扩展近几年 ARM 在安全固件领域最大的变化是 RMERealm Management Extension的引入。RME 在原有的安全世界/普通世界基础上增加了 Realm 世界用于支持机密计算场景让 Linux 这样的普通世界根本不感知的机密虚拟机能在 Realm 世界里运行。ATF 的 master 分支里可以看到lib/gpt_rme相关的代码它实现了 GPTGranule Protection Table的初始化和管理这是 RME 的核心机制之一。从工程审计视角看RME 给 ATF 带来的复杂度提升是显著大于传统的 TBBR 的。因为 GPT 的颗粒检查、状态转换、Realm 世界与正常世界的共享内存管理每一环都可能成为攻击面。目前很多 SoC 厂商还没有完整支持 RME但从设计方向看未来做 ARM 安全固件的人迟早要过这一关。6.2 FF-A 与虚拟机间安全通信FF-AFirmware Framework for Arm A-profile是 ARM 定义的另一个重要规范它的目标是标准化安全世界/普通世界之间的通信取代老旧的SMC调用约定。ATF 里已经有services/ff-a的相关实现比如用 FF-A 规范的direct message传递函数调用。做高安全等级的产品时想把 TEE 功能提供给多个普通世界分区使用FF-A 会是一个更规范的方案。不过实话实话FF-A 在生态上的落地速度没有想象中快不少厂商仍然基于旧的 OP-TEE SMC 方式工作。如果你不急着上马高度虚拟化的机密计算场景可以先在不改动架构的前提下保持对 FF-A 规范的关注。6.3 移植到新平台前需要关注的 LTS 分支选择TF-A 的发版节奏里LTS 分支会比 master 保守很多。我个人的教训是凡是直接用于量产的平台一定切换到 LTS 分支而不是追踪 master。LTS 分支会周期性合入修复 CVE 的安全补丁API 变化较小编译工具链和下游 U-Boot 的兼容性也更好。你在用git clone拉取 ATF 源码时可以显式选择 LTS 分支git clone --branch lts-v2.8 https://github.com/ARM-software/arm-trusted-firmware.git然后在make之前看一下docs/plat/下的移植指南确认这个版本与你要用的 U-Boot、OP-TEE 版本是否匹配。ATF、OP-TEE、U-Boot、Linux 四者的版本匹配关系我建议你固定成一组不要单独升其中一个否则容易出兼容性问题。6.4 从跑通到能用平台移植的完整交付建议很多朋友做 ATF 移植止步于启动打印通过了或Linux 能起来了但在真实产品上线前这部分工作还远远不够。我的经验是一个合格的 ATF 移植交付至少要包含以下内容BL31 常驻稳定性跑压力测试让系统反复执行reboot、suspend/resume、CPU hotplug至少几百次不出问题。安全启动验证报告完整记录ROT_KEY生成、证书链签名、镜像烧录、验证启动的全流程并附上验证成功的串口日志。安全审计清单如果这个产品会过 CCC、FIPS 或者等保ATF 只是信任链的一部分需要配合 Root of Trust、密钥管理、安全存储一起说明。构建复现文档记录你的make命令行、编译工具链版本、BL33 和 TEE 的 commit保证 team member 可以复现你的完整构建。我在实际项目里还养成了一个习惯每次移植完成都会把编译好的fip.bin和对应的bl31.elf保存到专门的 build artifact 仓库里并记录提交哈希。否则两个月后回来找问题连当时烧到板子上的镜像到底是哪个版本都说不清那种感觉实在太痛苦了。最后再分享一个小技巧调 ATF 问题时不要只盯着 ATF 自身的日志把BL33U-Boot的CONFIG_LOGLEVEL和 Linux 内核的earlycon都打开会给你很多跨层排查的线索。我见过太多的ATF 问题其实是 U-Boot 的 DTS 配置、内核 PSCI 驱动版本或者 bootloader 传递参数的问题全链路日志一开往往十分钟内就能定位。做底层固件就是这样很多问题不是难度高而是信息不够。先把日志铺开再把耐心准备好剩下的事情就顺理成章了。 
长河君 · 2026/9/9 3:35:45 · 阅读 1.2k ARM Trusted Firmware深度解析：架构、安全审计与平台移植实践
ARM Trusted Firmware 深度源码评测ATF 架构全景梳理、安全固件工程审计与平台移植落地指南这两年我在嵌入式安全领域摸爬滚打接触最多、也最绕不开的一个基础组件就是 ARM Trusted FirmwareATF。不管是做手机 Secure Boot、平板固件安全升级还是边缘网关的可信启动链ATF 几乎都是绕不开的第一道关口。它跑在 Linux 内核之下、硬件之上负责把 CPU 从 EL3 安全世界带到 EL1 内核世界同时承担着 PSCI 电源管理、安全监控模式切换、可信启动认证这些底层脏活累活。这篇文章我准备从源码层面拆解 ATF 的架构全景聊聊做固件工程审计时应该重点盯哪些文件和调用链最后分享一下我在平台移植过程中的完整落地步骤和踩坑实录。内容主要来自这一年来基于实际项目对 ATF 源码的持续阅读和移植验证希望能帮到正在做 ARM 底层固件、Secure Boot 方案选型或正准备把 ATF 移植到新板卡上的朋友。先说明一下文章里的源码分析基于 TF-A 的 LTS 分支v2.8 系列同时我会穿插一些 master 分支上的新特性对比。如果你手头的代码版本不同行号和宏定义可能会有出入但核心架构和调用链基本一致。1. ATF 在 ARM 启动流程中的位置与核心价值1.1 ATF 解决了什么问题很多人第一次接触 ATF 时会被它的名字吓到觉得它是一个庞然大物。其实 ATF 的定位非常聚焦它是 ARM 平台上安全世界的固件参考实现提供了从片上 ROM 启动到内核运行之间那段真空地带的标准化方案。在 ATF 出现之前各家 SoC 厂商在 BootROM 之后几乎都是各搞一套安全监控模式的代码千奇百怪也没有统一的电源状态协调接口。ATF 的价值在于它把 EL3 异常等级下的安全监控模式、电源管理、可信启动这些能力做成了一个可复用的标准框架。用生活类比来理解如果 Linux 内核是一个公司的业务部门那 ATF 就是这家公司的保安系统和物业总管。保安系统负责验证每一个进入公司的人是否持有合法工牌Trusted Boot 认证物业总管负责在业务部门休息时管理大楼的照明和电力分配PSCI 电源管理。业务部门自己在正常工作时间做业务但上下班开关门、凌晨停电如何恢复这些都归物业和保安管。1.2 启动链路全景BL1、BL2、BL31、BL32、BL33 的接力赛我在刚开始读 ATF 源码时最大的困惑是它的启动流程里为什么会有这么多 BLBoot Loader阶段。后来跟着代码走了一遍才明白这其实是一场严格分工的接力赛。整个启动链路从 SoC 出厂固化的 BootROM 开始BL1存放在片上 ROM 或一次性可编程存储中是复位后的第一个可执行代码负责初始化最小硬件环境把 BL2 从外部存储加载到 SRAM 并完成安全认证然后跳转过去。BL1 的代码量最小但容错要求最高。BL2运行在 EL3 下的可信启动固件负责初始化 DDR、加载 BL31和可选的 BL32到内存执行镜像签名验证验证通过后跳转到 BL31。BL31常驻内存的 EL3 运行时固件包含 Secure Monitor、PSCI 电源管理实现、SMC 调度器是 ATF 中最核心的物业总管。BL32可选的 Trusted OS如 OP-TEE运行在 S-EL1通过 SMC 与 BL31 通信。如果你的产品不需要 TEE这个阶段可以跳过。BL33就是我们常说的 U-Boot 或 UEFI运行在 EL2/EL1最终引导 Linux 内核。关于 BL31 和 U-Boot 的关系很多做上层开发的朋友容易混淆。BL31 运行在 EL3U-Boot 运行在 EL2/EL1两者的职责完全不同。U-Boot 阶段如果需要做电源管理相关操作比如 CPU 热插拔、系统挂起唤醒必须通过 SMC 指令陷入 EL3由 BL31 里的 PSCI 实现来真正操作硬件寄存器。这也是为什么 ATF 经常和 U-Boot 一起出现在启动代链中——它们在异常等级上是上下级关系。1.3 异常等级与安全状态模型理解 ATF 绕不开 ARM 的异常等级模型。ARMv8-A 定义了四个异常等级从 EL0 到 EL3数字越大特权越高。系统复位后 CPU 默认进入 EL3ATF 的 BL1/BL2/BL31 都在这个等级运行。EL2 通常跑虚拟化层HypervisorEL1 跑操作系统内核EL0 跑用户态应用。ATF 架构里还有一个非常重要的概念安全世界Secure World和普通世界Normal World。这两个世界共享同一套 CPU 物理资源但通过 TrustZone 技术做了隔离。Linux 运行在普通世界TEE 运行在安全世界两个世界之间的切换必须经过 EL3 的 Secure Monitor也就是 BL31 里的bl31_main和上下文管理模块。每次切换都需要保存和恢复完整的 CPU 上下文这部分代码在context_mgmt.c里是 ATF 中极其考验细节的地方。2. ATF 源码结构全景与关键目录审计2.1 源码顶层目录速览我习惯拿到一份源码先看目录结构因为目录设计通常反映了整个工程的核心模块划分。TF-A 的顶层目录并不复杂但每个目录的职责非常清晰tf-a/ ├── bl1/ # BL1 阶段源码 ├── bl2/ # BL2 阶段源码 ├── bl31/ # BL31 阶段源码 ├── bl32/ # BL32TEE 入口相关代码 ├── common/ # 各 BL 阶段共享的通用代码 ├── drivers/ # 驱动串口、定时器、IO 存储、认证加密等 ├── lib/ # 核心库el3_runtime、psci、stack_protector 等 ├── plat/ # 平台移植代码核心工作区 ├── services/ # 运行时服务SMC 调度、std_svc、trng 等 ├── include/ # 全局头文件 ├── tools/ # 构建与镜像处理工具cert_create、fiptool 等 ├── makefile # 顶层构建入口 └── docs/ # 设计文档与移植指南从工程审计的角度看plat/目录是每次必看的因为这是芯片厂商和方案商修改最集中的地方。lib/el3_runtime/里的上下文切换代码、lib/psci/里的电源管理框架、services/里的 SMC 调度器则决定了这个信任根实现是否健壮。2.2 核心库源码审计要点el3_runtime这个目录下主要是 AArch64 的异常进入与退出实现以及上下文管理。context_mgmt.c负责维护安全世界和普通世界的上下文结构体每一个cpu_context都保存了通用寄存器、系统寄存器、SVE 寄存器状态。在做安全审计时我重点检查的是上下文切换时是否完整保存了所有相关寄存器尤其是vbar_el3、sctlr_el3这类影响安全策略的系统寄存器。psciPSCIPower State Coordination Interface是 ARM 定义的电源管理接口标准。ATF 里的实现分成两层上层是 PSCI 服务框架负责解析 SMC 请求、校验参数、分发调用底层是平台操作函数比如platform_cpu_pwr_down、platform_cpu_suspend这些需要移植时在平台代码里实现或者引入 scpi/sip 等协议与下游的电源管理处理器通信。做移植的朋友可以重点看psci_setup.c里的初始化顺序以及psci_cpu_on.c的启动流程。el3_common这里存放 EL3 阶段共用的初始化代码包括 cache 使能、MMU 配置、异常向量表设置。BL31 的入口bl31_entrypoint.S就在这里是整个安全固件运行起来的第一行汇编。我在审计时习惯先看这段汇编确认启动时 CPU 处于什么状态、需要规避哪些硬件 bug。2.3 运行时服务与 SMC 调度机制ATF 启动完成后主要工作就是响应普通世界的 SMC 请求。所有 SMC 请求进入 EL3 后都会先经过runtime_svc.c里的分发逻辑。这个逻辑非常精巧SMC 指令的函数 ID 编码里包含了服务类型、调用类型等信息ATF 根据这些字段决定将请求转给哪个运行时服务。标准服务std_svc通常处理 PSCI 请求比如PSCI_CPU_ON、PSCI_CPU_OFF、PSCI_SYSTEM_SUSPEND。SiPSilicon Provider服务则留给芯片厂商实现私有功能比如厂商特有的安全配置、温度读取、AB 分区切换等。这里有个容易忽略的审计点SMC 返回值是否对调用者做了合法检查。一个负责任的安全固件必须在进入具体服务处理前验证调用者位于普通世界还是安全世界、请求的服务 ID 是否被允许。在runtime_svc.c的runtime_svc_init和handle_runtime_svc流程里这些检查逻辑是否完整决定了整个系统安全边界的强度。3. 平台移植落地实操从零适配一块自定义 ARM 板卡3.1 移植前必须搞清楚的几个问题很多初学者拿到一块新板子第一反应是直接照抄参考平台的代码。这个思路没错但容易翻车。我建议在动手前先回答这三个问题板卡的 DDR 初始化由谁来负责如果是 U-Boot 负责 DDR 初始化ATF 的 BL2 在加载 BL31 时可能还没有 DDR 可用那就需要在 BL2 阶段将 BL31 加载到 SRAM 里等 U-Boot 起来后再做一次低功耗驻留。如果是 ATF 的 BL2 负责 DDR 初始化那么 BL2 中需要集成厂商提供的 DDR 驱动这通常是最费时的部分。串口控制器的具体型号和寄存器基址是什么ATF 的早期启动打印离不开串口你需要确认你的串口芯片是否被drivers/uart下的某个驱动支持如果用的是 SoC 内部定制串口可能需要自己写一个简单的字符输出驱动。板卡有没有独立的电源管理控制器PMC如果需要支持 CPU 热插拔和深度睡眠就要确认如何与 PMC 通信是 MMIO 寄存器访问还是通过 SCPI 协议与另一个 M 核处理器通信。我这次移植用的是一个基于 Cortex-A72 的定制板卡4 核 CPUDDR4 内存串口用的是 SoC 内部的 8250 兼容控制器。目标是把 ATF 跑在 FVP 和 QEMU 环境上验证流程再对接实际板卡。下面我以这套环境为例给出从零开始移植的完整路径。3.2 基于现有参考平台搭出属于你的 plat 目录ATF 的plat/目录里已经提供了大量参考平台比如arm/board/fvp、arm/board/juno、qemu、nvidia/tegra、rockchip/rk3399等。选择参考平台时优先选与你的目标 SoC 架构最接近的可以节省大量工作。我这个项目基于 QEMU 虚拟环境和一块定制的 A72 开发板参考的是plat/qemu的目录结构。每个平台目录下基本都有这些文件plat/vendor/board/ ├── plat.mk # 平台构建配置定义需要编译哪些源文件 ├── platform_def.h # 平台宏定义内存布局、串口地址、GIC 地址等 ├── bl31_plat_setup.c # BL31 阶段平台初始化 ├── bl2_plat_setup.c # BL2 阶段平台初始化 ├── plat_topology.c # CPU 拓扑结构定义集群、核心、线程 ├── plat_pm.c # 电源管理操作函数 ├── plat_console.c # 控制台输出配置 ├── aarch64/platform_common.c # 共享平台函数 └── include/plat_macros.h # 平台辅助宏创建一个新平台的 ATMAll-to-Make最快路径是先复制一份 qemu 的目录到你自己的厂商目录下然后逐文件修改。改到能编译通过、能启动再逐步清掉不需要的代码。3.3 平台内存布局与platform_def.h配置platform_def.h是移植最容易出错的地方。它定义了 ATF 各个镜像的加载地址和数据存放地址。我在做第一个移植板时因为 DDR 地址配置错误BL31 加载完成跳转后直接跑飞串口上什么都没有输出排查了很久。下面是核心宏的说明以我的板卡为例如下#define PLAT_PRIMARY_CPU 0x0 #define PLAT_CLUSTER_COUNT 1 #define PLAT_MAX_CPUS_PER_CLUSTER 4 /* 内存布局 */ #define ARM_TRUSTED_SRAM_BASE 0x04000000 /* SRAM 基址 */ #define ARM_TRUSTED_SRAM_SIZE 0x00040000 /* SRAM 大小 256KB */ #define BL31_BASE 0x04000000 #define BL31_SIZE 0x00040000 #define BL32_BASE 0x04200000 #define BL32_SIZE 0x00040000 /* 串口信息 */ #define PLAT_ARM_UART_BASE 0x09000000 #define PLAT_ARM_UART_CLK_IN_HZ 24000000 #define PLAT_ARM_UART_BAUDRATE 115200 /* GIC 信息 */ #define PLAT_ARM_GICD_BASE 0x2f000000 #define PLAT_ARM_GICC_BASE 0x2c000000这里的核心逻辑是SRAM 必须够放下 BL31以及 BL32 可选所以 SRAM 的基址和大小要根据芯片手册确定。如果 SRAM 太小就必须考虑 XIP片上执行或加载到 DDR 后运行的模式但这会牺牲启动早期阶段的安全性。一般 Cortex-A 系列的 SoC 至少会留 256KB 到 1MB 的 SRAM 给 ATF实测 256KB 跑最小配置的 BL31 已经比较紧凑如果还要用 TBBR 安全启动和 TRNG 那就得规划仔细。PLAT_ARM_UART_BASE和时钟频率必须和你的板子实际一致否则串口打印乱码或者完全没有输出。在最早阶段调不通串口时我只能靠逻辑分析仪抓波形。3.4 构建流程与编译命令解析TF-A 的构建顶层用的是makefile配合平台目录下的plat.mk。编译一个 AArch64 平台的命令如下make CROSS_COMPILEaarch64-linux-gnu- \ PLATqemu \ DEBUG1 \ LOG_LEVEL40 \ BL33./u-boot/u-boot.bin \ ARM_TSP_RAM_LOCATIONtdram \ all fip几个重要参数说明PLATqemu指定平台名对应plat/qemu/目录。DEBUG1打开调试选项会保存更多符号信息日志输出也可以用。产品发布时务必改成DEBUG0关掉多余日志。LOG_LEVEL40是日志级别40 对应LOG_LEVEL_INFO如果排查问题可以调到 50VERBOSE会打出非常详细的 EL3 运行路径。BL33...需要指定 BL33 镜像U-Boot 或 UEFI特别是生成fip镜像时必须带上。all fip表示编译所有 BL 阶段并用fiptool打包生成fip.bin这是烧录到板卡的主镜像。如果不想每次手动传 BL33也可以先把BL33路径写到plat/qemu/platform.mk里。交叉编译工具链的选择值得多说一句。ATF 的交叉编译工具链一般用aarch64-linux-gnu-gcc或arm-none-eabi-gcc取决于你是否使用 newlib我个人更推荐aarch64-linux-gnu-gcc因为 ATF 的某些测试和工具链依赖 Linux 头文件。注意不要用 ARM Compiler 5AC5来编译 ATF。AC5 是老旧的 ARMCC 产物它不会生成 AArch64 代码。网上那些关于arm compiler 5.06u7 下载的内容基本都是针对裸机 STM32 这类 Cortex-M 平台或老旧的 ARM32 平台的ATF 的 AArch64 世界完全用不上。在 aarch64 生态里标准工具链要么是 ARM 官方的aarch64-none-elf-gcc要么是发行版自带的aarch64-linux-gnu-gcc。如果你在某个资源站搜索 AC5 想拿来编 ATF属于走错大门了。3.5 BL31 平台初始化函数详解BL31 的启动入口在lib/el3_common/aarch64/bl31_entrypoint.S它完成最底层的基础设置后跳转到 C 函数bl31_main然后依次调用平台初始化函数。这里我挑最重要的三个函数剖析一下。bl31_early_platform_setup是第一个被调用的平台函数主要做非常早期的硬件准备void bl31_early_platform_setup(void *from_bl2, void *plat_params_from_bl2) { /* 从 BL2 传递过来的内存信息不能直接信任必须做校验 */ assert(from_bl2 NULL); /* 初始化串口这是后续所有日志的先决条件 */ console_16550_register(PLAT_ARM_UART_BASE, PLAT_ARM_UART_CLK_IN_HZ, PLAT_ARM_UART_BAUDRATE); /* 配置 GIC 安全中断 */ plat_gic_driver_init(); plat_gic_init(); }我在移植时踩过一个坑console_16550_register之后我没有做console_set_scope的配置结果串口打印一会儿有一会儿没有后来发现是 Linux 内核起来后console 被重定向了。在 BL31 阶段建议把 console 的作用域设为CONSOLE_FLAG_BOOT和CONSOLE_FLAG_RUNTIME都打开保证运行期也能看到 PSCI 相关日志。bl31_plat_arch_setup用来配置 BL31 运行时的 MMU 和内存属性void bl31_plat_arch_setup(void) { /* 构建页表映射 BL31 的代码段、数据段和设备区域 */ mmap_add(bl31_mmap); init_xlat_tables(); enable_mmu_el3(0); }这个函数正常的流程是用 xlat table 库把设备内存映射为 Device 属性、把普通内存映射为 Normal 属性。如果你的 MMU 配置里把一个只有 Device 属性的外设映射成了普通内存编译器可能会对寄存器读写做合并或重排导致硬件行为诡异。这里建议用mmap_add_region单独为每个外设配置类型而不是用一个大 WHERE 区域覆盖全部地址空间。bl31_platform_setup是通用的平台初始化收尾点一般放定时器初始化、安全外设配置、SIP 服务的准备等。这些其实比较简单主要看你的板级需求。4. 安全固件工程审计实战从代码到硬件的信任链构建4.1 可信启动链Trusted Board Boot如何设计与验证安全固件审计最核心的就是信任链设计。ARM 的可信启动链Trusted Board Boot简称 TBBR思路非常直白从 BootROM被 SoC 出厂固化信任开始每一级固件必须验证下一级固件的签名和完整性通过验证才允许被执行。LF 整个流程中平台证书是沿着链式结构逐级签名的。BL1 在片内 ROM 中它验证 BL2 的镜像BL2 验证 BL31、BL32、BL33。每级镜像都有对应的数字证书证书里包含镜像的哈希值、签名和授权信息。ARM 提供了tools/cert_create来生成这些证书同时提供了tools/fiptool把证书和镜像打包成 FIP。我在实际项目中验证这套信任链时发现两个非常有价值的审计点第一BL2 是否强制校验密钥属性。如果你的产品有生产密钥、开发密钥之分那么 BL2 在验证镜像签名时不能仅仅验证密钥能解开还要验证密钥是谁的。在 ATF 里这通过Trusted Key Certificate的场景来管理如果配置不完整攻击者完全可以替换成自己的开发密钥签名镜像绕过整个安全启动。第二镜像哈希算法和密钥长度。ARM 默认推荐 RSA-2048但随着算力提升很多产品已经切换到 RSA-3072 或 ECC。ATF 在 v2.6 之后也支持 ECC 曲线。如果你要过国密合规还要自己改造认证算法ATF 提供了独立的auth_mod框架把完整性校验、签名验证抽象成模块化接口重写drivers/auth/mbedtls或加入自己的 crypto engine 驱动都是可行的。4.2 镜像认证与签名验证的代码路径ATF 里的认证框架代码主要位于drivers/auth/你用auth_mod接口注册认证方法和存储方法。启动时每个 BL 镜像的加载都会经过认证流程这个过程在bl2_main.c中可以被看到static int load_and_auth_image(unsigned int image_id, image_info_t *image_data) { /* 1. IO 层从存储设备读取镜像 */ /* 2. 解析镜像头部提取元数据 */ /* 3. 调用 auth_mod 验证签名 */ /* 4. 验证通过后返回镜像信息给加载器 */ }看代码时会发现 ATF 对证书的解析、哈希计算、公钥比较做了非常细致的校验检查字段长度是否小于负载长度、公钥指数是否为 65537、签名长度是否与 RSA 模长匹配。这些都是防绕过的基础。我在审计时一般会加一段负面测试故意篡改一个字节的 BL33 镜像确认启动被拦截在可信边界之外。4.3 固件安全审计的检查清单做固件工程审计不能只看启动代码还要评估运行时的安全状态。根据我的经验一份最关键的安全审计清单包含以下内容SMC 调用入口检查runtime_svc.c中是否有非法服务处理返回错误码是否泄漏敏感信息中断管理安全中断和普通中断的配置是否合理在 EL3 中断异常向量中是否关闭了不必要的路由内存隔离BL31 的内存是否对普通世界完全不可见MMU 页表中是否误映射了 BL31 的代码段给普通世界调试接口是否屏蔽了 JTAG/SWD 接口相关 fuse 在烧录后是否应该熔断证书库BL1 中用于验证 BL2 的根公钥是否被硬编码到 BootROM 的 eFuse 中是否允许固件升级期间修改密钥随机数源安全固件里的随机数是否来自硬件 TRNG而不是使用不安全的伪随机算法这些检查项我会整理成表格每项都关联对应的源码文件和风险等级。下面给出简化版供参考审计项关键文件风险等级操作建议SMC 服务校验services/std_svc/std_svc_setup.c高检查服务 ID 是否白名单化上下文切换完整性lib/el3_runtime/aarch64/context_mgmt.c高检查是否保存sctlr_el3、vbar_el3BL31 MMU 映射plat/board/bl31_plat_setup.c高确认 BL31 代码段为 RO外设区域为 Device证书链验证drivers/auth/auth_mod.c高确认不需要的哈希算法已关闭调试接口控制plat/board/include/platform_def.h中量产板关闭 DEBUG 和调试串口硬件 TRNG 初始化drivers/arm/trng/trng_*中确保 BL31 启动阶段完成了熵源初始化4.4 TBBR 工具链与镜像生成实操要在自己的平台开启 TBBR首先确保platform_def.h中定义了TRUSTED_BOARD_BOOT : 1。然后在plat.mk中增加CRT_KEYS : $(BUILD_PLAT)/keys $(eval $(call add_define,TRUSTED_BOARD_BOOT)) # 获取证书生成工具 $(eval $(call MAKE_TOOL,cert_create))生成密钥与证书的命令大致为make PLATqemu \ TBBR_BOOT1 \ GENERATE_COT1 \ ROT_KEYplat/qemu/keys/rot_key.pem \ BL33./u-boot/u-boot.bin \ all fip首次运行时 ATF 会生成多级密钥和证书。升级密钥链表上是rot_key.pem根密钥下面是bl31_key.pem、bl32_key.pem、bl33_key.pem、non_volatile_counter等。生产环境里根密钥的私钥必须离线保存并且建议放到 HSM 里避免开发机被入侵导致信任根泄露。生成完fip.bin后可以用fiptool查看内容./tools/fiptool/fiptool info fip.bin如果在fiptool info的输出中看到BL33有Certificate字段说明 TBBR 的证书已经正确嵌入。启动时如果认证失败BL2 会打印一条Authentication failed或Failed to load image的日志并停在安全状态等待复位。5. 实际运行和常见问题排查记录5.1 把 ATF 跑在 QEMU 上我在真正接触物理板卡前习惯先在 QEMU 上验证 ATF 的启动流程。QEMU 对 ARM 安全固件的模拟相当真实而且还支持 TrustZone这就给调试提供了极大的便利。具体操作qemu-system-aarch64 \ -machine virt,secureon \ -cpu cortex-a53 \ -smp 4 \ -m 1G \ -bios ./build/qemu/release/bl1.bin \ -nographic \ -device loader,file./build/qemu/release/fip.bin,addr0x04000000-bios bl1.bin直接模拟片上 ROM 初始化-device loader把 FIP 放到 BL2 期望的地址。启动后正常会看到 BL1、BL2、BL31、BL33 的串口输出最后进入 U-Boot 命令行。我在 QEMU 上验证时发现很多问题都不是代码问题而是版本和启动参数不匹配。如果 QEMU 版本较老对armv8.5或RME特性支持不全ATF 编译时如果开了相关 feature 就会启动失败。这类问题看错误日志很关键但日志可能只停在PANIC at PC : 0x...。这时可以先把平台相关的ERROR日志级别调高在串口输出来找线索。5.2 常见问题速查表我把实际移植和调试中遇到的高频问题整理成表格方便大家对照问题现象可能原因排查方向串口完全没有输出UART 地址/时钟配置错误BL1 未执行Debug 等级太低检查PLAT_ARM_UART_BASE用逻辑分析仪看 TX 波形提高LOG_LEVELATF 打印到 BL31 后停止BL31 基址与链接地址不一致DDR 初始化未完成就跳转查看bl31.elf的 entry 地址与BL31_BASE确认 DDR 在 BL2 阶段已可用U-Boot 启动后系统无 PSCI 支持BL31 未提供标准 PSCI 接口U-Boot 配置与 ATF 版本不匹配在 U-Boot 中启用CONFIG_ARM_PSCI_FW检查 SMC 调用是否返回正确安全世界挂死TEE 未启动BL32 镜像未打包到 FIPTSP 配置错误用fiptool info查看是否含 BL32检查ARM_TSP_RAM_LOCATION执行PSCI_CPU_ON时 CPU 启动失败对应 CPU 的核心上电序列没实现电源控制地址错误检查plat_pm.c中 cpu_on 操作以及 PMC 寄存器地址BL2 报Authentication failed密钥不匹配BL33 镜像被篡改哈希算法配置不一致核对ROT_KEY与证书链重新生成 FIP进入 U-Boot 后 reboot 命令失效U-Boot 只调用 PSCISYSTEM_RESET但平台实现没接复位控制检查plat_reset或system_off实现确认复位寄存器地址编译时报缺头文件platform_def.h平台目录未正确指定或源文件包含错误确认PLATboard参数大小写检查plat.mk中 INCLUDES 路径启动时 hang 在plat_setup阶段GIC 初始化失败定时器配置异常用编译器输出 map 文件定位 hang 在哪个函数地址断点调试5.3 排查实录一次 BL31 跳转进入 Linux 失败分享一下我印象最深的一次排查经历。当时我已经把 ATF 跑在了 QEMU 上BL1、BL2、BL31 都正常BL33U-Boot也能启动并引导内核但内核启动到一半就重启了。反复试了几次最后发现根本原因在 U-Boot 与 ATF 的 PSCI 配合上。U-Boot 有两种引导内核的电源管理方式一种是自己直接操作 CPU 寄存器一种是调用 ATF 的 PSCI 接口。我移植的 U-Boot 版本里CONFIG_ARM_PSCI_FW没有开启导致 U-Boot 尝试自己去核间启动但它的启动序列和 ATF 的 BL31 驻留产生了冲突。开启这个配置后U-Boot 不再自己操办电源管理而是把CPU_ON、CPU_OFF、SYSTEM_RESET这些请求都委托给 SMC由 BL31 统一处理问题就消失了。这个案例给我的启发是ATF 移植不能只盯着 ATF 自己的代码还要关注它与 U-Boot、Linux 之间的接口约定。特别是在做平台移植的时候方案设计阶段就要把 PSCI 的调用方协议定清楚否则后面调试电源管理问题时你会同时面对内核、U-Boot、ATF、SoC 四个层面的信息噪音。5.4 arm 交叉编译和工具链选择建议关于交叉编译我刚才提过 AC5 不适用于 AArch64 的 ATF。再强调一遍arm compiler 5.06、5.06u7 这类 ARMCC 工具链是给 Cortex-M/A-R 32 位架构用的老编译器编译 ATF 或者任何 AArch64 固件都是不适用的。我看到不少嵌入式新手在这个问题上走了弯路有人甚至下载了 AC5 然后费劲折腾半天编译不过最后发现方向错了。如果你做的是 Cortex-A 系列 AArch64 固件建议直接用# 安装 aarch64 交叉工具链 sudo apt install gcc-aarch64-linux-gnu或者从 ARM 官网下载AArch64 GNU/Linux toolchain版本选择最新的 LTS 即可。ATF 对 GCC 的版本要求不算苛刻但太老的 4.x 版本在某些ATTR特性上可能会报错建议至少用 GCC 8 以上。另外如果你需要把 BL33比如 U-Boot也交叉编译出来U-Boot 用同一套aarch64-linux-gnu-gcc编译完全没问题。如果你构建一个小根文件系统放在 SD 卡或 virtio 盘上可以先用busybox搭一个最小的rootfs方便在板子起来后验证各种常用命令工具这也是排查系统是否真正稳定运行的关键一步。之前我在一个项目里靠着往 rootfs 里临时塞了i2c-tools、mmc-utils这些 arm 工具才发现板卡的 eMMC 在BL31跑完进入 OS 后存在时钟配置不对的问题。5.5 关于系统挂起唤醒与 PSCI 深度睡眠的移植注意点电源管理中的深度睡眠affinity suspend是我遇到过代码最绕的设计之一。它牵扯到多级低功耗状态core、cluster、system每一级都有对应的进入与退出回调。ATF 的 PSCI 框架在psci_suspend.c里实现了一套状态机的运行逻辑但底层跟 SoC 强相关有的 SoC 要求 CPU 进入 WFI 前刷新 cache有的要求关闭 L2 电源前先保存 GIC 状态这些细节都必须写进你在plat_pm.c里实现的pwr_domain_suspend和pwr_domain_suspend_finisher。做这套操作时最危险的是乱序。假设你按手册里的步骤配置了寄存器但时序错了系统大概率会在唤醒时 hang 住。遇到这种问题我的建议是先在底层加串口 trace在进入低功耗前打印before suspend在唤醒后打印after resume通过日志确认它到底卡在哪一步。如果打印完before suspend后就没有后续那说明唤醒路径没有执行的入口很有可能是 reset vector 配置错误导致 CPU 醒来后跳到了一个空地址或安全配置异常的区域。现在的 ARM 系统里系统级低功耗SYSTEM_SUSPEND通常还会关联SCMI协议与运行在其它处理器核上的电源管理服务通信这种方案下消息传递的握手确认逻辑也是移植时容易遗漏的点。6. 高级主题RME、FF-A 与 ATF 的未来方向6.1 机密计算与 Realm 管理扩展近几年 ARM 在安全固件领域最大的变化是 RMERealm Management Extension的引入。RME 在原有的安全世界/普通世界基础上增加了 Realm 世界用于支持机密计算场景让 Linux 这样的普通世界根本不感知的机密虚拟机能在 Realm 世界里运行。ATF 的 master 分支里可以看到lib/gpt_rme相关的代码它实现了 GPTGranule Protection Table的初始化和管理这是 RME 的核心机制之一。从工程审计视角看RME 给 ATF 带来的复杂度提升是显著大于传统的 TBBR 的。因为 GPT 的颗粒检查、状态转换、Realm 世界与正常世界的共享内存管理每一环都可能成为攻击面。目前很多 SoC 厂商还没有完整支持 RME但从设计方向看未来做 ARM 安全固件的人迟早要过这一关。6.2 FF-A 与虚拟机间安全通信FF-AFirmware Framework for Arm A-profile是 ARM 定义的另一个重要规范它的目标是标准化安全世界/普通世界之间的通信取代老旧的SMC调用约定。ATF 里已经有services/ff-a的相关实现比如用 FF-A 规范的direct message传递函数调用。做高安全等级的产品时想把 TEE 功能提供给多个普通世界分区使用FF-A 会是一个更规范的方案。不过实话实话FF-A 在生态上的落地速度没有想象中快不少厂商仍然基于旧的 OP-TEE SMC 方式工作。如果你不急着上马高度虚拟化的机密计算场景可以先在不改动架构的前提下保持对 FF-A 规范的关注。6.3 移植到新平台前需要关注的 LTS 分支选择TF-A 的发版节奏里LTS 分支会比 master 保守很多。我个人的教训是凡是直接用于量产的平台一定切换到 LTS 分支而不是追踪 master。LTS 分支会周期性合入修复 CVE 的安全补丁API 变化较小编译工具链和下游 U-Boot 的兼容性也更好。你在用git clone拉取 ATF 源码时可以显式选择 LTS 分支git clone --branch lts-v2.8 https://github.com/ARM-software/arm-trusted-firmware.git然后在make之前看一下docs/plat/下的移植指南确认这个版本与你要用的 U-Boot、OP-TEE 版本是否匹配。ATF、OP-TEE、U-Boot、Linux 四者的版本匹配关系我建议你固定成一组不要单独升其中一个否则容易出兼容性问题。6.4 从跑通到能用平台移植的完整交付建议很多朋友做 ATF 移植止步于启动打印通过了或Linux 能起来了但在真实产品上线前这部分工作还远远不够。我的经验是一个合格的 ATF 移植交付至少要包含以下内容BL31 常驻稳定性跑压力测试让系统反复执行reboot、suspend/resume、CPU hotplug至少几百次不出问题。安全启动验证报告完整记录ROT_KEY生成、证书链签名、镜像烧录、验证启动的全流程并附上验证成功的串口日志。安全审计清单如果这个产品会过 CCC、FIPS 或者等保ATF 只是信任链的一部分需要配合 Root of Trust、密钥管理、安全存储一起说明。构建复现文档记录你的make命令行、编译工具链版本、BL33 和 TEE 的 commit保证 team member 可以复现你的完整构建。我在实际项目里还养成了一个习惯每次移植完成都会把编译好的fip.bin和对应的bl31.elf保存到专门的 build artifact 仓库里并记录提交哈希。否则两个月后回来找问题连当时烧到板子上的镜像到底是哪个版本都说不清那种感觉实在太痛苦了。最后再分享一个小技巧调 ATF 问题时不要只盯着 ATF 自身的日志把BL33U-Boot的CONFIG_LOGLEVEL和 Linux 内核的earlycon都打开会给你很多跨层排查的线索。我见过太多的ATF 问题其实是 U-Boot 的 DTS 配置、内核 PSCI 驱动版本或者 bootloader 传递参数的问题全链路日志一开往往十分钟内就能定位。做底层固件就是这样很多问题不是难度高而是信息不够。先把日志铺开再把耐心准备好剩下的事情就顺理成章了。