深入浅出ARM64工作模式：从零理解异常级别EL0～EL3
你有没有想过，当你在手机上打开一个App时，系统是如何确保这个应用不会偷偷修改内核、窃取指纹数据，甚至干扰其他程序运行的？
答案就藏在处理器的运行模式设计中。对于现代ARM64架构来说，这一切的核心机制就是——异常级别（Exception Level, EL）。
ARM64不再像早期处理器那样简单地区分“用户态”和“内核态”，而是构建了一个四层权限金字塔：EL0 到 EL3。每一级都像是一个安全门禁区域，只有持有相应权限的代码才能进入。这种设计不仅支撑了Linux系统的稳定运行，更是TrustZone安全环境、虚拟化云服务器和TEE可信执行环境的技术基石。
本文不堆术语、不抄手册，带你用“人话”搞懂ARM64的工作模式。无论你是嵌入式新手、操作系统爱好者，还是想深入了解安全启动流程的开发者，这篇文章都会让你建立起清晰的体系认知。
为什么需要多个运行级别？
在x86时代，我们习惯于“用户态 vs 内核态”的二元模型。但在移动计算与云计算并行发展的今天，这种简单的划分已经不够用了：
- 手机要同时运行普通App和支付类可信应用（如支付宝刷脸），它们必须物理隔离。
- 云服务器要在同一台机器上跑多个独立的操作系统实例，这就需要虚拟化支持。
- 系统启动过程中，固件需要以最高权限初始化硬件，并安全地交棒给操作系统。
于是，ARM64引入了四级异常级别（EL0～EL3），形成一个自底向上逐级提权、自顶向下实施监管的分层控制结构。这就像一栋大楼：
+------------------+ | EL3 | ← 安全监控室（安保总控） +------------------+ | EL2 | ← 虚拟化管理层（物业经理） +------------------+ | EL1 | ← 操作系统内核（住户管理员） +------------------+ | EL0 | ← 用户应用程序（普通住户） +------------------+每上升一级，权限就更强一点；而高权限层可以对低层进行拦截、监控和调度。接下来我们一层一层拆解。
EL0：普通用户的“安全牢笼”
这是所有应用程序运行的地方——你的微信、抖音、终端命令，通通都在 EL0。
听起来地位不高，但它存在的意义极其重要：限制风险。
在 EL0 中：
- 不能直接访问硬件寄存器
- 无法修改页表或启用/关闭MMU
- 连中断都不能随便开闭
- 所有系统调用必须通过svc指令触发异常，陷入更高层级处理
你可以把它想象成一个被严格看管的沙盒。哪怕你在程序里写了个死循环或者越界读内存，顶多只是自己崩溃，绝不会波及整个系统。
✅ 典型场景：Android App、Linux shell脚本、Python脚本均运行于此。
但这也意味着，任何涉及资源请求的操作（比如打开文件、分配内存），都要“打报告”给上级——也就是跳转到 EL1。
EL1：操作系统内核的主场
当用户程序执行svc #0x80时，CPU会立即切换到 EL1，开始执行内核代码。这就是所谓的“陷入（trap）”。
在 EL1，操作系统获得了真正的控制权：
- 可以配置虚拟内存（VMSA）
- 能管理中断控制器（GIC）
- 控制定时器、调度进程、加载驱动
关键寄存器包括：
| 寄存器 | 功能说明 |
|---|---|
VBAR_EL1 | 异常向量表基地址，告诉CPU发生异常时该跳去哪 |
SPSR_EL1 | 保存异常前的状态（如当前运行级别、中断使能状态） |
ELR_EL1 | 记录异常发生的返回地址，用于恢复执行 |
举个例子：你想打印一段日志到屏幕，调用了printf()→ 最终触发write()系统调用 → 发出svc指令 → CPU跳转至VBAR_EL1 + 0x0处的同步异常向量 → 内核解析为 sys_write 并执行 → 完成后通过eret返回 EL0。
// 设置异常向量表（C封装） void set_vector_base(uint64_t base) { asm volatile("msr vbar_el1, %0" :: "r"(base)); }⚠️ 注意：VBAR_EL1必须64字节对齐，否则将引发不可恢复异常！这是很多初学者踩过的坑。
此外，每个异常级别最好使用独立的栈指针（例如用sp_el1作为EL1专用栈），避免用户栈溢出污染内核上下文。
EL2：虚拟化的舞台中央
如果你听说过 KVM、Xen 或者容器化云服务，那你一定绕不开 EL2。
EL2 是专门为Hypervisor（虚拟机监视器）设计的特权级别。它的核心任务是：让多个操作系统在同一块芯片上互不干扰地运行。
怎么做到的？靠的是两个关键技术：
1. Stage 2 地址转换
我们知道，操作系统负责把虚拟地址转成“物理地址”。但在虚拟机里，“物理地址”其实是假的——它还要再映射一次到真实的主机物理地址。
这就是 Stage 2 MMU 的作用：
- Stage 1：Guest OS 管理的 VA → IPA（Intermediate Physical Address）
- Stage 2：Hypervisor 管理的 IPA → PA（Physical Address）
两级页表共同完成最终地址翻译，实现内存隔离。
2. 捕获与模拟
某些敏感指令（比如访问协处理器 CP15）会被自动捕获并转发给 Hypervisor 处理。Hypervisor 可以选择模拟执行结果，也可以拒绝操作。
控制这一切的是HCR_EL2（Hypervisor Control Register）：
| 位域 | 作用 |
|---|---|
TVM | 是否捕获对虚拟内存系统的访问 |
TGE | 启用全局异常路由，统一管理中断 |
VM | 开启虚拟化功能开关 |
有了 EL2，ARM平台终于能原生支持高效虚拟化，无需依赖复杂的二进制翻译技术。如今亚马逊 Graviton 实例、华为云鲲鹏虚拟机，背后都是这套机制在支撑。
⚠️ 常见问题：若未正确设置
VTTBR_EL2（虚拟机二级页表基址），可能导致虚拟机启动失败或内存泄漏。
EL3：安全世界的守门人
如果说 EL2 是为了“多租户隔离”，那么 EL3 就是为了“安全隔离”而生。
它是 TrustZone 技术的核心所在，只做一件事：在安全世界（Secure World）和非安全世界（Normal World）之间切换。
这个过程通过一条特殊指令完成：SMC（Secure Monitor Call）。无论是操作系统还是虚拟机，只要想进入安全环境，就必须执行smc触发异常，进入 EL3 进行身份验证和上下文切换。
关键寄存器：SCR_EL3
| 字段 | 含义 |
|---|---|
NS | 0=安全世界，1=非安全世界 |
IRQ/FIQ | 是否允许来自安全世界的中断 |
ST | 是否启用安全定时器访问 |
RET | 是否允许从安全世界干净返回 |
典型的 SMC 处理流程如下：
void smc_handler(void) { uint64_t caller_addr; asm volatile("mrs %0, elr_el3" : "=r"(caller_addr)); uint32_t func_id = get_smc_function_id(); if (func_id == SMC_ID_SECURE_BOOT_CHECK) { scr_el3 &= ~SCR_NS; // 切换至安全世界 secure_world_entry(); } else { scr_el3 |= SCR_NS; // 维持非安全世界 normal_world_resume(caller_addr); } }这段代码看起来简单，却是实现 OP-TEE、Trusty TEE 等可信执行环境的基础逻辑。
💡 提示：EL3 代码应尽可能精简，因为它运行在最高特权级，一旦出错或存在漏洞，整个系统的信任链就会崩塌。
四级联动：一次系统调用的真实旅程
让我们以 Linux 中调用write()为例，完整走一遍 ARM64 的异常流转路径：
用户程序执行
svc #0x80
→ CPU 保存现场至SPSR_EL1，跳转至VBAR_EL1对应的同步异常入口内核识别系统调用号，调用
sys_write()
→ 执行文件系统逻辑，可能触发缺页中断 → 再次陷入 EL1 处理若系统运行在虚拟机中
→ 内核尝试访问 GIC 寄存器 → 被 EL2 捕获 → Hypervisor 模拟中断控制器行为若涉及加密操作（如写入密钥文件）
→ 内核发起 SMC 调用 → 陷入 EL3 → 切换至安全世界执行加密算法 → 安全返回所有操作完成后，执行
eret指令逐级返回
→ 最终回到 EL0，用户程序继续执行
整个过程就像一场精密的接力赛，每一棒都有明确职责，且不允许越界。
工程实践中必须注意的几个坑
别以为知道概念就够了，实际开发中这些细节决定成败：
1. 向量表必须对齐
VBAR_EL1/EL2/EL3都要求64字节对齐。未对齐会导致 CPU 进入“锁定状态”，只能重启解决。
2. 栈空间独立分配
每个 EL 应有自己的栈空间。推荐做法：
- 使用SP_ELx寄存器指向专属栈
- 初始化阶段在汇编中提前设置好，防止异常嵌套时栈混乱
3. 异常优先级要合理配置
使用 GICv3 时，需正确设置中断优先级掩码（PMR_EL1）和组使能位（ICC_IGRPEN*），否则可能出现高优先级中断被阻塞的情况。
4. EL3 要遵循最小权限原则
不要在 EL3 做复杂运算或网络通信！它只负责快速切换和基础验证，其余交给安全OS处理。
5. 调试建议：善用 QEMU + GDB
搭建实验环境最方便的方式是使用 QEMU 模拟 AArch64 平台：
qemu-system-aarch64 -machine virt -cpu cortex-a57 \ -nographic -s -S然后用 GDB 连接调试，单步跟踪异常入口、寄存器变化，直观理解流程。
掌握ARM64工作模式的价值在哪？
也许你会问：“我只是个应用开发者，了解这些有必要吗？”
答案是：非常有必要，尤其是在以下场景：
- 移植Bootloader（如 U-Boot、ATF）时，必须清楚 BL1 在 EL3 初始化 TrustZone，BL2 在 EL2 启动 Hypervisor
- 编写内核模块或驱动时，要知道哪些寄存器只能在 EL1 访问，哪些会被 EL2 拦截
- 做安全研究时，理解 SMC 攻击面、探索降级漏洞（如 Downcortex）都依赖对 EL 切换机制的掌握
- 优化性能时，了解异常延迟和上下文切换成本有助于写出更高效的中断服务程序
更重要的是，随着 RISC-V 等新架构兴起，其异常模型也借鉴了 ARM64 的 EL 分层思想。掌握这一套逻辑，等于掌握了现代处理器安全与虚拟化设计的通用范式。
如果你现在再去翻看 Linux 内核源码中的entry.S，或是 ATF（Arm Trusted Firmware）里的el3_entrypoint.c，那些曾经晦涩难懂的汇编代码，是不是突然变得清晰了许多？
ARM64 的异常级别不是冷冰冰的规格文档，而是一套精心设计的权力制衡系统。它让我们的设备既能高效运行海量应用，又能守住安全底线。
下一步，不妨动手试试：用 QEMU 写一个最简单的异常处理程序，捕获svc指令并打印寄存器值。你会发现，理论一旦落地，理解就会真正属于自己。
💬 如果你在实践过程中遇到具体问题，欢迎留言交流。我们一起把底层技术讲透。
