📚 课程目录第2章 ARMv9异常模型与安全架构

第二章 ARMv9异常模型与安全架构

异常模型，说白了就是CPU处理突发事件的机制。ARMv9在这块做了不少改动，尤其是安全架构的扩展。我刚开始接触ARMv9时，第一反应是：这不就是AArch64那套吗？后来踩了几个坑才发现，事情没那么简单。

2.1 异常等级（EL0-EL3）

ARMv9保留了四个异常等级，从EL0到EL3。数字越大，权限越高。这个设计其实很直观——你想想看，操作系统内核肯定不能跟用户程序平起平坐，对吧？

异常等级	典型用途	权限范围
EL0	用户应用程序	最低，受限访问
EL1	操作系统内核	可管理MMU、系统寄存器
EL2	Hypervisor（虚拟机监控器）	虚拟化扩展，控制EL1
EL3	Secure Monitor（安全监控器）	最高，控制安全状态切换

我个人习惯把EL3看作"看门人"。它负责安全世界和普通世界之间的切换。在项目中，我见过不少开发者把EL3的代码写得过于复杂，结果性能瓶颈全卡在这里。

小提示：EL0到EL3的切换不是随意的。只有通过异常（Exception）才能提升等级，通过异常返回（ERET）才能降低等级。这个机制保证了系统不会乱跳。

2.2 同步异常与异步异常

异常分两类：同步和异步。区别很简单——同步异常跟当前指令直接相关，异步异常则是外部事件触发的。

同步异常：数据中止、指令中止、系统调用（SVC/HVC/SMC）、未定义指令。我在调试一个GPU驱动时，遇到过数据中止导致系统重启的问题。查了半天，发现是页表配置错了。
异步异常：IRQ（普通中断）、FIQ（快速中断）、SError（系统错误）。SError这玩意儿比较坑，它可能来自内存ECC错误或者总线故障。

注意：我曾经在项目中遇到一个SError，它是在异常返回后才触发的。当时我以为是代码逻辑问题，折腾了两天。后来才发现，SError是异步的，它不会立即被处理，而是等到当前异常处理完才上报。这个坑，我建议你提前记住。

2.3 安全状态：Secure与Non-Secure

ARMv9的安全架构基于TrustZone技术。系统被划分为两个世界：安全世界（Secure World）和普通世界（Non-Secure World）。

为什么需要这个？举个例子：你的手机支付应用需要处理指纹数据。这些数据如果放在普通世界，恶意应用可能通过侧信道攻击窃取。放在安全世界，普通世界的代码根本访问不到。

安全状态的切换通过SMC（Secure Monitor Call）指令实现。EL3的Secure Monitor负责处理这个切换。我记得第一次写SMC处理程序时，忘了保存上下文，结果安全世界返回后，普通世界的寄存器全乱了。嗯，从那以后我再也不敢省略上下文保存了。

  关键点：安全世界和普通世界有各自的内存空间、中断控制器配置和外设访问权限。它们之间通过共享内存通信时，必须使用特定的协议（如OP-TEE的SMC接口）。

2.4 Realm Management Extension (RME) 深度解析

RME是ARMv9引入的新特性。它扩展了安全模型，增加了一个新的异常等级——EL2 Realm。说白了，RME让你能在普通世界和安全世界之外，再创建一个"领域"（Realm）。

这个领域有什么用？想象一下：你有一个云服务，需要处理用户数据。传统方案要么把数据放在普通世界（不安全），要么放在安全世界（性能受限）。RME的Realm提供了一个中间地带——数据在Realm中加密，连Hypervisor和Secure Monitor都看不到。

RME的核心是Granule Protection Table（GPT）。它定义了每个内存粒度的访问权限。粒度通常是4KB或64KB。GPT的配置在EL3完成，Realm和Secure World都无权修改。

  RME的关键特性：
  新增EL2 Realm等级，用于隔离敏感工作负载
GPT提供硬件级的内存隔离
支持动态创建和销毁Realm
与现有TrustZone兼容，可同时运行

我在一个机密计算项目中用过RME。当时需要在云平台上保护用户模型数据。传统方案用Intel SGX，但迁移到ARM平台后，RME的Realm机制让事情简单了不少。不过要注意，RME的配置比较复杂，尤其是GPT的初始化，一旦配错，系统直接挂掉。

调试建议：如果你刚开始接触RME，建议先用QEMU模拟器测试。ARM提供了RME的QEMU支持，可以在没有硬件的情况下验证GPT配置和Realm创建流程。

2.5 异常处理流程

异常发生时，CPU会做以下几件事：

保存当前状态到SPSR（Saved Program Status Register）
跳转到异常向量表（Exception Vector Table）中对应的入口
根据异常类型，自动切换异常等级和安全状态
执行异常处理程序
通过ERET指令返回，恢复SPSR到PSTATE

异常向量表在AArch64中固定为0x800字节大小。每个异常类型有4个入口，分别对应不同的执行状态。我建议你把向量表放在一个独立的4KB页中，方便管理。

// 异常向量表示例（AArch64）
.align 12
.global exception_vector_table
exception_vector_table:
    // EL1t 同步
    .word sync_el1t
    // EL1t IRQ
    .word irq_el1t
    // EL1t FIQ
    .word fiq_el1t
    // EL1t SError
    .word serror_el1t
    // ... 其他入口

常见错误：我见过有人把异常向量表放在非对齐地址上。ARMv9要求向量表必须4KB对齐，否则异常触发时CPU直接跳转到错误地址。这个bug很难查，因为系统可能随机崩溃。

2.6 安全架构的实践建议

最后，分享几个我在项目中总结的经验：

EL3代码要精简：EL3运行在最高权限，但性能受限。把复杂逻辑放在EL1或EL2，EL3只做切换和验证。
GPT配置要谨慎：RME的GPT一旦配置错误，可能导致安全世界无法访问必要内存。建议在开发阶段启用GPT的调试模式。
异常优先级要清楚：SError的优先级高于IRQ和FIQ。如果你的系统有ECC内存，SError处理程序必须能快速响应。
安全通信用共享内存：安全世界和普通世界之间，用共享内存加消息队列的方式通信，比SMC调用高效得多。

嗯，这一章的内容就到这里。异常模型和安全架构是ARMv9的基石，理解透了，后面的虚拟化、内存管理、性能调优才能顺利展开。