4、异常处理模型：安全监控模式（Monitor Mode）、SMC 指令、世界切换上下文保存与恢复
好，咱们今天聊点硬核的。异常处理模型，说白了就是 TrustZone 的「交通警察」。你想想看，安全世界和非安全世界是两个独立运行的实体，它们怎么切换？谁来做裁判？答案就是——Monitor Mode（监控模式）。
我个人习惯把 Monitor Mode 比作一个「看门的老大爷」。两个世界想串门，都得先经过老大爷点头。老大爷手里攥着两把钥匙：一把开安全世界的门，一把开非安全世界的门。切换的时候，他得把当前世界的「现场」原封不动地保存下来，再把另一个世界的「现场」恢复回去。嗯，这就是上下文保存与恢复的核心。
4.1 安全监控模式（Monitor Mode）
Monitor Mode 是 ARM 架构中一个特殊的异常模式。它独立于安全世界和非安全世界，拥有自己的栈指针（SP_Mon）和寄存器组。说白了，它不属于任何一方，只负责「切换」这件事。
我记得第一次接触 TrustZone 时，有个问题困扰了我很久：为什么不能直接在安全世界或非安全世界里做切换？后来踩了坑才明白——如果切换逻辑本身就在某个世界里，那切换过程中被中断了怎么办？谁来保证原子性？Monitor Mode 的存在，就是为了解决这个「谁来保护保护者」的问题。
核心要点：Monitor Mode 的异常向量表是独立的，且只能通过硬件异常或 SMC 指令进入。这意味着，非安全世界的软件无法直接篡改 Monitor 的行为。
Monitor Mode 的进入方式主要有三种：
- SMC 指令：软件主动发起世界切换
- IRQ/FIQ 中断：配置为路由到 Monitor 的中断
- 外部中止（External Abort）：某些系统错误也会触发 Monitor
实际项目中，我见过有人试图在非安全世界里直接写 SCR（安全配置寄存器）来切换世界。结果呢？系统直接挂掉。为什么？因为 SCR 是安全世界才能访问的寄存器，非安全世界碰它就会触发异常。嗯，这里要注意：永远不要试图绕过 Monitor 做世界切换，这是 TrustZone 的底线。
4.2 SMC 指令：世界切换的「敲门砖」
SMC（Secure Monitor Call）指令，是软件主动发起世界切换的唯一合法途径。它的用法很简单：
// 在非安全世界调用 SMC，请求切换到安全世界
// R0 通常存放功能 ID，R1-R6 存放参数
MOV R0, #0x01 // 功能号：请求安全服务
MOV R1, #0x1000 // 参数：缓冲区地址
SMC #0x00 // 触发 Monitor 异常你可能会问：为什么是 SMC 而不是普通的软中断（SWI）？我刚开始也有这个疑问。后来看了 ARM 架构手册才明白——SMC 是专门为 TrustZone 设计的指令，它会让 CPU 强制进入 Monitor Mode，并且把当前世界的状态标记为「被中断」。而 SWI 只能在当前世界内部处理，无法跨越安全边界。
避坑指南：我曾经在一个项目中，把 SMC 的参数传递搞错了。R0 里放的是功能号，但我把缓冲区地址也塞进了 R0，结果 Monitor 端解析出来的参数全是乱码。调试了整整两天才发现问题。记住：SMC 的参数传递规则一定要和 Monitor 端约定好，最好做成结构体。
SMC 指令的执行流程大致如下：
- CPU 执行 SMC 指令，触发 Monitor 异常
- 硬件自动保存当前世界的部分上下文（PC、CPSR 等）
- CPU 切换到 Monitor Mode，加载 Monitor 的异常向量表
- Monitor 软件保存完整的上下文（通用寄存器、银行寄存器等）
- Monitor 根据 SMC 参数决定切换到哪个世界
- 恢复目标世界的上下文，执行 ERET 指令返回
这里有个细节：SMC 指令可以带一个立即数参数（比如上面的 #0x00），这个参数在 ARMv8 中被称为 SMC 调用类型。我个人习惯用 #0x00 表示「标准调用」，用 #0x01 表示「快速调用」。当然，具体怎么用完全取决于你的 Monitor 实现。
4.3 世界切换上下文保存与恢复
世界切换最核心的问题就是：怎么保证切换前后，两个世界的程序都能正常运行？答案就是上下文保存与恢复。
你想想看，安全世界正在算一个加密密钥，突然被非安全世界的 SMC 打断了。如果不保存现场，等切回来的时候，寄存器里的中间结果早就被覆盖了。那加密结果就全错了。
上下文保存的内容包括：
| 保存内容 | 说明 | 保存位置 |
|---|---|---|
| 通用寄存器（R0-R12） | 当前世界的计算现场 | Monitor 栈或专用内存 |
| 栈指针（SP） | 当前世界的栈位置 | Monitor 栈 |
| 链接寄存器（LR） | 返回地址 | 硬件自动保存到 LR_mon |
| 程序状态寄存器（SPSR） | 当前世界的 CPU 状态 | 硬件自动保存到 SPSR_mon |
| 银行寄存器 | FIQ、IRQ 等模式的私有寄存器 | Monitor 栈 |
| 系统控制寄存器 | MMU 配置、缓存策略等 | Monitor 栈 |
嗯，这里要注意：并不是所有寄存器都需要保存。比如 R15（PC）在异常发生时已经被硬件保存了，你不需要再手动存一次。另外，有些寄存器是 Banked（银行化）的，比如 FIQ 模式的 R8-R12，它们在切换世界时不会受影响，但如果你在 Monitor 里用了这些模式，就得小心了。
我见过一个经典错误：有人在 Monitor 里用 FIQ 模式处理中断，但没有保存 FIQ 模式的银行寄存器。结果非安全世界的 FIQ 中断处理程序回来时，发现 R8 的值莫名其妙变了。调试了三天才发现是 Monitor 的锅。
警告：上下文保存的顺序非常重要。如果你先保存了 SP，然后又用 SP 来压栈，那保存的 SP 值就是错的。正确的做法是：先切换到 Monitor 自己的栈，再保存其他世界的上下文。
下面是一个简化的上下文保存代码示例：
// Monitor Mode 下的上下文保存（简化版）
// 假设当前在 Monitor Mode，LR_mon 和 SPSR_mon 已由硬件保存
// 第一步：切换到 Monitor 自己的栈
LDR SP, =monitor_stack_top
// 第二步：保存通用寄存器
STMDB SP!, {R0-R12}
// 第三步：保存银行寄存器（以 FIQ 模式为例）
MRS R0, R8_fiq
MRS R1, R9_fiq
MRS R2, R10_fiq
MRS R3, R11_fiq
MRS R4, R12_fiq
STMDB SP!, {R0-R4}
// 第四步：保存系统控制寄存器
MRC p15, 0, R0, c1, c0, 0 // SCTLR
MRC p15, 0, R1, c2, c0, 0 // TTBR0
STMDB SP!, {R0-R1}
// 现在可以安全地切换世界了
// ... 切换逻辑 ...
// 恢复时反向操作即可恢复上下文的顺序正好相反：先恢复系统控制寄存器，再恢复银行寄存器，最后恢复通用寄存器。然后执行 ERET 指令，硬件会自动恢复 PC 和 CPSR。
我个人习惯在上下文保存时加一个「魔数」（Magic Number）校验。每次保存时在栈顶写一个固定值，恢复时检查这个值有没有被篡改。如果发现魔数不对，说明栈被踩了，立刻触发安全告警。这个方法帮我抓过好几次内存越界的 bug。
4.4 世界切换的性能考量
上下文保存与恢复是有代价的。你想想看，每次 SMC 调用都要保存几十个寄存器，如果频繁切换，性能开销会非常大。
我曾经在一个 IoT 项目里，安全世界和非安全世界之间每毫秒切换一次，结果发现 CPU 有 30% 的时间都花在了上下文保存和恢复上。后来怎么优化的？两个方向：
- 减少切换频率：把多次 SMC 调用合并成一次批量处理
- 按需保存：只保存会被覆盖的寄存器，而不是全部保存
嗯，这里要注意：按需保存虽然能提升性能，但会增加代码复杂度。你得精确分析哪些寄存器在 Monitor 里会被修改。我建议新手先做全量保存，等系统稳定了再考虑优化。
最后说一句：世界切换的上下文保存，本质上是一个「信任边界」的问题。Monitor Mode 作为唯一的切换点，它的正确性直接决定了整个系统的安全性。所以，写 Monitor 代码时，请把它当作核反应堆的控制程序来对待——每一个寄存器、每一条指令，都可能是致命的。