前言
在前面的文章中，我们深入分析了OP-TEE的安全世界侧（Secure World）的启动流程和TA运行机制。但一个关键问题是：REE侧（Rich Execution Environment，即Linux）是如何与安全世界通信的？答案就在OP-TEE Linux驱动中。
OP-TEE驱动是连接用户空间应用与安全世界TA之间的桥梁。当用户空间调用TEEC_OpenSession()打开一个TA会话时，这个请求会通过驱动层的ioctl接口进入内核态，最终通过SMC（Secure Monitor Call）指令陷入安全世界。本文将从编译加载、ioctl调用链、数据结构、共享内存管理到完整的SMC调用路径，层层剖析这个关键的驱动模块。
一、驱动模块的编译与加载
1.1 Kconfig配置体系
OP-TEE驱动的编译由两层Kconfig控制：
通用TEE框架层（drivers/tee/Kconfig）：
config TEE tristate "TEE Support" depends on HAVE_ARM_SMCCC || COMPILE_TEST || CPU_SUP_AMD select CRYPTO select CRYPTO_SHA1 select DMA_SHARED_BUFFER select GENERIC_ALLOCATOR |
OP-TEE驱动层（drivers/tee/optee/Kconfig）：
config OPTEE tristate "OP-TEE support" depends on HAVE_ARM_SMCCC && MMU help This implements an OP-TEE based Trusted Execution Environment (TEE) driver. |
注意OPTEE依赖HAVE_ARM_SMCCC，这是因为它必须通过ARM的SMC指令与安全世界通信。
1.2 Makefile编译结构
驱动采用分层编译的组织方式。TEE通用框架层将tee_core.o、tee_shm.o和tee_shm_pool.o编译为一个模块tee.ko。OP-TEE驱动层则将core.o、call.o、notif.o、rpc.o、supp.o、device.o、smc_abi.o和ffa_abi.o编译为optee.ko模块。
1.3 模块加载流程
驱动的初始化采用分层设计：
第一阶段：TEE框架初始化（tee_core.c）使用subsys_initcall级别，在内核启动早期执行，注册tee字符设备类并创建总线类型tee_bus_type。
第二阶段：OP-TEE模块初始化（core.c:177-206）通过module_init注册，依次尝试注册SMC ABI和FFA ABI两种通信方式：
c static int __init optee_core_init(void) { if (is_kdump_kernel()) return -ENODEV; rc = optee_smc_abi_register();// 尝试SMC方式 if (rc) pr_warn("SMC ABI not registered\n"); rc = optee_ffa_abi_register();// 尝试FFA方式 if (rc) pr_warn("FFA ABI not registered\n"); return 0; } |
第三阶段：平台设备探测（smc_abi.c:1331-1491），这是驱动初始化的核心。当设备树中存在compatible = "linaro,optee-tz"节点时，内核调用optee_probe()完成探测。这个函数执行了一系列关键操作：
1确定调用方式：通过设备树的method属性选择SMC或HVC指令
1验证API兼容性：检查OP-TEE的API UID和版本号
1交换能力信息：与安全世界交换sec_caps（如是否支持动态共享内存）
1配置共享内存池：优先使用动态共享内存，否则回退到静态内存
1创建两个设备：optee-clnt（客户端设备）和optee-supp（Supplicant设备）
1初始化通知机制：支持中断方式的异步通知
c // smc_abi.c:1380-1410 optee = kzalloc(sizeof(*optee), GFP_KERNEL); optee->ops = &optee_ops; optee->smc.invoke_fn = invoke_fn;// SMC/HVC调用函数 // 创建客户端设备 teedev = tee_device_alloc(&optee_clnt_desc, NULL, pool, optee); optee->teedev = teedev; // 创建Supplicant设备 teedev = tee_device_alloc(&optee_supp_desc, NULL, pool, optee); optee->supp_teedev = teedev; // 注册设备（创建/dev/tee0和/dev/tepriv0） tee_device_register(optee->teedev); tee_device_register(optee->supp_teedev); |
这里创建的两个设备分别对应不同的用途：/dev/tee0供普通应用使用，/dev/tepriv0供Supplicant守护进程使用。
二、REE侧用户空间对驱动的调用过程
2.1 ioctl入口
驱动通过file_operations结构体注册了ioctl入口函数：
c // tee_core.c:850-856 static const struct file_operations tee_fops = { .owner = THIS_MODULE, .open = tee_open, .release = tee_release, .unlocked_ioctl = tee_ioctl, .compat_ioctl = compat_ptr_ioctl, }; |
tee_ioctl()函数通过一个switch-case分发所有ioctl命令：
ioctl命令 | 处理函数 | 用途 |
TEE_IOC_VERSION | tee_ioctl_version() | 查询TEE版本信息 |
TEE_IOC_SHM_ALLOC | tee_ioctl_shm_alloc() | 分配共享内存 |
TEE_IOC_SHM_REGISTER | tee_ioctl_shm_register() | 注册用户空间共享内存 |
TEE_IOC_OPEN_SESSION | tee_ioctl_open_session() | 打开TA会话 |
TEE_IOC_INVOKE | tee_ioctl_invoke() | 调用TA命令 |
TEE_IOC_CANCEL | tee_ioctl_cancel() | 取消正在进行的请求 |
TEE_IOC_CLOSE_SESSION | tee_ioctl_close_session() | 关闭TA会话 |
TEE_IOC_SUPPL_RECV | tee_ioctl_supp_recv() | Supplicant接收请求 |
TEE_IOC_SUPPL_SEND | tee_ioctl_supp_send() | Supplicant发送响应 |
2.2 Open Session的完整流程
以TEE_IOC_OPEN_SESSION为例，我们可以看到驱动如何处理用户空间请求：
c // tee_core.c:467-544 static int tee_ioctl_open_session(struct tee_context *ctx, struct tee_ioctl_buf_data __user *ubuf) { // 1. 从用户空间拷贝缓冲区数据 copy_from_user(&buf, ubuf, sizeof(buf)); uarg = u64_to_user_ptr(buf.buf_ptr); copy_from_user(&arg, uarg, sizeof(arg)); // 2. 转换参数：将用户空间的SHM ID解析为内核tee_shm指针 rc = params_from_user(ctx, params, arg.num_params, uparams); // 3. 调用OP-TEE驱动的具体实现 rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params); // 4. 将结果写回用户空间 put_user(arg.session, &uarg->session); put_user(arg.ret, &uarg->ret); put_user(arg.ret_origin, &uarg->ret_origin); params_to_user(uparams, arg.num_params, params); } |
这里的关键是第3步：ctx->teedev->desc->ops->open_session()。这个虚函数表（vtable）使得TEE框架层与OP-TEE具体实现解耦。对于OP-TEE，这个函数指向optee_open_session()（call.c:140）。
2.3 Invoke Command的调用路径
TEE_IOC_INVOKE的处理类似，最终调用optee_invoke_func()（call.c:257）：
c // call.c:140-218 int optee_open_session(struct tee_context *ctx, ...) { // 分配共享内存用于传递optee_msg_arg shm = optee_get_msg_arg(ctx, arg->num_params + 2, &msg_arg); // 填充消息头 msg_arg->cmd = OPTEE_MSG_CMD_OPEN_SESSION; // 转换参数格式（从tee_param到optee_msg_param） optee->ops->to_msg_param(optee, msg_arg->params + 2, ...); // 进入安全世界！ if (optee->ops->do_call_with_arg(ctx, shm)) { msg_arg->ret = TEEC_ERROR_COMMUNICATION; } // 转换返回参数 optee->ops->from_msg_param(optee, param, ...); } |
三、驱动中重要的结构体变量
3.1 驱动操作表（vtable）
驱动层定义了两套操作表，分别用于客户端和Supplicant：
c // smc_abi.c:1014-1053 static const struct tee_driver_ops optee_clnt_ops = { .get_version = optee_get_version, .open = optee_smc_open, .release = optee_release, .open_session = optee_open_session, .close_session = optee_close_session, .invoke_func = optee_invoke_func, .cancel_req = optee_cancel_req, .shm_register = optee_shm_register, .shm_unregister = optee_shm_unregister, }; static const struct tee_driver_ops optee_supp_ops = { .get_version = optee_get_version, .open = optee_smc_open, .release = optee_release_supp, .supp_recv = optee_supp_recv, .supp_send = optee_supp_send, .shm_register = optee_shm_register_supp, .shm_unregister = optee_shm_unregister_supp, }; |
3.2 核心数据结构
struct optee（optee_private.h:151-168）是驱动的主结构体，持有所有关键资源：
c struct optee { struct tee_device *supp_teedev;// Supplicant设备 struct tee_device *teedev;// 客户端设备 const struct optee_ops *ops;// 内部操作（SMC/FFA抽象） struct tee_context *ctx;// 驱动内部TEE上下文 union { struct optee_smc smc;// SMC ABI特有数据 struct optee_ffa ffa;// FFA ABI特有数据 }; struct optee_call_queue call_queue; // 线程等待队列 struct optee_notif notif;// 通知机制 struct optee_supp supp;// Supplicant同步结构 struct tee_shm_pool *pool;// 共享内存池 }; |
其中optee_smc子结构体持有SMC调用函数指针：
c struct optee_smc { optee_invoke_fn *invoke_fn;// arm_smccc_smc 或 arm_smccc_hvc void *memremaped_shm;// 静态共享内存映射地址 u32 sec_caps;// 安全世界能力标志 unsigned int notif_irq;// 异步通知中断号 }; |
struct optee_ops（optee_private.h:122-131）抽象了进入安全世界的不同方式：
c struct optee_ops { int (*do_call_with_arg)(struct tee_context *ctx, struct tee_shm *shm_arg); int (*to_msg_param)(struct optee *optee, struct optee_msg_param *msg_params, size_t num_params, const struct tee_param *params); int (*from_msg_param)(struct optee *optee, struct tee_param *params, size_t num_params, const struct optee_msg_param *msg_params); }; |
struct optee_msg_arg（optee_msg.h:208-220）是传递给安全世界的消息格式，通过物理地址传入SMC寄存器：
c struct optee_msg_arg { u32 cmd;// OPTEE_MSG_CMD_* u32 func;// TA函数ID u32 session;// 会话ID u32 cancel_id; u32 ret;// 返回值 u32 ret_origin;// 返回来源 u32 num_params; struct optee_msg_param params[];// 柔性数组 }; |
struct optee_supp（optee_private.h:76-85）管理Supplicant的请求队列：
c struct optee_supp { struct mutex mutex; struct tee_context *ctx; int req_id; struct list_head reqs;// 待处理请求队列 struct idr idr;// 请求ID管理 struct completion reqs_c;// 请求到达通知 }; |
四、共享内存的注册和分配机制
共享内存是REE与安全世界交换数据的核心机制。OP-TEE驱动支持两种方式：动态共享内存（Dynamic SHM）和静态共享内存（Static SHM）。
4.1 共享内存分配（TEE_IOC_SHM_ALLOC）
当用户空间调用TEEC_AllocateSharedMemory()时，触发tee_ioctl_shm_alloc()：
c // tee_core.c:286-320 static int tee_ioctl_shm_alloc(struct tee_context *ctx, ...) { // 分配共享内存 rc = tee_shm_alloc(ctx, data.size, TEE_SHM_MAPPED | TEE_SHM_DMA_BUF); // 返回文件描述符给用户空间 fd = tee_shm_get_fd(shm); put_user(fd, &data->fd); } |
OP-TEE的动态池管理器实现（smc_abi.c:525-575）使用alloc_pages()分配物理页面，然后通过SMC注册到安全世界。
4.2 共享内存注册（TEE_IOC_SHM_REGISTER）
当用户空间调用TEEC_RegisterSharedMemory()时，驱动将用户空间的内存区域注册到安全世界：
c // smc_abi.c:424-474 static int optee_shm_register(struct tee_context *ctx, struct tee_shm *shm, struct page **pages, size_t num_pages, unsigned long start) { // 1. 检查内存类型（必须是普通内存） rc = optee_check_mem_type(start, num_pages); // 2. 构建非连续页表链表 optee_fill_pages_list(reg, pages, num_entries); // 3. 构建注册消息 msg_arg->cmd = OPTEE_MSG_CMD_REGISTER_SHM; msg_arg->params[0].attr = OPTEE_MSG_ATTR_NONCONTIG | OPTEE_MSG_ATTR_TYPE_RMEM_INPUT; msg_arg->params[0].u.rmem.shm_ref = (unsigned long)shm; // 4. 通过SMC进入安全世界完成注册 optee->ops->do_call_with_arg(ctx, shm_reg); } |
optee_fill_pages_list()函数将分散的物理页面组织成一个4KB页面地址的链表，每个链表节点本身也占用一个页面，形成一种"自举"的页表结构。
4.3 共享内存池管理
驱动在探测阶段根据安全世界的能力选择内存池策略：
c // smc_abi.c:1368-1378 // 优先使用动态共享内存 if (sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) pool = optee_config_dyn_shm(); // 否则回退到静态共享内存 if (IS_ERR(pool) && (sec_caps & OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM)) pool = optee_config_shm_memremap(invoke_fn, &memremaped_shm); |
动态共享内存池使用Linux的gen_pool分配器管理，分配的页面在使用时才注册到安全世界。静态共享内存池则使用设备树中预留的固定内存区域，无需动态注册，但容量有限。
五、libteec接口与tee_supplicant接口在驱动中的实现
5.1 libteec——用户空间TEE客户端库
libteec是GlobalPlatform TEE Client API的实现，位于optee_client/libteec/src/tee_client_api.c。
TEEC_InitializeContext初始化时遍历/dev/tee0到/dev/tee9，打开设备文件并通过TEE_IOC_VERSION查询能力：
c // 遍历设备节点，找到可用的OP-TEE设备 for (n = 0; n < TEE_NUM_DEVICES; n++) { snprintf(devname, sizeof(devname), "/dev/tee%zu", n); fd = open(devname, O_RDWR | O_CLOEXEC); // 发送TEE_IOC_VERSION查询 ioctl(fd, TEE_IOC_VERSION, &version_data); if (version_data.gen_caps & TEE_GEN_CAP_GP) // 找到GP兼容设备 } |
TEEC_OpenSession的完整调用流程：
c // tee_client_api.c:594-662 TEEC_Result TEEC_OpenSession(TEEC_Context *ctx, TEEC_Session *session, const TEEC_UUID *destination, ...) { // 1. 准备ioctl参数 arg->num_params = TEEC_CONFIG_PAYLOAD_REF_COUNT;// 4个参数 uuid_to_octets(arg->uuid, destination);// UUID转换 // 2. 预处理参数（处理共享内存） res = teec_pre_process_operation(ctx, operation, params, shm); // 3. 发起ioctl调用 rc = ioctl(ctx->fd, TEE_IOC_OPEN_SESSION, &buf_data); // 4. 后处理返回参数 teec_post_process_operation(operation, params, shm); // 5. 释放临时共享内存 teec_free_temp_refs(operation, shm); } |
共享内存管理分为三种情况：
1TEEC_RegisterSharedMemory()：将用户空间已分配的内存注册到TEE
1TEEC_AllocateSharedMemory()：由TEE库分配并注册内存
1TEEC_ReleaseSharedMemory()：释放共享内存
5.2 tee_supplicant——Supplicant守护进程
tee_supplicant是处理安全世界RPC（远程过程调用）请求的用户空间守护进程。
内核侧的RPC处理（supp.c）：
当安全世界需要REE侧服务（如加载TA二进制、访问文件系统等），会通过RPC机制回调到内核。内核的optee_handle_rpc()（smc_abi.c:760-808）根据RPC类型分发处理：
c // smc_abi.c:760-808 static void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param, ...) { switch (OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0)) { case OPTEE_SMC_RPC_FUNC_ALLOC: // 为RPC分配共享内存 break; case OPTEE_SMC_RPC_FUNC_FREE: // 释放RPC共享内存 break; case OPTEE_SMC_RPC_FUNC_CMD: // RPC命令 -> 可能需要Supplicant处理 handle_rpc_func_cmd(ctx, param, &call_ctx); break; } } |
Supplicant请求的传递（supp.c:76-150）：
c u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct tee_param *param) { // 1. 创建请求并加入队列 req = kzalloc(sizeof(*req), GFP_KERNEL); req->func = func; list_add_tail(&req->list, &supp->reqs); // 2. 通知Supplicant有新请求 complete(&supp->reqs_c); // 3. 等待Supplicant响应（阻塞） wait_for_completion(&req->c); // 4. 返回Supplicant的处理结果 return req->ret; } |
Supplicant守护进程（tee_supplicant.c）的主循环：
c while (true) { // 1. 从内核接收RPC请求 ioctl(fd, TEE_IOC_SUPPL_RECV, &recv); // 2. 根据请求类型分发处理 switch (recv.func) { case OPTEE_RPC_CMD_LOAD_TA: // 加载TA二进制文件 load_ta(recv.func, recv.num_params, recv.params); break; case OPTEE_RPC_CMD_RPMB: // 访问RPMB存储 break; case OPTEE_RPC_CMD_FS: // 文件系统操作 break; } // 3. 将结果发送回内核 ioctl(fd, TEE_IOC_SUPPL_SEND, &send); } |
这形成了一个完整的RPC闭环：安全世界 → 内核RPC处理 → Supplicant守护进程 → 内核 → 安全世界。
六、从TEEC_OpenSession到SMC的完整调用链
现在让我们追踪一个完整的TEEC_OpenSession调用，从用户空间到安全世界。
6.1 完整调用链图
6.2 SMC调用的寄存器编码
进入安全世界时，SMC寄存器的布局如下：
寄存器 | 值 | 说明 |
a0 | OPTEE_SMC_CALL_WITH_ARG | SMC函数ID |
a1 | msg_arg物理地址高32位 | 共享内存地址 |
a2 | msg_arg物理地址低32位 | 共享内存地址 |
a3-a7 | 0 | 保留 |
SMC函数ID由ARM SMCCC标准定义：
c // optee_smc.h:11-16 #define OPTEE_SMC_STD_CALL_VAL(func_num) \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_32, \ ARM_SMCCC_OWNER_TRUSTED_OS, (func_num)) |
6.3 调用队列与线程竞争管理
OP-TEE安全世界中的线程数量是有限的。当所有线程都忙时，安全世界会返回OPTEE_SMC_RETURN_ETHREAD_LIMIT。此时内核驱动通过一个等待队列机制处理竞争：
c // call.c:14-92 void optee_cq_wait_init(struct optee_call_queue *cq, struct optee_call_waiter *w) { mutex_lock(&cq->mutex); init_completion(&w->c); list_add_tail(&w->list_node, &cq->waiters);// 加入等待队列 mutex_unlock(&cq->mutex); } void optee_cq_wait_for_completion(struct optee_call_queue *cq, struct optee_call_waiter *w) { wait_for_completion(&w->c);// 睡眠等待 // 醒来后移到队尾，让其他等待者优先 } void optee_cq_wait_final(struct optee_call_queue *cq, struct optee_call_waiter *w) { mutex_lock(&cq->mutex); list_del(&w->list_node); optee_cq_complete_one(cq);// 唤醒下一个等待者 // 如果自己也被其他线程唤醒，继续唤醒下一个 if (completion_done(&w->c)) optee_cq_complete_one(cq); mutex_unlock(&cq->mutex); } |
这个设计确保了在高并发场景下，线程资源被公平分配，避免饥饿。
七、总结
OP-TEE Linux驱动是整个TEE生态系统的基石。通过本文的分析，我们可以看到：
1分层架构：TEE框架层提供通用接口，OP-TEE驱动提供具体实现，两者通过vtable解耦
1双设备模型：客户端设备（/dev/tee0）和Supplicant设备（/dev/tepriv0）各司其职
1共享内存：动态和静态两种策略，通过物理地址传递给安全世界
1RPC机制：安全世界可以回调REE侧的服务，形成双向通信
1SMC调用：通过ARM安全监控调用指令实现世界切换
理解了这些机制，就掌握了REE与安全世界对话的核心。在接下来的文章中，我们将继续深入分析其他关键组件。
10个月宝宝每天需要喝多少奶粉？
