在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安全问题大量集中在“
