深度源码评测Arm-Trusted-Firmware(ATF)架构全景、安全固件工程审计与平台移植落地指南1. 先搞清楚ATF在整个ARM软件体系里的位置1.1 从异常级别模型看ATF为什么绕不开做ARM平台开发的人肯定绕不开异常级别这四个字。很多刚接触这块的同学会把ATF理解成一段启动代码或者一个u-boot的上游模块但实际上ATF的定位要特殊得多——它跑在EL3是整个ARM处理器上唯一运行在最高特权级的通用固件。打个比方如果EL0是普通用户、EL1是操作系统内核、EL2是虚拟机监控器那EL3就是一个独立的安全监控层手里握着处理器的最终控制权。所有从非安全世界切换到安全世界的操作都必须经由EL3签发的SMC指令才能完成。这在工程上意味着什么意味着ATF的可靠性直接决定了整个系统的安全下限。操作系统可能被攻破Hypervisor可能被攻破但只要EL3守得住攻击者就永远控制不了平台最核心的资源。反过来如果ATF本身出了漏洞上层做再多防护都是白搭。所以你会看到ARM近几年对ATF的投入越来越大TPM、安全启动、针对CCA机密计算架构的支持都在往这里面塞。这也是我为什么坚持把ATF往深里读——它不只是启动流程的一部分更是一条完整的安全边界。1.2 启动流程BL1、BL2、BL31、BL32、BL33到底各干各的什么事ATF的启动流程可以拆成五个阶段架构图上画得规规矩矩但工程上真正跑起来每一段都有它独特的脾气。BL1这段代码烧在片上ROM里是整个系统上电后的第一条指令流。它的职责很简单——把BL2从启动设备通常是编在FIP镜像里由SoC内部的ROM加载逻辑引导加载进SRAM然后验签、跳转。BL1的代码量非常小因为它根本没地方躲——SRAM总共就那么大留给BL1的空间往往只有几十KB。BL1也是整个信任链的根所以业内也把它叫RoTRoot of Trust。芯片出厂时烧进去的BL1是不能改的一旦改错板子就真的成砖了。BL2放在SRAM里运行负责加载和验证后续所有镜像。它在整个体系里相当于把关人BL31、BL32如果有以及BL33通常是U-Boot或UEFI都要经它验签后才被放行到各自的目的地。BL31运行在EL3的运行时固件。这才是ATF的核心——它接管了SMC调度、PSCI电源管理、运行时服务注册、Secure Monitor的所有职责。系统启动完成之后BL31并不是退场了而是一直活着随时等内核或Hypervisor用SMC指令来向它请求服务。BL32可选组件跑在Secure EL1典型例子是OP-TEE。ATF通过Secure Partition Dispatcher机制把SMC转发给它——比如你在用户态调一个TA命令请求先落到内核OP-TEE驱动再通过SMC进EL3BL31再看是给trusted OS自己的命令还是转发到BL32的SPD整个路径非常长每一跳都有安全问题需要审计。BL33非安全世界的第一段代码U-Boot或者UEFI固件。BL31在完成初始化之后会把CPU的状态切到非安全态然后把控制权交给BL33。可以理解为前面的ATF全部是为了把这最后一棒递出去。初学的时候容易把BL31和BL33的关系搞混。记住一句核心逻辑BL1和BL2是阶段性的临时角色干完活就退场BL1有时会留在内存中但只提供了少量运行时服务BL31才是整个EL3世界的常驻主程序。1.3 源码目录是一张现成的架构地图ATF的代码根目录结构非常清晰每个目录基本对应一个功能域。我最初花了两周通读源码很大一部分时间都是在按目录猜职责、进目录验假设的状态里度过的。这里把最有价值的几个目录做一个快速清单。bl1/、bl2/、bl31/、bl32/各BL阶段的主流程代码。想搞清BL31的初始化顺序直接看bl31/bl31_main.c里的bl31_main()函数。plat/平台移植目录。各大SoC厂商的参考实现都在这里比如plat/arm/board/下面是ARM官方的各种开发板plat/rockchip/、plat/mediatek/是厂商自己的适配层。lib/内核对上层暴露的库比如lib/el3_runtime/是EL3的运行时上下文管理lib/xlat_tables/里面是MMU页表构建库lib/psci/是PSCI通用逻辑。drivers/各种外设驱动包括arm/gic中断控制器、arm/uart串口、auth认证模块、ioIO抽象层。tools/工程工具fiptool用于封装FIP固件包cert_create用于生成证书链还有mbedtls相关的辅助构建脚本。services/EL3运行时服务std_svc是标准服务比如PSCI和SDEIspd/是安全分区调度器也就是BL32世界的入口。对想要快速上手或者做平台移植的读者我的建议是先从plat/arm/board/下的fvp或者juno板入手对照官方Porting Guide逐行看比直接看通用逻辑更省力。官方参考板的设计通常最规范抽丝剥茧之后再看自家平台很多怪问题都迎刃而解。2. 源码级拆解核心子系统的实现逻辑与安全边界2.1 PSCI不是一套代码库而是一套协议落地很多开发者提到PSCI第一反应是哦就是电源管理。但如果你真的深入读源码就会意识到PSCIPower State Coordination Interface先是作为一个ARM定义的规范存在然后才被ATF用代码实现了出来。它解决的核心问题非常朴素操作系统要把CPU核关掉、要挂起、要重新拉起来但CPU核的启停权在EL3手里普通内核代码不能直接用WFI然后把执行流扔掉——因为当核被关闭之后下一个要把它唤醒的中断依然要经由EL3路由。所以ATF在EL3里面实现了一个电源状态的最高裁判不断跟踪哪个核在什么状态、哪个状态转换合法的、如何把状态迁移所需的上下文保存好。从代码上看lib/psci/psci_main.c里的psci_cpu_on()是个绝佳的切入点。你可以顺着这个函数追踪整个CPU_ON的调用链内核发起SMC → EL3捕获 → PSCI框架校验参数 → 调用平台层注册的platform_setup_pm_ops函数最终通过接管power_down/power_up回调完成实际动作。**平台层向你开放的不是电源控制寄存器怎么写而是一个约定的操作表。**这是ATF设计里很值得学习的一点用一套抽象协议把安全边界EL3和硬件细节平台层隔开。2.2 SMC调度器是EL3世界的总线对内核或者U-Boot里的开发者来说SMC指令就像一个魔法门一条指令下去就能进到EL3。但进了EL3之后请求怎么分发这就是SMC调度器要解决的问题。ATF里所有服务在EL3初始化时都要通过SMC_RT_SVC_DESC这类宏把自己的分发函数注册进rt_svc_descs表。SMC进来后调度器根据smc_fid的高位字段快速定位到对应的服务描述符再把寄存器上下文传过去。这个机制类似内核的syscall table但多了一层。我读这块源码时最大的感触是**上下文切换非常贵而且异常容易出错。**一个SMC要跨EL3和Non-secure侧两套世界需要保存和恢复的寄存器非常多。ATF为此专门维护了一套CPU上下文结构体在EL3和普通世界的切换过程中反复进出。如果你在做SPM或者SPD相关的开发一定要先把这套上下文切换机制嚼透否则一个小字段的错误设置就可能导致安全世界的信息泄漏。2.3 内存布局与xlat_tables如何决定固件能不能活下来ATF对内存布局的执念说实话我刚开始看源码时是有点受不了的——到处都是PLAT_*_BASE、PLAT_*_SIZE、MAP_*宏仿佛在写一本内存考古学著作。但后来真正在板子上遇到为什么固件莫名其妙不跑的问题时才领会到这种严谨的必要性。整个ATF运行时期的内存被分成了三块ROM、SRAM、DRAM。BL1和BL2代码基本限定在前两者里BL31的大部分也可放在SRAM里性能好且安全。如果你用的平台的SRAM很小常见的是256KB甚至128KB就得学会如何在这么小的空间里塞下BL31 栈 页表 各个运行时服务的数据结构。而lib/xlat_tables/提供了一套二级页表构建机制允许你精细控制每一块内存的属性是可执行还是不可执行、是设备内存还是普通内存、是否允许非安全访问。这套机制是整个ATF内存安全的关键——一个在写平台上随意映射页表的改动完全可能把某个安全页面暴露给普通世界。所以在做平台移植时我强烈建议把platform_def.h里所有地址相关的宏逐个核对一遍明确每个宏指向的位置、大小、归属。很多移植问题看似是代码逻辑错误实际上都是内存映射越界。3. 安全固件工程审计从信任链设计到实测风险点3.1 信任链CoT怎么一环扣一环做过安全固件的人都知道安全性不是由一个加密算法决定的而是由信任链的闭环程度决定的。ATF的信任链可以画成一张有向图BL1是信任根它用自己的RSA公钥验证BL2的签名BL2再验证BL31、BL32、BL33的签名。每一环都验签就构成了第一条完整链路。但工程审计时不能只看链上有没有验签还要看几个关键问题公钥放在哪里ATF把平台公钥编进了BL1或BL2的只读数据区攻击者能不能通过修改fip包里的镜像来覆盖公钥本身验签过程用的哈希算法和填充方式是否安全ATF默认的MBEDTLS_USE_MD5我曾经看到有人在配置里还留着MD5做兼容这绝对是审计红线。失败后怎么处理如果验签不通过BL1的panic行为应该直接死循环而不是尝试跳过错误继续运行。有些早期固件实现为了调试方便验签失败后只是打印一个log就继续跑这相当于给攻击者开了后门。ATF本身对这些问题处理得比较规范真正的风险点往往在集成方手里——比如把TRUSTED_BOOT_BOARD_ID开着但证书链配置错误、把MEASURED_BOOT忽略了、或者改了plat_get_rotpk_info()让它返回一个假公钥。我审计过不止一个项目最终发现安全漏洞往往不在ATF上游代码里而在对接层的松懈配置。3.2 FIP打包与签名验证机制构建ATF时make成功之后你会看到一堆.bin和.elf但真正烧到板子上的通常是一个fip.bin。这个FIPFirmware Image Package本质上就是一个容器把BL2、BL31、BL32、BL33加上各自的元数据打包在一起。fiptool既可以打包含有签名的镜像也可以只做无签名的裸奔包。签名验证过程里有两个特别值得注意的细节。一个是在tools/cert_create生成的证书链里每张证书的扩展字段都绑定了一系列属性比如镜像的类型、版本号、所在内存地址等——这些属性一旦和实际加载的镜像不匹配验签就会失败。另一个是ATF对回滚保护的实现它在FIP里引入了版本号比较机制高版本的证书不能被低版本覆盖防止攻击者把固件降级到有已知漏洞的旧版本。这两点如果只是走马观花读源码很容易忽略但它们才是CoT里真正难绕过的部分。我自己的经验是拿到一个新平台的FIP包第一步先执行fiptool info看看里面分别是什么镜像、各自的追加信息是否正确。第二步在打开TRUSTED_BOARD_BOOT的情况下故意把BL33换成一个没签名的野镜像看平台是否真的会拒绝引导。这个负向测试虽然简单但能立刻暴露信任链的薄弱环节。3.3 审计时重点看的几个风险面调试接口、日志打印、证书校验、边界检查固件审计和普通应用代码审计不太一样它看的是如果CPU已经不可信固件还能保住什么。我在审计ATF集成项目时通常会沿着下面几条线过一遍调试接口是否默认关闭DEBUG1构建出来的固件会打开一堆NOTICE级别的日志甚至调试命令生产环境必须用DEBUG0。另外plat/common/plat_psci_common.c里常年有一些用来手动触发调试流程的函数生产固件里应当确认已从链接中剔除。日志是否泄漏秘密普通世界能不能通过串口或者Side-channel读到EL3的密钥信息VERBOSE级别的日志打印可能会把证书内容、公钥哈希、内存地址都打出来生产环境务必关掉。证书链的根证书能否被替换plat_get_rotpk_info()的返回值决定信任根的公钥是谁。如果这个函数的实现被人改动成编译时读环境变量或者从易失Flash读取那整条链就不存在了。地址边界和长度参数是否安全固件接收来自普通世界的参数后有没有校验输入的内存地址没有越界到安全区域这是经典漏洞类型。ATF框架本身已经有IN_RANGE()之类的检查但平台层在处理自己的SMC功能号时经常忘记做同样的校验。3.4 历史CVE给我们的教训回顾ATF的CVE列表会发现漏洞大多集中在内存布局错误的指针引用、上下文切换时寄存器未完全清理、以及BL31加载镜像时的长度校验缺失这几类。比如CVE-2020-6173就涉及Boot Loader阶段对镜像头信息解析时未正确处理RO段的边界条件导致越界写。这类问题给做固件的工程师一个很明确的信号ATF的代码更新必须作为安全更新的常规一环来处理而不是能用就不动。我见过不少项目把IMPORTANT_NOTICE里的安全修复说明看都不看一直跑着两三年前的ATF烧录包。在SoC平台总体迭代不慢的年代这几乎等于把所有已公开漏洞写在脸上。4. 平台移植落地从一个空白板卡到跑通BL314.1 移植前必须梳理的三件事如果你要在一颗新SoC或者新的评估板上让ATF跑起来请务必先回答下面三个问题省得后面返工这颗SoC的私密内存SRAM/BRAM总容量是多少能划分给BL1、BL2、BL31的空间分别有多大这是制定内存布局的起点。串口在哪里初始化MMU是否一上电就能用EL3阶段访问外设地址时是否能直接读写这决定平台层的bl31_early_platform_setup2()里要先配哪块。一共几个核心大小核怎么排MPIDR分布如何PSCI要把每个核的上电/下电、复位向量、唤醒地址都管理起来这块梳理不清楚后面跑到多核启动时一定死人。4.2 最小移植的文件清单与实现要点ATF重视的是最小可跑通路。我把一次移植中真正要动到的文件做了一个优先级排序platform_def.h定义平台内存地址、内存大小、核心数、PLAT_LOG_LEVEL等基础参数。所有PLAT_*宏都必须给出明确且互不冲突的值。plat_setup.c实现bl31_early_platform_setup2()、bl31_platform_setup()、bl31_plat_arch_setup()。这三个函数是BL31从汇编跳到C语言后的三条第一道门前两个负责基础的串口、时钟、电源控制器初始化第三个负责建立MMU映射。plat_pm.c提供plat_psci_ops结构体至少要实现cpu_standby、cpu_on、cpu_off这几个回调。这是电源管理的落地层。plat_topology.c实现plat_core_pos_by_mpidr()和plat_my_core_pos()让上层PSCI知道物理核的编号和MPIDR的对应关系。plat_gic.c配置GIC中断控制器注册分发器驱动。GIC版本选错中断就会全部乱套。common/plat_common.cplat_get_next_bl_params()、plat_put_next_bl_params()定义把控制权交给BL33的方式。拿platform_def.h举例真正写起来大概长这样#define PLAT_PRIMARY_CPU 0x0 #define PLAT_CLUSTER_COUNT 1 #define PLAT_MAX_CPUS_PER_CLUSTER 4 #define PLAT_MAX_PWR_LVL 2 #define CFG_SRAM_BASE 0x02000000 #define CFG_SRAM_SIZE 0x00040000 /* 256KB SRAM */ #define BL31_BASE (CFG_SRAM_BASE 0x1000) #define BL31_SIZE (CFG_SRAM_SIZE - 0x2000)这些地址不是拍脑袋定的要对着SoC memory map手册逐页核对特别是给BL31预留的栈空间和页表区域。我见过好几个平台死机的案例最后定位归结为BL31的栈区和页表区重叠原因就是BL31_SIZE算得太极限。4.3 构建、烧录、验证的三步闭环在plat/vendor/board/下面建好目录后编译验证的骨架一般是make PLATyour_platform \ TARGET_BOARDeval_board \ CROSS_COMPILEaarch64-none-elf- \ DEBUG1 \ V1 all如果编译没有报错用fiptool把镜像打包bl31.elf # 或者 bl31.bin最后烧录时注意FIP包的加载地址要和BL1的引导逻辑匹配。首次上电前我建议打开DEBUG1和LOG_LEVEL50让最详细的日志先跑一轮通过串口确认BL1 → BL2 → BL31 → BL33各阶段是否按预期跳转。如果卡在某个阶段优先怀疑串口、MMU、或者镜像加载地址三个点。5. 躲不掉的那些坑串口、GIC、电源状态与缓存5.1 串口输出失效的第一排查顺序ATF移植过程中最普遍的失败模式就是板子插电后串口完全没有输出。遇到这个别慌按下面的顺序排查串口引脚有没有接对、波特率对不对ATF的默认波特率通常从platform_def.h里的PLAT_UART_CLOCK_IN_HZ和BAUD_RATE算出来如果SoC某条分频链路和手册标称值有出入出来的就是乱码或者静默。代码有没有真的进到串口初始化用JTAG看PC指针是否已在console_uart的初始化函数里。.data和.bss段是否被正确重定位BL1阶段代码经常是直接位置相关执行的如果把BL1_RW_BASE配错全局变量访问会崩。5.2 GIC版本与中断安全上下文GIC是EL3最依赖的中断控制器GICv2和GICv3的驱动接口差异非常大。ATF框架中把对GIC的访问抽象成了arm_gic_v2.c和arm_gic_v3.c两个驱动任选其一。移植时首先理解你用的是哪个版本其次要特别注意安全与非安全中断的分组配置。普通世界的中断到达GIC后如果被错误路由到EL3可能会被BL31当作安全中断处理从而导致系统出现匪夷所思的“随机重启”。而安全中断如果路由到非安全世界则等于把EL3的中断面暴露给了普通世界这是安全审计的重罪。5.3 电源状态描述符写错会引发什么ATF的PSCI描述符中平台层的plat_get_power_domain_tree_desc()返回的是一个树状结构描述了整个SoC电源域的关系电源域级别、每个域的编号、每个级别支持的状态。这里最常犯的错是把局部电源域写到全局电源域的位置——比如一个CPU核支持的状态错误地加在了cluster级别结果执行浅睡眠时把整个cluster断电了其他核直接被抹掉。调试这类问题我的经验是先让所有CPU都停在wfi状态手动向EL3发一个PSCI_CPU_ON命令看单个核能否从关断状态恢复。确认单个核链路通了再测双核、集团、全系统挂起才能安全把这些逻辑交给OS。6. 调试手段与效率经验6.1 日志分级与本地化打印ATF的日志系统是按NOTICE、WARNING、ERROR、VERBOSE分级的可以通过PLAT_LOG_LEVEL控制编译进去的代码量。在bring-up阶段打开VERBOSE看的是各种函数进出和虚拟地址映射一旦功能稳定生产版切回NOTICE。这两档之间的取舍不只是打印量还直接影响到安全性和性能——开VERBOSE的固件会比开NOTICE慢不少而且日志内容可能泄露内存布局信息。6.2 串口、JTAG与fiptool三件套串口仍然是ATF调试的主干道但真遇到PC跑飞或者MMU配错导致串口也打不出来的情况就得上JTAG。ARM平台的调试方法不算难但需要额外注意如果EL3的调试组件被锁死了普通的调试agent可能连不到CPU核心。此时需要先检查是否开启了ARM_DAP_*调试相关配置。覆盖到最复杂的信任链问题时千万别忘了fiptool的--dump选项。把FIP里面的每个镜像单独dump出来再用certtool或者Openssl手动验证证书往往能快速定位是签名没对上还是证书内容不匹配。6.3 一个实际的移植联想如何在交叉编译链中选型ATF交叉编译链的选择我推荐优先用官方支持的aarch64-none-elf-或者aarch64-linux-gnu-。用arm-linux-gnueabihf-这类32位工具链去编译ATF是行不通的——ATF要求AArch64模式。有些同学图省事直接用平台BSP自带的gcc-linaro老版本结果踩了不少-fno-builtin、march相关的坑。ATF对工具链版本有明确的最低要求构建前先把Makefile里的CROSS_COMPILE检查看清楚。真正的经验是交叉编译链版本和ATF版本要绑定考虑新系统就选新ATF新工具链老平台要升级ATF前先验证工具链的AArch64特性集是否能满足否则会出现编译过了但在板子上异常的奇怪现象。7. 最后再分享一点压箱底的东西源码评测的工程化方法从实际出发我现在每次拿到一个新的ATF版本或者新的移植任务已经不再满足于能编译、能启动而是会把下面几个问题变成例行检查项BL31启动过程中所有NOTICE级日志是否读得通有没有看似无线程切换的地方fiptool dump后的FIP包结构是否与官方文档一致尤其注意有没有冗余或者缺失的条目。是否用--enable-trusted-board-boot开启过完整证书链验证只用裸镜像链接的调试固件不算数。生产固件编译参数里DEBUG0、LOG_LEVEL是否已降到合理范围是否跑过一次psciCPU热插拔、系统挂起/恢复的功能测试这些动作听起来很基础但恰恰是它们确保了一个ATF集成项目不会在车间量产时突然翻车。源码评测这个事最怕的就是只读代码不动手或者只编译不验证。把单板调通、把信任链拉起来、把一个系统完整地跑起来你才算真正吃透了ATF。如果时间允许我建议你从ARM官方的fvp_base平台开始做一次完整的从零移植安全启动实验把构建、打包、验签、启动全流程走通。用官方参考板做练习最大的好处是文档全、坑少、遇到问题有大量社区能答比直接上手商业SoC平台的适应成本低得多。等这块熟透了再转战自家芯片你会发现所有需要踩的坑基本都已经被官方板提前替你踩了一遍。