3、TEE基础与安全模型：TEE与REE的隔离架构、TrustZone与Trusted OS（OP-TEE）概述、安全启动链与信任根
好，我们进入第三章。这一章是理论基石，但我会尽量讲得「接地气」一点。
很多做UEFI启动的工程师，第一次接触TEE时都会懵：
「我明明已经用UEFI Secure Boot把系统保护起来了，为什么还要搞一个TEE？」
这个问题，我当年也问过。后来在一个金融支付项目里，客户要求指纹数据「即使内核被攻破也不能泄露」——我才真正理解了TEE的价值。
说白了，TEE解决的是「特权软件不可信」的问题。你想想看，就算你的Bootloader是安全的，操作系统内核一旦有漏洞，所有数据都白搭。TEE就是在硬件层面给你一个「安全飞地」。
3.1 TEE与REE的隔离架构
先看一张图，这是整个TEE架构的核心逻辑。
核心概念：TEE（Trusted Execution Environment，可信执行环境）与REE（Rich Execution Environment，富执行环境）共享同一个物理处理器，但在硬件层面被强制隔离。
这张图我建议你多看两眼。它解释了为什么TEE能「防住」一个被攻破的操作系统。
隔离的核心机制有三点：
- 内存隔离：TEE拥有独立的安全内存区域（TZASC/ TZMA控制），REE的DMA和CPU都无法直接访问。
- 中断隔离：安全中断（FIQ）直接路由到TEE，REE无法拦截或伪造。
- 外设隔离：通过TrustZone地址空间控制器（TZPC），将外设（如键盘、指纹传感器）分配给TEE独占。
我的经验：有一次调试一个OP-TEE的共享内存问题，发现REE侧往共享缓冲区写数据后，TA读到的全是0x00。查了两天，最后发现是TZASC的配置把共享内存区域设成了「安全」属性，REE根本写不进去。嗯，隔离是双向的——你配置错了，两边都跑不通。
3.2 TrustZone与Trusted OS（OP-TEE）概述
ARM TrustZone是TEE的硬件基础。它把处理器状态分成两个世界：
| 特性 | 正常世界（Normal World） | 安全世界（Secure World） |
|---|---|---|
| 运行环境 | Linux、Android、Windows | Trusted OS（OP-TEE、Trusty、QSEE） |
| 内存访问 | 仅非安全内存 | 安全内存 + 非安全内存（需配置） |
| 中断处理 | IRQ | FIQ（安全中断） |
| 启动顺序 | 后启动 | 先启动（安全世界先于正常世界） |
| 典型应用 | 用户界面、网络、存储 | 密钥管理、支付、DRM、生物识别 |
OP-TEE是目前最流行的开源Trusted OS。我为什么推荐它？
- 代码开源，社区活跃（Linaro维护）
- 支持ARMv7和ARMv8架构
- 与UEFI有成熟的集成方案（后面章节会实战）
- 有完善的文档和测试套件
OP-TEE的架构分三层：
- OP-TEE OS（内核层）：运行在安全世界的内核，负责任务调度、内存管理、加密服务。
- OP-TEE Client（客户端API）：运行在REE侧，提供libteec库，供普通应用调用TEE功能。
- OP-TEE TA（可信应用）：运行在安全世界的应用，处理敏感数据。
注意：OP-TEE的TA编译后是一个独立的二进制文件（.ta），它不能直接调用REE的API。所有输入输出必须通过参数传递。我曾经见过一个新手把printf直接写在TA里——编译能过，但运行时空指针崩溃。TA里只能用TEE内部API（TEE Internal API）。
3.3 安全启动链与信任根
这是整个课程最核心的概念之一。安全启动链，说白了就是「谁证明谁」的问题。
你想想看：TEE本身也是一个软件，它凭什么可信？
答案就是——信任根（Root of Trust）。
典型的TEE安全启动链如下：
BootROM（信任根）
↓ 验证
Bootloader（BL1/BL2）
↓ 验证
OP-TEE OS（安全世界内核）
↓ 验证
REE Bootloader（UEFI / U-Boot）
↓ 验证
REE OS（Linux / Windows）
↓ 验证
REE 应用每一步都验证下一步的签名，形成一个「信任链」。信任链的起点是BootROM——它固化在芯片内部，不可修改。
关键点：在TEE联合启动场景中，OP-TEE的启动必须早于REE。因为REE的启动参数、安全策略、密钥材料都需要由TEE提供。如果REE先启动，TEE的安全性就无法保证——你想想看，一个被攻破的REE可以伪造TEE的启动镜像。
我参与过一个项目，客户坚持要「先启动Linux，再加载OP-TEE」。结果安全审计时被直接打回——因为攻击者可以在Linux启动阶段篡改OP-TEE的镜像。后来改成了UEFI -> OP-TEE -> Linux的顺序，才通过认证。
信任根的具体实现方式：
| 信任根类型 | 存储位置 | 特点 |
|---|---|---|
| BootROM | 芯片内部ROM | 不可修改，出厂固化 |
| eFuse | 芯片内部一次性编程 | 可烧录公钥哈希，防回滚 |
| OTP | 芯片内部一次性编程 | 存储设备唯一密钥 |
| 安全存储 | TEE内部加密分区 | 由TEE密钥保护，可更新 |
避坑指南：我曾经在调试安全启动时，发现OP-TEE启动后总是报签名验证失败。查了半天，发现是eFuse里烧录的公钥哈希和OP-TEE镜像的签名公钥不匹配——因为开发板出厂时烧录的是测试密钥，而我用的是生产密钥签名。嗯，这个问题在量产时尤其容易踩坑，建议在硬件设计阶段就规划好密钥管理流程。
最后，我想强调一个容易被忽略的点：信任根不是一次性的。
在设备整个生命周期中，你可能需要更新OP-TEE、更新REE、甚至更换密钥。所以安全启动链必须支持「安全更新」——即只有经过签名的更新包才能被加载。这个机制在UEFI中叫做「Secure Boot Update」，在OP-TEE中叫做「Secure Storage Update」。后面章节我们会手把手实现。
好，这一章的理论基础就到这里。记住三句话：
- TEE和REE是硬件隔离的，不是软件隔离的。
- OP-TEE是开源Trusted OS的首选。
- 安全启动链从BootROM开始，一步都不能断。