2. TEE架构剖析

各位同学，今天我们来啃一块硬骨头——ARM TrustZone。说实话，TrustZone这玩意儿在移动设备里已经铺了十几年了，但真正能把它讲清楚的人不多。我当年刚接触TEE时，看了好几份白皮书，愣是没搞明白安全世界和普通世界到底怎么切来切去的。后来亲手调过几回Monitor模式的异常向量表，才算真正通了。

好，咱们不绕弯子，直接开整。

2.1 TrustZone的核心思想：一个物理核，两个虚拟世界

ARM TrustZone不是加了一个独立的硬件安全模块，而是在现有的CPU核上做了扩展。说白了，就是让一个物理核能跑出两种“人格”——安全世界（Secure World）和普通世界（Normal World）。

你想想看，这跟虚拟化有点像，但又不完全一样。虚拟化是让一个核跑多个操作系统，而TrustZone是让一个核在两种安全状态下切换。硬件层面通过一个叫NS（Non-Secure）的比特位来标记当前是哪个世界。

我在项目中遇到过一件事：有个同事想直接在Linux里读写安全内存，结果一访问就触发Data Abort，系统直接挂掉。嗯，这就是硬件隔离在起作用，不是软件能绕过去的。

2.2 安全世界 vs 普通世界：到底有什么区别？

咱们用一张表来对比一下这两个世界的差异：

特性	普通世界（Normal World）	安全世界（Secure World）
操作系统	Android、Linux、RTOS	Trusted OS（如OP-TEE、QSEE）
内存访问	只能访问非安全内存	可访问安全和非安全内存
外设访问	非安全外设	安全外设（如指纹传感器、安全键盘）
中断处理	普通中断（IRQ）	安全中断（FIQ）
调试权限	可调试	通常禁止调试

说白了，安全世界就是“特权阶级”，它什么都能看。普通世界就是“平民”，只能看自己的那一亩三分地。这种设计保证了即使普通世界的操作系统被攻破了，攻击者也拿不到安全世界里的密钥、指纹数据等敏感信息。

2.3 两个世界怎么切换？——Monitor模式登场

好，现在问题来了：两个世界互相隔离，那它们之间怎么通信？总不能让安全世界和普通世界老死不相往来吧？

这时候就需要一个“看门人”——Monitor模式。Monitor模式是ARM架构中比安全世界还高一级的特权模式，它专门负责两个世界之间的切换。

我个人习惯把Monitor模式想象成一个“安全门禁”。普通世界想进安全世界，必须通过这个门禁。门禁会检查你的身份（通过SMC指令）、清理现场（保存上下文）、然后才放你进去。

2.4 世界切换的完整流程

咱们来看一个典型的切换场景：普通世界的App想调用安全世界的加密服务。

1. 发起调用：普通世界的App通过TEE Client API发起请求，调用libteec库。
2. 陷入内核：libteec通过ioctl进入Linux内核的TEE驱动。
3. 触发SMC：TEE驱动执行SMC（Secure Monitor Call）指令，CPU陷入Monitor模式。
4. 上下文保存：Monitor保存普通世界的寄存器状态，切换到安全世界。
5. 分发请求：安全世界的TEE内核接收请求，分发给对应的Trusted Application。
6. 执行服务：Trusted Application在安全世界执行加密操作。
7. 返回结果：结果通过同样的路径返回给普通世界。

整个过程看起来步骤多，但实际上在硬件层面，SMC指令的执行非常快。我记得有一次做性能测试，一次完整的世界切换大概只需要几微秒。当然，如果频繁切换，性能开销还是不可忽视的。

2.5 Monitor模式详解：到底干了什么？

Monitor模式的核心工作可以概括为三件事：

• 上下文切换：保存当前世界的寄存器状态，恢复目标世界的寄存器状态。这包括通用寄存器、系统寄存器、协处理器状态等。
• 安全检查：验证切换请求是否合法。比如检查SMC参数是否在允许范围内。
• 异常处理：处理安全相关的异常，比如安全中断（FIQ）的响应。

下面是一个简化的Monitor模式异常向量表示例：

/* 简化的Monitor异常向量表 */
.section .vectors, "ax"
.align 5

monitor_vectors:
    b    monitor_reset         /* 0x00: 复位 */
    b    monitor_undef         /* 0x04: 未定义指令 */
    b    monitor_smc           /* 0x08: SMC指令 */
    b    monitor_prefetch_abort /* 0x0C: 预取异常 */
    b    monitor_data_abort    /* 0x10: 数据异常 */
    b    monitor_reserved      /* 0x14: 保留 */
    b    monitor_irq           /* 0x18: IRQ中断 */
    b    monitor_fiq           /* 0x1C: FIQ中断 */

monitor_smc:
    /* 保存普通世界上下文 */
    stmfd   sp!, {r0-r12, lr}
    
    /* 检查SMC功能号 */
    mov     r0, #FUNC_CHECK
    bl      smc_handler
    
    /* 恢复安全世界上下文 */
    ldmfd   sp!, {r0-r12, pc}^

嗯，这里要注意，实际的ATF代码比这个复杂得多，但核心逻辑就是保存上下文、处理请求、恢复上下文这三板斧。

2.6 硬件层面的隔离机制

TrustZone的隔离不仅仅是软件层面的，硬件层面也做了很多工作：

• 内存总线：ARM的AXI总线增加了一个NS位，所有内存访问都会带上这个标记。安全世界的访问NS=0，普通世界的访问NS=1。
• 缓存：L1和L2缓存也支持安全标记，防止普通世界通过缓存侧信道攻击获取安全数据。
• 中断控制器：GIC（通用中断控制器）支持将中断配置为安全中断（FIQ）或非安全中断（IRQ）。
• 调试接口：JTAG/SWD调试接口可以被安全世界锁定，防止攻击者通过调试接口读取安全内存。

说白了，TrustZone的隔离是从CPU核到总线到外设的全链路隔离。这也是为什么它比纯软件方案（比如seccomp）要安全得多。

2.7 一张图看懂TrustZone架构

下面我用SVG画了一张TrustZone的核心架构图，把刚才讲的内容串起来：

这张图把三个核心区域的关系画得很清楚。左边是普通世界，右边是安全世界，中间是Monitor模式。两个世界之间的所有通信都必须经过Monitor这个“门禁”。

2.8 实际部署中的注意事项

最后，结合我自己的经验，给大家几个实际部署时的建议：

• 中断路由要规划好：安全中断（FIQ）和非安全中断（IRQ）的分配要提前设计好。我见过一个项目把安全中断配错了，导致安全世界被普通世界的中断频繁打断，性能惨不忍睹。
• 内存隔离要彻底：安全内存和非安全内存的物理地址空间要严格分开，不能有重叠。我曾经在调试时发现安全世界能读到普通世界的内存，后来查出来是页表配置错了。
• 调试接口要锁死：产品量产时一定要把JTAG/SWD调试接口锁死，否则攻击者可以通过调试接口直接读取安全内存。嗯，这个坑我踩过，不说了都是泪。
• 上下文切换要高效：尽量减少世界切换的次数。每次切换都有开销，频繁切换会影响系统实时性。