4、ATF基础概念：ARMv8异常级别、EL3/EL2/EL1/EL0、Secure Monitor、SPD框架
好，咱们今天聊点硬核的。ARMv8的异常级别模型，说白了就是给CPU分了四个权限等级。我刚开始接触ATF时，觉得这东西不就是个权限管理嘛，后来踩了坑才明白——它直接决定了整个系统的安全边界怎么画。
4.1 ARMv8异常级别：四个世界
ARMv8把运行模式分成了四个异常级别（Exception Level），从EL0到EL3。数字越大，权限越高。你想想看，这就像一栋楼的四个楼层：EL0是普通用户区，EL1是操作系统区，EL2是虚拟化管理区，EL3是安全监控区。
| 异常级别 | 典型用途 | 运行环境 |
|---|---|---|
| EL0 | 用户态应用程序 | 非安全/安全世界 |
| EL1 | 操作系统内核（Linux、RTOS） | 非安全/安全世界 |
| EL2 | Hypervisor（虚拟化） | 非安全世界 |
| EL3 | Secure Monitor（ATF核心） | 安全世界 |
这里有个关键点：EL3是唯一永远安全的级别。我在项目中遇到过有人试图在EL1做安全启动校验，结果被攻击者从EL0直接绕过——因为EL1的页表可以被EL2篡改。嗯，这就是为什么ATF必须跑在EL3。
核心原则：安全边界必须建立在最高权限级别上。EL3就是那个"最后一道门"。
4.2 Secure Monitor：两个世界的桥梁
ARMv8把系统分成了两个"世界"：非安全世界（Normal World）和安全世界（Secure World）。非安全世界跑Linux、Android这些，安全世界跑TEE（如TrustZone）、安全存储、指纹处理等敏感任务。
那问题来了：两个世界怎么通信？答案就是Secure Monitor。它运行在EL3，负责处理世界切换。每次从非安全世界调用安全服务，都得经过它。
具体流程是这样的：
- 非安全世界执行
SMC指令（Secure Monitor Call） - CPU陷入EL3，Secure Monitor接管
- Secure Monitor解析调用参数，决定路由到哪个安全服务
- 切换到安全世界执行服务
- 返回结果，切回非安全世界
我个人习惯把Secure Monitor比作一个"安全门卫"——它不干具体活，但谁进谁出、带什么东西，都得它说了算。
小技巧：调试SMC调用时，可以在ATF的smc_handler64函数里加打印。我曾经靠这个定位过一个诡异的缓存一致性问题——安全世界写的数据，非安全世界读出来是旧的。
4.3 SPD框架：让TEE和ATF好好说话
SPD全称是Secure Payload Dispatcher。说白了，它就是ATF里用来对接各种TEE（如OP-TEE、Trusty、QSEE）的框架。
为什么需要SPD？因为不同的TEE实现，它们的SMC调用号、参数格式、初始化流程都不一样。ATF不能硬编码支持某一种TEE，所以搞了个插件框架——你想用哪个TEE，就编译对应的SPD进去。
常见的SPD实现：
- spd_opteed：对接OP-TEE，开源社区最常用
- spd_trusty：对接Google Trusty，主要用于Android
- spd_tlk：对接NVIDIA TLK
- spd_spmd：用于FF-A（弹性框架架构）
每个SPD需要实现一组回调函数：
// SPD回调接口（简化版）
struct spd_ops {
uint64_t (*spmd_handler)(uint64_t x0, uint64_t x1, ...);
int (*spmd_init)(void);
void (*spmd_suspend)(void);
void (*spmd_resume)(void);
};我记得第一次移植OP-TEE时，SPD的初始化顺序把我坑了一把——ATF必须先初始化SPD，然后SPD再去初始化TEE。如果顺序反了，TEE根本收不到SMC请求。
注意：SPD的编译是静态链接的。你只能在构建ATF时选一个SPD，不能运行时动态加载。选错了？重新编译吧。
4.4 异常级别切换实战：SMC调用流程
咱们来看一个完整的SMC调用流程。假设非安全世界的Linux想调用OP-TEE的加密服务：
- 发起调用：Linux执行
SMC #0指令，参数放在x0-x6寄存器 - 陷入EL3：CPU自动保存当前上下文，跳转到ATF的SMC入口
- 路由判断：ATF解析x0中的SMC功能ID，发现是OP-TEE的服务
- 调用SPD：ATF调用
spd_opteed的handler函数 - 世界切换：SPD保存非安全世界上下文，恢复安全世界上下文
- 执行服务：CPU切换到EL1（安全世界），OP-TEE执行加密操作
- 返回结果：OP-TEE执行
SMC #0返回，ATF恢复非安全世界上下文
这里面每一步都有坑。我遇到过最典型的问题是：上下文保存不完整。ATF默认只保存x0-x29，但有些TEE会用到x30（链接寄存器）甚至浮点寄存器。结果就是——返回非安全世界时，程序莫名其妙崩溃。
避坑指南：如果你发现SMC调用后Linux进程挂了，先检查ATF的上下文保存代码。我曾经花了两天时间，最后发现是少保存了一个系统寄存器ACTLR_EL3。
4.5 知识体系总览
下面这张图把本章的核心概念串起来了。我建议你把它存下来，以后调试ATF时对照着看。
这张图里，左侧是四个异常级别的堆叠，右侧是两个世界的划分，中间靠SPD框架连接。你注意看EL3那条虚线——它同时连接到非安全世界和安全世界，这就是Secure Monitor的"桥梁"作用。
4.6 本章小结
ARMv8的异常级别模型是整个ATF的基石。EL3是安全世界的"制高点"，Secure Monitor是跨世界通信的"守门人"，SPD框架让ATF能灵活对接各种TEE。这三个概念搞清楚了，后面学ATF的启动流程、电源管理、PSCI这些，就会顺畅很多。
嗯，最后说一句：别小看异常级别的切换。我见过太多人觉得SMC调用很简单，结果在上下文保存、缓存一致性、MMU配置上翻车。下次你写SMC handler时，记得多想想——当前在哪个EL？要切到哪个EL？中间要保存什么？