在ARM TrustZone生态里，OP-TEE是很多设备默认的可信执行环境（TEE）。它的任务是提供一个跑在“安全世界”（Secure World）里的操作系统，让密钥、支付凭证、生物识别数据等高价值资产在一个相对隔离的环境里处理。我第一次接触OP-TEE时，预期和其他人差不多：既然信任链从硬件隔离开始，Secure World里的代码似乎天然安全。但后面做TEE安全评估，越来越确认一个判断：隔离只解决“不能直接访问”的问题，并不解决“接口调用带来的输入暴露”问题。Trustfall项目披露的RSA堆下溢漏洞，就是一个很典型的例子——一个加密库里的内存写错误，让攻击者从普通世界一步步走进了Secure World。
这里说的“Trustfall”，是一个面向TEE类型环境的安全研究项目，重点研究OP-TEE这类开源可信执行环境。它的核心价值不在于某一台设备的利用演示，而在于验证了一个关键结论：可信执行环境的安全，不依赖“我运行在安全世界”这个标签，而是依赖边界内部每一行代码对输入范围的处理。
下面我会从TrustZone的信任模型开始，把RSA堆下溢为什么会发生在Secure World里、攻击链条怎么走、防御者应该怎么响应这几个问题完整拆开讲。
1. 认知纠偏：TEE的边界到底隔离了什么
1.1 TrustZone的硬件隔离与软件信任
ARM TrustZone从硬件层面把系统分成了两个世界：普通世界（Normal World）和安全世界（Secure World）。REE侧的Linux、Android或者RTOS跑在普通世界，OP-TEE OS跑在安全世界。内存管理单元、总线和外设控制器会把特定内存区域标记为“安全”，普通世界的程序即便拿到root，也不能直接访问这些安全内存。
这个设计解决的是一个很基础的问题：普通世界里的恶意代码不能直接偷偷读取安全内存里的密钥。但要注意，硬件没有做另一件事——它没有禁止安全世界与普通世界通信。实际上，TEE为了对外提供服务，必须接收来自普通世界的请求。
这些请求会以多种形式出现：
- 普通世界应用通过TEE Client API发起会话；
- 调用者传入共享内存缓冲区，里面装着要被加密、签名或解析的数据；
- TA在运行过程中可能继续从REE侧接收补充数据；
- 安全存储的备份、导入导出流程也可能引入外部数据。
一旦数据进入Secure World，就变成了OP-TEE内核和TA来处理。处理的是不可信输入，而且是高价值的不可信输入。
1.2 从REE到TA，真正的输入面在哪里
OP-TEE的调用路径大致是这样的：
普通世界应用 → libteec → Linux内核驱动 → SMC陷入Secure Monitor → OP-TEE Core → 分发到TA。
其中任何一个环节都可能被攻击者控制。如果REE侧本身已经被攻陷，那么攻击者可以：
- 构造任意格式的共享内存数据；
- 以各种非法参数调用TA；
- 篡改传参的缓冲区长度，伪造密钥对象；
- 调用多个TA，寻找解析最薄弱的那一个。
所以真正需要被审视的，并不是Secure World的“隔离墙”够不够高，而是Secure World内部所有能接触到REE数据的函数，是否都做到了正确的输入验证。
1.3 大多数TEE漏洞不是芯片后门，而是输入处理失守
过去公开的TEE安全问题，大量集中在“
