给x86固件工程师的ARM ATF/TF-A入门：对比UEFI启动，搞懂BL2/31/33到底干了啥-平芜编程栈

从x86到ARM：固件工程师的安全启动架构迁移指南

当一位经验丰富的x86固件工程师首次接触ARM体系时，最困惑的莫过于那套截然不同的启动流程。您可能已经熟练掌握了UEFI规范中的SEC、PEI、DXE阶段划分，但当面对BL1、BL2、BL31这些陌生名词时，是否感觉像在阅读另一门学科的专业术语？本文将为您架起一座认知桥梁，通过对比分析帮助您快速建立ARM Trusted Firmware（ATF）的思维模型。

1. 架构全景：ARM与x86的安全启动哲学差异

ARM体系与x86在启动设计上存在根本性差异，这源于两者不同的安全模型设计理念。x86架构长期采用"修补式安全"策略，通过在后期的启动阶段（如DXE）引入安全模块来增强防护；而ARMv8则从芯片设计之初就将安全性作为首要考量，形成了纵深防御体系。

关键对比维度：

信任链建立：x86依赖离散的安全模块（如Boot Guard、TXT），ARM则通过连续的BL阶段实现信任传递
硬件初始化位置：x86通常在PEI阶段完成，ARM则分散在BL2和BL31
运行时保护机制：x86依赖SMM，ARM使用EL3监控模式

典型ARMv8启动流程中的特权级切换如下图所示：

EL3 (Secure Monitor) BL1 → BL2 → BL31 / | \ EL2 (Hypervisor) / | → BL33 (UEFI/uboot) EL1 (OS Kernel) / → BL32 (TEE OS) EL0 (Applications) /

2. 阶段对标：ATF与UEFI启动组件映射

2.1 BL1：ARM版的Boot Guard ACM

作为信任根，BL1与Intel Boot Guard的Authenticated Code Module（ACM）功能相似，但实现方式截然不同：

特性	x86 ACM	ARM BL1
存储位置	SPI Flash	芯片掩膜ROM
验证对象	验证FIT中的IBB	验证BL2镜像签名
执行环境	32位保护模式	AArch64 EL3
内存初始化	依赖FSP	使用芯片SRAM

BL1的典型工作流程：

初始化最小硬件集（时钟、看门狗）
建立异常向量表
配置Trusted SRAM区域
加载并验证BL2镜像
移交执行权至BL2

2.2 BL2：PEI阶段的"安全增强版"

这个阶段最令x86工程师困惑——为什么DDR初始化会放在安全固件中？这是因为ARM将关键硬件初始化视为安全边界的一部分：

// 典型BL2硬件初始化序列（以NXP LX2160为例） bl2_early_platform_setup(); // 时钟/电源基础配置 ddrc_init(); // DDR控制器配置 serdes_init(); // 高速串行接口初始化 if (is_secure_boot_enabled()) verify_bl31_signature(); // 验证下一阶段签名

与x86 PEI阶段的对比差异：

代码可见性：多数x86厂商提供二进制FSP，而ARM BL2通常开源
安全边界：BL2运行在安全世界（Secure World），PEI则属于非安全世界
硬件覆盖范围：BL2通常包含更多PHY层初始化

2.3 BL31与UEFI的运行时服务对比

BL31作为EL3的常驻监控程序，其功能相当于x86中SMM与UEFI运行时服务的结合体：

功能映射表：

ARM BL31服务	x86对应机制	触发方式
PSCI电源管理	ACPI _PSC方法	SMC调用
安全配置接口	SMM Handler	SMC调用
安全监控	Intel TXT	异步异常
世界切换（World Switch）	无直接对应	ERET指令

典型BL31服务注册示例：

DECLARE_RT_SVC( std_svc, // 服务名称 OEN_STD_START, // OEM编号范围起始 OEN_STD_END, STD_SVC_DESC // 服务描述符 );

3. 关键概念解析：ARM特有的安全机制

3.1 TrustZone与Boot Guard的实质区别

虽然常被类比，但这两项技术解决的是不同层面的安全问题：

TrustZone：硬件级的世界隔离机制
- 提供Secure/Non-secure双执行环境
- 内存/外设访问权限控制
- 需要软件栈（如OP-TEE）配合
Boot Guard：启动完整性验证方案
- 确保启动代码未经篡改
- 依赖签名验证链
- 不提供运行时保护

3.2 异常级别（EL）与x86特权环的异同

ARM的EL并非简单对应x86的Ring 0-3：

ARM EL	x86近似对应	典型用途
EL3	SMM + TXT	安全监控模式
EL2	VMX Root Mode	虚拟机监控程序
EL1	Ring 0	操作系统内核
EL0	Ring 3	用户应用程序

重要区别：每个EL都可以进一步划分为安全（S-ELx）和非安全（NS-ELx）状态，这种二维权限模型是x86所不具备的。

4. 实战：移植x86固件经验到ARM平台

4.1 硬件初始化迁移指南

当您需要将x86 BIOS的硬件初始化代码迁移到ARM平台时，需注意以下关键点：

DDR初始化迁移：
- x86常见模式：FSP→MRC→BIOS
- ARM典型路径：BL2→DDR PHY训练→BL31
- 特别注意：ARM平台通常需要更早初始化DDR（在BL2阶段）

外设安全属性配置：

在BL2阶段通过TZASC（TrustZone Address Space Controller）设置

示例代码：

void configure_tzpc(void) { // 设置某个外设为非安全访问 mmio_write_32(TZPC_BASE + TZPC_DECPROT0_SET, DECPROT_UNLOCK | DECPROT_NS_RW); }

4.2 UEFI适配注意事项

当BL33采用UEFI实现时，需特别注意：

内存映射协调：

# ARM平台典型内存布局 0x00000000 - 0x03FFFFFF : BL1/BL2 (Secure) 0x04000000 - 0x07FFFFFF : BL31/BL32 (Secure) 0x80000000 - 0xFFFFFFFF : UEFI/OS (Non-secure)

PSCI集成： UEFI需通过libPSCI封装以下服务：
- CPU_ON/CORE_ENTRY（对应x86的MP初始化）
- SYSTEM_RESET（替代x86的RESET_REGISTER）
- SYSTEM_OFF（类似x86的S5状态）

5. 调试技巧：从x86思维到ARM实践

5.1 异常级别识别

通过以下命令可快速判断当前执行级别：

# 在UEFI Shell或uboot中执行 mrs x0, CurrentEL lsr x0, x0, #2 // 结果即为当前EL数值

5.2 安全状态检测

判断当前处于Secure还是Non-secure世界：

uint64_t read_scr(void) { uint64_t scr; asm volatile("mrs %0, scr_el3" : "=r" (scr)); return scr; } int is_secure_world(void) { return (read_scr() & SCR_NS_BIT) ? 0 : 1; }

5.3 常见问题排查表

现象	x86类似问题	ARM特有原因
DDR初始化失败	MRC训练错误	TZASC配置不当
SMC调用无响应	SMI Handler未注册	BL31服务未初始化
启动卡在BL2	PEI阶段挂起	BL31镜像签名验证失败
运行时安全异常	SMM违规	非安全代码访问安全资源