TEE-TA学习轨迹第一篇：TA的启动方式和实体运行地址空间

原创于 2026-06-25 10:31:01 发布 · 193 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Android系统安全 #ATF #系统安全 #安全启动 #TA

话题

#开源项目吐槽大会

Android系统安全专栏收录该内容

63 篇文章

订阅专栏

在以 OP-TEE 为代表的主流 TEE 操作系统中，可信应用（TA）是安全服务的实际载体，全程运行在安全世界隔离环境中，非安全世界（Android/Linux 等 REE 侧）无法直接读写 TA 的代码、内存与敏感数据。

结合之前分析的线程模型、SMC 调用、RPC 机制，TA 的启动与运行主要分为静态内置型和动态加载型两大类，两者在特权级、生命周期、隔离强度、适用场景上有本质差异。

一、两种核心 TA 的运行与启动原理

方式1：静态内置 TA（Pseudo TA / 内核态 TA）

本质定义

静态 TA 的代码会和 OP-TEE 内核源码一起编译、一起链接，最终打包进 OP-TEE 整体镜像中，随 BL2 加载到安全内存。它本质是 TEE 内核的一部分功能模块，只是以 TA 的 UUID 接口形式对外提供服务。

运行特权级

运行在 S-EL1 内核特权级，与 TEE 内核共享地址空间、共享内核栈，没有独立的用户态线程。

完整启动/调用流程

1.编译链接阶段

TA 源码随 OP-TEE 内核一同编译，通过内核的 TA 注册宏将自身的 UUID 和处理函数绑定，最终链接进内核镜像，随内核一起完成签名校验。

2.冷启动初始化

OP-TEE 内核初始化的后半段，遍历所有内置 TA 的注册表，执行每个 TA 的初始化函数，完成硬件资源初始化、全局状态准备，服务注册完成后对外可见。

3.运行时调用

非安全世界发起对应 UUID 的 SMC 调用 → OPTEED 转发到 TEE 内核 → 内核通过 UUID 匹配到对应静态 TA 的处理函数 → 直接在当前内核上下文中执行业务逻辑 → 结果原路返回。

全程不需要创建新线程、不需要地址空间切换、没有加载开销，直接在内核态完成处理。

核心特点

启动极快，零加载开销，系统上电即可用
权限最高，可直接访问硬件加密引擎、efuse、安全寄存器等底层资源
随内核镜像一起签名，无法被动态替换，防篡改能力强
无用户态隔离，TA 代码漏洞会直接影响整个 TEE 内核安全

方式2：动态加载 TA（User TA / 用户态 TA）

这是最常见、最通用的 TA 形态，Android 系统中绝大多数业务侧安全服务（支付、指纹、DRM 等）都采用这种方式。

本质定义

TA 是独立编译的 ELF 可执行文件，单独签名，存放在非安全世界的文件系统中；按需加载、用完可释放，运行时才被载入安全世界的独立地址空间。

运行特权级

运行在 S-EL0 用户特权级，每个 TA 拥有独立的虚拟地址空间、独立的线程栈，与 TEE 内核、其他 TA 完全沙箱隔离。TA 只能通过系统调用（SVC 指令）访问内核提供的服务，无法直接访问硬件和内核内存。

完整启动/运行流程

1.会话发起

非安全世界客户端（如 Android HAL、APP）通过 TEE 驱动发起 open_session 请求，携带目标 TA 的 UUID，SMC 陷入 EL3 后转发到 TEE 内核。

2.加载触发与 RPC 回读

TEE 内核查找本地已加载的 TA 列表，若未找到该 UUID，会主动发起 RPC 调用（对应之前的 thread_rpc_spsr 机制），切回非安全世界，请求 tee_supplicant 读取 TA 镜像文件。

3.镜像传输与校验

tee_supplicant 从文件系统读取 TA 的 ELF 镜像，通过共享内存传递到安全世界；TEE 内核校验 TA 的数字签名、完整性、权限配置（manifest），校验不通过直接拒绝加载。

4.运行环境构建

校验通过后，内核为 TA 分配独立资源：

分配独立的虚拟地址空间，映射 TA 的代码段（只读可执行）、数据段（可读写不可执行）、栈空间
调用 __thread_alloc_and_run 创建专属线程，初始化线程上下文
配置 S-EL0 程序状态、用户栈指针，构造异常返回现场

5.切入 TA 执行

调用 thread_enter_user_mode，通过 ERET 指令从 S-EL1 降到 S-EL0，跳转到 TA 的入口函数，TA 正式开始执行业务逻辑。

6.退出与资源回收

TA 执行完成、或调用 close_session 时，线程退出，地址空间销毁，安全内存回收，TA 回到未加载状态。

核心特点

灵活可独立升级，不需要修改 TEE 内核即可更新 TA 功能
隔离性强，单 TA 漏洞不会直接波及内核和其他 TA
按需加载，不常驻占用稀缺的安全内存
有加载与校验开销，首次调用延迟更高
依赖非安全世界提供镜像，需依赖签名校验保障安全

二、两种 TA 方式核心对比

对比维度	静态内置 TA（Pseudo TA）	动态加载 TA（User TA）
运行特权级	S-EL1 内核态	S-EL0 用户态
加载时机	随内核冷启动一起加载，全程常驻	按需动态加载，用完可释放
地址空间	与内核共享，无独立隔离	独立虚拟地址空间，沙箱隔离
调用性能	零加载开销，调用延迟极低	首次调用有加载、校验开销，会话建立慢
升级方式	必须随 TEE 整包升级，无法单独更新	可独立升级替换，灵活度高
安全强度	防篡改能力强，但单 TA 漏洞可击穿整个内核	沙箱隔离，攻击面更小，漏洞影响范围有限
资源占用	常驻安全内存，占用固定	按需占用，空闲时不消耗安全内存
典型适用场景	根密钥管理、硬件抽象、核心安全服务	业务类安全服务、支付、DRM、生物识别

三、典型落地案例

案例1：静态内置 TA —— 设备根密钥管理服务（RKMS）

业务场景

Android 设备的硬件级根密钥派生与存储，是 Keystore 服务、全盘加密、设备认证的底层根基。比如设备出厂时烧录在 efuse 中的唯一密钥，所有业务密钥都由它派生而来，绝对不能泄露到非安全世界，也不能被篡改。

为什么选择静态内置方案

启动时序要求：设备开机阶段需要先解密数据分区，再加载文件系统，因此密钥服务必须在文件系统可用前就就绪，只能随内核一起启动。
最高安全等级：根密钥直接对接硬件加密引擎和 efuse 硬件，运行在内核态可避免用户态/内核态切换的攻击面；同时随内核镜像一起签名，攻击者无法通过替换 TA 的方式窃取根密钥。
极致性能：Keystore 调用非常高频，静态 TA 零加载开销，保证上层业务的响应速度。

运行方式

冷启动时随 OP-TEE 内核完成初始化，全程常驻内核态；上层每次密钥生成、签名、加密请求，都通过 SMC 直接进入内核态 TA 处理，全程无额外加载与切换开销。

案例2：动态加载 TA —— Widevine L1 DRM 可信应用

业务场景

流媒体高清版权保护，比如 Netflix、Disney+、国内主流视频平台的 1080P/4K 超清播放。Widevine L1 等级要求视频解密、解帧全程在安全世界完成，非安全世界无法拿到明文视频内容，防止录屏、盗版抓取。

为什么选择动态加载方案

解耦升级：Widevine 方案由 Google 提供，和设备厂商的 TEE 内核完全解耦，DRM 版本更新不需要升级整个 TEE 镜像，厂商适配成本极低。
资源效率：只有播放视频时才加载 TA，平时不占用宝贵的安全内存；安全内存是 TEE 最稀缺的资源，动态加载能大幅提升资源利用率。
故障隔离：DRM TA 逻辑复杂、攻击面大，运行在 S-EL0 用户态沙箱中，即使出现漏洞也无法直接访问 TEE 内核和其他 TA 的敏感数据，故障影响范围可控。