📚 课程目录第1章课程导入

1. 课程导入

在移动终端、车机、支付终端与边缘计算设备中，越来越多的敏感操作——指纹比对、密钥运算、DRM解密、安全支付——需要在与普通操作系统隔离的环境中完成。OP-TEE（Open Portable Trusted Execution Environment）正是这一需求的工业级开源答案：它运行在ARM TrustZone的安全世界（Secure World）中，与运行于普通世界（Normal World）的Linux/Android形成硬件级隔离，为可信应用（TA）提供受保护的执行空间。

本课程的目标不是让你背下API，而是建立一套可落地的工程能力：能读懂OP-TEE的启动链路，能编写并签名一个TA，能通过CA调用TA完成一次安全运算，能定位TA加载失败、会话异常、共享内存越界等典型问题，并理解其背后的安全模型。

学习目标可归纳为四条主线：

理解TrustZone与TEE的安全边界，掌握OP-TEE在系统中的位置与职责；

掌握OP-TEE的构建体系（optee_os、optee_client、optee_test、build）与交叉编译流程；

能独立开发一个TA+CA的最小闭环，并完成签名、部署与运行；

具备调试与排障能力，能读懂串口日志、TA panic信息与xtest结果。

核心概念：先建立“世界”与“边界”的直觉

OP-TEE的所有工程问题，最终都可以还原为几个核心概念之间的关系。理解它们，比记住命令更重要。

Secure World / Normal World：由ARM TrustZone的SCR.NS位与安全内存控制器划分。Normal World运行Rich OS（Linux/Android），Secure World运行OP-TEE OS。
TA（Trusted Application）：运行在安全世界的可信应用，通常以UUID标识，代码与数据受TEE保护。
CA（Client Application）：运行在普通世界的客户端应用，通过TEE Client API与TA通信。
SMC（Secure Monitor Call）：两个世界之间的唯一合法入口，由ARM Trusted Firmware或OP-TEE的monitor处理。
共享内存（Shared Memory）：CA与TA交换数据的受控缓冲区，必须显式注册与释放。
会话（Session）：CA与TA之间的逻辑通道，承载命令调用与上下文。

下图给出OP-TEE在系统中的整体架构与调用路径，建议先建立这张“地图”，后续章节再逐层深入。

整体知识框架：从构建到调试的五层结构

OP-TEE工程能力可以拆成五层，建议按顺序推进，不要跳层。

层级	核心内容	关键产出
环境层	交叉编译工具链、QEMU/开发板、ATF、U-Boot、Linux内核	可启动的OP-TEE运行环境
构建层	optee_os、optee_client、optee_test、build仓库与make参数	编译出tee.bin、libteec、xtest
开发层	TA/CA代码结构、UUID、命令ID、共享内存、会话	可运行的hello_world TA
安全层	签名、TA加载校验、安全存储、加密API	签名后的TA镜像与安全数据
调试层	串口日志、xtest、TA panic、GDB/OP-TEE trace	可定位问题的排障能力

实战路线图：一条最小闭环打通全链路

本课程后续章节会围绕一条主线展开：在QEMU或真实开发板上，从零构建OP-TEE，编写一个TA，通过CA调用它完成一次安全运算，并完成签名与部署。这条闭环一旦打通，后续所有复杂场景都是它的扩展。

# 典型构建入口（示意）
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
$ repo sync -j4
$ cd build
$ make toolchains
$ make run
# 运行后进入Normal World，执行：
$ xtest
$ optee_example_hello_world

建议先跑通官方xtest，再改hello_world。xtest覆盖了TA加载、会话、共享内存、加密、存储等大量用例，是验证环境是否正确的第一道关卡。

案例场景：一次“TA加载失败”的复盘

初学者最常见的问题是：CA调用TA时返回TEEC_ERROR_ITEM_NOT_FOUND或TEEC_ERROR_GENERIC。表面看是“TA没找到”，实际原因往往分布在三个位置：

TA镜像未部署到正确路径：OP-TEE默认从/lib/optee_armtz/加载TA，UUID文件名必须与TA代码中的UUID一致。
签名不匹配：TA镜像需要签名，若签名密钥与OP-TEE OS中配置的公钥不一致，加载会被拒绝。
tee-supplicant未运行：TA加载依赖RPC到Normal World读取文件，supplicant未启动会导致加载超时。

排障时不要只盯着CA代码。先看串口日志中OP-TEE OS的输出，再确认supplicant状态，最后核对TA路径与UUID。顺序错了，会在错误的方向上浪费大量时间。

这条案例说明：OP-TEE开发不是“写一个函数”那么简单，它横跨两个世界、多个组件和一条RPC链路。本课程的价值，正是把这条链路拆开、讲透、再让你亲手接回去。

接下来，我们将从TrustZone与TEE的安全边界开始，逐步进入OP-TEE的构建、开发、签名与调试。你需要的不是记忆，而是建立一张清晰的系统地图，并在每个节点上具备可验证的工程手段。