企业官网建设流程全解析

简介：OP-TEE_my_test 是一份面向嵌入式安全开发者的实践型资源包，聚焦 ARM 架构下可信执行环境 OP-TEE 中自定义 TA（可信应用）与 CA（客户端应用）的集成与测试。内容围绕 TA 与 CA 的源码组织、构建配置及在 QEMU 中的部署验证展开，适合已具备一定 C 语言与 Linux 构建基础、希望深入理解 Secure World 与 Normal World 通信机制的开发者。资源包共 19 个文件，约 15KB，包含 4 个 makefile、3 个 mk 与 3 个 Android.mk 等构建脚本，4 个 h 头文件、3 个 c 源文件，以及 3 个 msc 交互时序图、1 个 sh 脚本和 1 个 md 说明文档，覆盖 TA 与 CA 的编译、链接与调用流程。目前已有 2338 人学习下载。通过该资源，读者可获取一套可运行的 TA/CA 示例工程，理解 Makefile 与构建目录的修改方式，并借助 QEMU 快速验证集成结果，为嵌入式安全系统的开发与调试提供参考。

1. 从 OP-TEE_my_test 说起：一个可信执行环境的最小验证工程到底在测什么

很多人第一次看到 OP-TEE_my_test 这个名字，会以为它只是某个随手建的测试目录。但如果你正在做 ARM 平台的可信执行环境开发，或者需要在安全世界与普通世界之间划一条可信边界，这个命名背后其实对应着一类非常典型的工程需求：用最小的代码量，把 TA（Trusted Application）的加载、会话建立、命令分发、共享内存传递这条链路完整跑通，并且每一步都能看到返回值。它解决的不是“怎么写出一个生产级安全应用”，而是“怎么在半天内确认我的 OP-TEE 环境是活的、我的 TA 能被正常调用、我的参数传递没有踩到内存对齐的坑”。适合谁？适合刚拿到一块支持 Trusted Zone 的开发板、刷完固件却不知道从哪下手的嵌入式工程师，也适合已经在做 CA/TA 分离架构、但每次调试都要靠猜的中间件开发者。OP-TEE_my_test 的价值就在于：它把黑匣子拆成一条可观测的调用链，让你在改任何业务逻辑之前，先确认基础设施是可信的。

2. OP-TEE 的 CA/TA 双世界模型与最小验证工程该包含哪些文件

2.1 为什么 OP-TEE 要把代码切成两个世界

OP-TEE 的架构核心是 ARM TrustZone 提供的安全世界（Secure World）与普通世界（Normal World）隔离。普通世界跑的是 Linux 用户态程序，也就是 CA（Client Application）；安全世界跑的是 OP-TEE OS 和 TA（Trusted Application）。两者不能直接函数调用，必须通过 SMC 指令陷入安全监控模式，由 OP-TEE OS 转发请求。这个模型带来的直接后果是：你不能在 CA 里直接 malloc 一块内存传给 TA 用，也不能在 TA 里直接 printf 到串口。所有交互必须走会话（session）和命令（command）两个抽象。常见做法是 CA 先调用TEEC_InitializeContext打开 TEE 设备，再用TEEC_OpenSession建立到指定 UUID 的 TA 的会话，然后通过TEEC_InvokeCommand发命令，参数用TEEC_Param数组传递。TA 侧则实现TA_CreateEntryPoint、TA_OpenSessionEntryPoint、TA_InvokeCommandEntryPoint三个入口。OP-TEE_my_test 要验证的就是这条链路每一环的返回值是否如预期。

2.2 一个可复现的最小工程目录结构

我一般会把 OP-TEE_my_test 组织成下面这样，不依赖任何构建系统的高级特性，纯 Makefile 加几个源文件，方便逐行看编译产物：

OP-TEE_my_test/ ├── host/ │ ├── main.c │ └── Makefile ├── ta/ │ ├── my_test_ta.c │ ├── user_ta_header_defines.h │ ├── sub.mk │ └── Makefile └── shared/ └── my_test_ta.h

shared/my_test_ta.h里放 TA 的 UUID 和命令 ID，CA 和 TA 都包含它，保证两边对命令号的理解一致。UUID 不要用全零，也不要用示例里常见的固定值，自己生成一个版本 4 的 UUID 写进去。命令 ID 从 0 开始递增，但 0 通常被 OP-TEE 内部保留，所以我一般从 1 开始定义MY_TEST_CMD_HELLO、MY_TEST_CMD_ECHO、MY_TEST_CMD_SUM三个命令，分别验证无参数调用、内存块传递、多参数数值计算。

2.3 编译与加载：TA 是怎么被放进安全世界的

TA 编译出来是一个.ta文件，本质上是带签名头的 ELF。它不能直接放到文件系统里被 CA 打开，必须先经过签名并放到 OP-TEE 能识别的路径。常见做法是用 OP-TEE 提供的sign_encrypt.py脚本对 TA 签名，然后把签名后的.ta复制到开发板文件系统的/lib/optee_armtz/目录下。CA 运行时，OP-TEE 的 supplicant 会根据 UUID 去这个目录加载对应的 TA。如果你改了 TA 代码但忘记重新签名和复制，CA 会返回TEEC_ERROR_ITEM_NOT_FOUND，这个错误码我后面还会细说。下面是一个典型的 TA 编译命令片段：

# 在 ta/ 目录下，假设已设置 CROSS_COMPILE 和 TA_DEV_KIT_DIR make \ CROSS_COMPILE=aarch64-linux-gnu- \ TA_DEV_KIT_DIR=/path/to/optee_os/out/arm/export-ta_arm64 \ O=out # 编译产物在 out/ 下，文件名类似 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.ta

参数说明：CROSS_COMPILE指定交叉编译器前缀，必须和你的开发板架构一致；TA_DEV_KIT_DIR指向 OP-TEE OS 编译后导出的 TA 开发套件目录，里面包含头文件和链接脚本；O=out把中间文件放到独立目录，避免污染源码树。编译成功后用file命令确认产物是 ARM aarch64 或 arm 架构，不要拿 x86 的产物去板子上跑。

3. 用 TEEC_InvokeCommand 跑通第一条命令：从 CA 到 TA 的完整调用链

3.1 CA 侧初始化与打开会话的代码骨架

CA 侧代码不复杂，但顺序不能乱。必须先TEEC_InitializeContext，再TEEC_OpenSession，最后才是TEEC_InvokeCommand。任何一步失败都要用TEEC_ErrorOrigin判断错误来自普通世界还是安全世界。下面是我在 OP-TEE_my_test 里用的最小 CA 骨架：

#include <stdio.h> #include <string.h> #include <tee_client_api.h> #include "my_test_ta.h" int main(void) { TEEC_Context ctx; TEEC_Session sess; TEEC_Operation op; TEEC_Result res; uint32_t err_origin; // 1. 初始化上下文，打开 /dev/tee0 res = TEEC_InitializeContext(NULL, &ctx); if (res != TEEC_SUCCESS) { printf("init ctx failed: 0x%x\n", res); return -1; } // 2. 用 UUID 打开会话，触发 TA 加载 res = TEEC_OpenSession(&ctx, &sess, &my_test_ta_uuid, TEEC_LOGIN_PUBLIC, NULL, NULL, &err_origin); if (res != TEEC_SUCCESS) { printf("open session failed: 0x%x origin: 0x%x\n", res, err_origin); TEEC_FinalizeContext(&ctx); return -1; } // 3. 准备无参数命令 memset(&op, 0, sizeof(op)); op.paramTypes = TEEC_PARAM_TYPES(TEEC_NONE, TEEC_NONE, TEEC_NONE, TEEC_NONE); res = TEEC_InvokeCommand(&sess, MY_TEST_CMD_HELLO, &op, &err_origin); printf("hello cmd res: 0x%x origin: 0x%x\n", res, err_origin); TEEC_CloseSession(&sess); TEEC_FinalizeContext(&ctx); return 0; }

逻辑说明：TEEC_InitializeContext的第一个参数传 NULL 表示使用默认 TEE 设备；TEEC_LOGIN_PUBLIC表示不鉴权，适合调试阶段；err_origin会告诉你错误是来自 CA 侧（TEEC_ORIGIN_API）、TA 侧（TEEC_ORIGIN_TRUSTED_APP）还是内核驱动（TEEC_ORIGIN_COMMS）。参数说明：op.paramTypes用宏TEEC_PARAM_TYPES组合四个参数类型，这里全填TEEC_NONE，表示不传任何数据。如果你把TEEC_NONE写成TEEC_VALUE_INPUT却没填op.params[0].value，TA 侧读到的就是栈上的随机值，这种玄学问题我踩过不止一次。

3.2 TA 侧入口函数与命令分发

TA 侧代码要包含tee_internal_api.h，并实现三个入口。TA_InvokeCommandEntryPoint里用 switch 分发命令号，每个命令返回TEE_SUCCESS或具体错误码。下面是对应MY_TEST_CMD_HELLO的最小实现：

#include <tee_internal_api.h> #include <tee_internal_api_extensions.h> #include "my_test_ta.h" TEE_Result TA_CreateEntryPoint(void) { return TEE_SUCCESS; } void TA_DestroyEntryPoint(void) {} TEE_Result TA_OpenSessionEntryPoint(uint32_t param_types, TEE_Param params[4], void **sess_ctx) { (void)param_types; (void)params; (void)sess_ctx; return TEE_SUCCESS; } void TA_CloseSessionEntryPoint(void *sess_ctx) { (void)sess_ctx; } TEE_Result TA_InvokeCommandEntryPoint(void *sess_ctx, uint32_t cmd_id, uint32_t param_types, TEE_Param params[4]) { (void)sess_ctx; (void)param_types; (void)params; switch (cmd_id) { case MY_TEST_CMD_HELLO: IMSG("hello from TA\n"); return TEE_SUCCESS; default: return TEE_ERROR_BAD_PARAMETERS; } }

逻辑说明：IMSG是 TA 侧的日志宏，输出会进 OP-TEE 的 secure console，通常通过串口或xtest的日志通道看到。参数说明：param_types的高 16 位和低 16 位分别描述四个参数的类型，TA 侧必须校验它和预期一致，否则直接返回TEE_ERROR_BAD_PARAMETERS。我一般会在每个 case 开头加一句if (param_types != expected) return TEE_ERROR_BAD_PARAMETERS;，别小看这一行，它能挡掉后面很多内存越界的血泪经验。

3.3 共享内存传递：TEEC_MEMREF_TEMP_INPUT 的正确用法

无参数命令跑通后，下一步验证内存块传递。OP-TEE 提供TEEC_MEMREF_TEMP_INPUT、TEEC_MEMREF_TEMP_OUTPUT、TEEC_MEMREF_WHOLE等类型。临时内存引用最简单，CA 侧把缓冲区指针和长度填进op.params[0].tmpref，TA 侧用params[0].memref.buffer和params[0].memref.size访问。下面是一个 echo 命令的 CA 侧写法：

char send_buf[] = "optee_my_test"; char recv_buf[32] = {0}; memset(&op, 0, sizeof(op)); op.paramTypes = TEEC_PARAM_TYPES(TEEC_MEMREF_TEMP_INPUT, TEEC_MEMREF_TEMP_OUTPUT, TEEC_NONE, TEEC_NONE); op.params[0].tmpref.buffer = send_buf; op.params[0].tmpref.size = strlen(send_buf) + 1; op.params[1].tmpref.buffer = recv_buf; op.params[1].tmpref.size = sizeof(recv_buf); res = TEEC_InvokeCommand(&sess, MY_TEST_CMD_ECHO, &op, &err_origin); printf("echo res: 0x%x, recv: %s\n", res, recv_buf);

TA 侧对应实现：

case MY_TEST_CMD_ECHO: { if (param_types != TEEC_PARAM_TYPES(TEEC_MEMREF_TEMP_INPUT, TEEC_MEMREF_TEMP_OUTPUT, TEEC_NONE, TEEC_NONE)) return TEE_ERROR_BAD_PARAMETERS; void *in = params[0].memref.buffer; uint32_t in_len = params[0].memref.size; void *out = params[1].memref.buffer; uint32_t out_len = params[1].memref.size; if (in_len > out_len) return TEE_ERROR_SHORT_BUFFER; TEE_MemMove(out, in, in_len); params[1].memref.size = in_len; // 回写实际使用长度 return TEE_SUCCESS; }

逻辑说明：TA 侧必须检查输入长度是否超过输出缓冲区，否则TEE_MemMove会直接踩坏安全世界的内存。参数说明：params[1].memref.size在返回前要改成实际写入的字节数，CA 侧读这个字段才知道有效数据多长。注意TEEC_MEMREF_TEMP_*类型在 OP-TEE 内部会做一次拷贝，适合小数据量；大数据量应该用TEEC_MEMREF_PARTIAL_INPUT配合共享内存注册，减少拷贝开销。

4. 参数类型、内存对齐与返回值：OP-TEE_my_test 里最容易翻车的三个地方

4.1 TEEC_PARAM_TYPES 宏的位域陷阱

TEEC_PARAM_TYPES是一个把四个 4 位类型码拼成 16 位整数的宏。常见错误是直接写0x00000001这种魔法数字，结果 CA 和 TA 对参数类型的理解错位。正确做法是始终用宏组合，并且在 TA 侧用同样的宏做比较。下面这张表列出我常用的参数类型组合和对应含义：

如果你在 CA 侧写了TEEC_VALUE_INPUT，TA 侧却按TEEC_MEMREF_TEMP_INPUT去读params[0].memref.buffer，读到的其实是params[0].value.a的值被当成指针，大概率触发 data abort。这种错误不会在编译期报，只会在运行时给你一个TEEC_ERROR_TARGET_DEAD，然后 TA 被内核杀掉，日志里只有一行看不懂的 panic。

4.2 共享内存的 cache 一致性问题

ARM 平台上 CA 和 TA 可能运行在不同的 cache 域。如果你用TEEC_MEMREF_WHOLE注册了一块共享内存，CA 侧写完数据后没有做 cache flush，TA 侧读到的可能是旧值。OP-TEE 对TEEC_MEMREF_TEMP_*类型会在内部做拷贝和同步，所以小数据量下不容易出问题；但一旦换成TEEC_MEMREF_PARTIAL_*或TEEC_MEMREF_WHOLE，就必须自己保证一致性。我一般会在 CA 侧调用TEEC_InvokeCommand之前，对共享缓冲区做一次__builtin___clear_cache或者用msync类似的机制，具体取决于你的内核配置。更稳妥的做法是：调试阶段全部用TEEC_MEMREF_TEMP_*，等逻辑稳定后再换成共享内存注册，并且用xtest里的benchmark用例对比性能差异。

4.3 返回值不是只有 TEE_SUCCESS

OP-TEE 的返回值分两层：TEEC_Result是 CA 侧看到的，TEE_Result是 TA 侧返回的。TA 返回TEE_SUCCESS时 CA 看到TEEC_SUCCESS；TA 返回TEE_ERROR_BAD_PARAMETERS时 CA 看到TEEC_ERROR_BAD_PARAMETERS。但有些错误是 OP-TEE 内核驱动产生的，比如TEEC_ERROR_ITEM_NOT_FOUND表示 UUID 对应的 TA 没找到，TEEC_ERROR_COMMUNICATION表示 SMC 调用失败。下面这张表是我在 OP-TEE_my_test 里最常遇到的几个错误码和排查方向：

5. 避坑与排查：OP-TEE_my_test 跑不通时先看这五条

5.1 现象：CA 返回 0xffff0008，TA 日志完全看不到

原因：TEEC_ERROR_ITEM_NOT_FOUND，OP-TEE 的 supplicant 没有在/lib/optee_armtz/下找到对应 UUID 的.ta文件。常见触发场景是编译完 TA 后只复制了.ta但忘了签名，或者签名时用的 key 和板子上 OP-TEE OS 内置的公钥不匹配。解决：先用ls -l /lib/optee_armtz/确认文件名就是 UUID 加.ta后缀，再用optee_examples里自带的xtest跑一遍xtest 1001确认基础环境正常。如果xtest也报同样的错，说明 OP-TEE OS 的签名验证配置有问题，需要重新编译 OS 并关闭CFG_TA_SIGNATURE或者换成匹配的 key。

5.2 现象：TA 侧 IMSG 打印乱码或直接 panic

原因：TA 侧用了TEE_Malloc分配内存但没检查返回值，或者params[0].memref.buffer在param_types不匹配时被当成有效指针访问。解决：在 TA 的每个命令入口先校验param_types，再校验memref.size是否在合理范围（比如不超过 4096），最后才访问 buffer。我一般会写一个static TEE_Result check_param(uint32_t got, uint32_t expected)辅助函数，把校验逻辑收拢到一处，避免每个 case 里重复写还写漏。

5.3 现象：CA 侧 recv_buf 里只有一半数据，或者末尾有垃圾字符

原因：TA 侧TEE_MemMove拷贝后没有更新params[1].memref.size，CA 侧按原始sizeof(recv_buf)去读，把未初始化的栈数据也打印出来了。解决：TA 侧在拷贝完成后必须写params[1].memref.size = actual_len，CA 侧读取时用op.params[1].tmpref.size而不是自己记的缓冲区大小。这个坑在TEEC_MEMREF_TEMP_OUTPUT类型下尤其常见，因为临时内存引用在 CA 和 TA 之间会做一次拷贝，size 字段是唯一能传递实际长度的通道。

5.4 现象：改了 TA 代码重新编译，CA 行为没变化

原因：OP-TEE 的 supplicant 会缓存已加载的 TA，或者你复制.ta文件时目标路径不对。解决：先确认板子上的.ta文件时间戳是新的，然后重启板子或者用killall tee-supplicant再重新运行 CA。有些开发板的文件系统是只读的，复制操作看似成功实际写到了临时层，重启后就丢了。我一般会在复制后加一句md5sum对比宿主机和板子上的文件哈希，确认真的写进去了。

5.5 现象：TEEC_OpenSession返回TEEC_ERROR_COMMUNICATION

原因：OP-TEE 驱动没有正确加载，或者/dev/tee0权限不对。解决：用lsmod看optee和optee_armtz模块是否在列，用ls -l /dev/tee*看设备节点是否存在。如果设备节点存在但 CA 仍报通信错误，检查 CA 是否以 root 运行，或者当前用户是否在tee组里。这个错误在容器化环境里尤其常见，因为容器默认不暴露 TEE 设备节点，需要显式挂载/dev/tee0和/dev/teepriv0。

6. 把 OP-TEE_my_test 变成可复用的验证模板：三个进阶技巧

6.1 用 xtest 的回归用例反查自己的实现

OP-TEE 自带xtest工具，里面有一批针对 CA/TA 交互的回归用例。我习惯在写完 OP-TEE_my_test 后，先跑一遍xtest确认基础环境没问题，再把自己的 CA 和xtest的日志对比。具体做法是：在 CA 里把TEEC_InvokeCommand前后的err_origin都打印出来，然后和xtest里对应用例的输出格式对齐。如果xtest能过而你的 CA 过不了，问题一定在 CA 侧的参数构造或 TA 侧的 UUID 匹配上，不用怀疑 OP-TEE OS 本身。这个对比法帮我省过至少两天盲目重刷固件的时间。

6.2 给 TA 加一个版本号命令，避免新旧 TA 混淆

TA 加载后无法从外部直接看它的版本。我一般会在MY_TEST_CMD_HELLO之外再加一个MY_TEST_CMD_VERSION，返回一个 32 位整数，每次改 TA 代码就递增这个数。CA 侧启动时先调这个命令，把版本号打印出来。这样当你怀疑板子上跑的是旧 TA 时，看一眼版本号就知道要不要重新复制.ta文件。实现上很简单，TA 侧返回TEE_SUCCESS并把版本号写进params[0].value.a，CA 侧用TEEC_VALUE_OUTPUT接收。别小看这个习惯，它比md5sum更直接，因为版本号是编译进 TA 二进制里的，不会因为文件系统缓存而骗你。

6.3 用共享内存做一次 4KB 数据往返，验证性能边界

临时内存引用在数据量超过 1KB 后拷贝开销开始明显。我一般会在 OP-TEE_my_test 里加一个MY_TEST_CMD_BENCH命令，用TEEC_MEMREF_PARTIAL_INOUT注册一块 4KB 的共享内存，CA 侧填充递增字节，TA 侧做一次校验和计算并回写结果。CA 侧用clock_gettime记录TEEC_InvokeCommand前后的耗时，跑 1000 次取平均。这个数据能告诉你当前平台上一次跨世界调用的固定开销大概是多少微秒，以及 4KB 数据拷贝带来的额外开销占比。我实测过的经验值是：固定开销在几十微秒量级，4KB 拷贝会增加大约 10% 到 20% 的总耗时，具体取决于 cache 配置和 CPU 频率。有了这个基线，你后面做任何优化都能判断是不是真的有效。

6.4 一个我反复踩过的坑：别在 TA 里用标准 C 库

TA 运行在安全世界，没有完整的 libc。printf、malloc、memcpy这些函数要么不可用，要么行为和在普通世界不一样。OP-TEE 提供的是TEE_Malloc、TEE_MemMove、TEE_MemCompare这套内部 API。我早期图省事在 TA 里直接调memcpy，编译能过，运行到某些板子上就 data abort，换一块板子又正常，查了两天才发现是链接到了不兼容的 libc 实现。后来我养成习惯：TA 侧代码里出现任何以mem开头的函数，先确认它是TEE_前缀的版本。这个教训让我在后续所有 OP-TEE 项目里都先把 TA 的编译选项加上-nostdlib，强制自己只用 TEE 内部 API。希望帮到你。

本文还有配套的精品资源，点击获取