第2章：TEE接口体系：TEE内部API、TEE客户端API与GP TEE标准

做TEE开发这些年，我最大的感受就是——接口这东西，看着是标准，用起来全是坑。今天咱们就来聊聊TEE的接口体系。说白了，就是搞清楚三件事：TEE内部怎么干活、普通应用怎么跟TEE打招呼、以及GP这个组织到底定了哪些规矩。

TEE内部API，也叫TEE Internal API。它是给安全应用（TA）用的。你想想看，TA跑在TEE里，它想访问密码学硬件、想读写安全存储、想生成随机数，总得有个入口吧？这个入口就是内部API。

我个人习惯把内部API分成几类：

密码学API：AES、RSA、SHA、HMAC这些。注意，TEE里一般不让你自己实现算法，而是调用硬件加速器。我在项目中遇到过，有人用软件实现了AES，结果性能惨不忍睹，后来换成硬件API，速度提升了20倍。
安全存储API：用来存密钥、证书、敏感数据。这些数据是加密后存在REE侧的文件系统里的，但只有TEE能解密。嗯，这里要注意：安全存储的密钥是硬件绑定的，换颗芯片就读不出来了。
时间与随机数API：TEE_GetTime、TEE_GenerateRandom。随机数必须是真随机数，不能是伪随机。我曾经踩过坑，用了一个伪随机数生成器做密钥，结果被安全审计直接打回。
通信API：TA之间通信、TA与REE通信的底层支持。

核心要点：内部API是TA的“操作系统接口”。你写TA，本质上就是在调这些API。性能优化的第一步，就是搞清楚哪些API是硬件加速的，哪些是软件模拟的。

客户端API，也叫TEE Client API。它是给REE侧的应用（CA）用的。CA想跟TEE里的TA说句话，就得通过客户端API。说白了，这就是一个跨世界的RPC机制。

客户端API的核心流程，我总结为四步：

你想想看，每次调用InvokeCommand，都要经过REE→Monitor→TEE的切换。这个切换开销可不小。我在项目中遇到过，有人在一个循环里频繁调用InvokeCommand，每次只传几个字节，结果性能直接崩了。后来改成批量传输，一次传一批数据，性能就上来了。

优化技巧：尽量减少跨世界调用的次数。能一次传完的数据，别分十次传。这是TEE性能优化的第一铁律。

GP TEE标准，全称是GlobalPlatform TEE Specification。它定义了上面说的内部API和客户端API的接口规范。为什么要定这个标准？说白了，就是为了让不同厂商的TEE实现能互相兼容。

GP TEE标准主要包含以下几个部分：

GP标准的好处是，你写的TA理论上可以在任何符合GP标准的TEE上跑。但现实是，各家厂商都有自己的扩展API。比如高通有QSEE扩展，Trustonic有Kinibi扩展。这些扩展往往性能更好，但会牺牲可移植性。

避坑指南：我曾经为了追求性能，大量使用了厂商私有API。结果换平台时，代码几乎重写。建议：核心逻辑用GP标准API，性能关键路径用厂商API，但要做好隔离。

下面这张图，是我自己画的TEE接口体系框架图。它展示了REE、TEE、TA、CA之间的关系，以及API的调用路径。

这张图你看懂了吗？CA通过Client API发起请求，经过Monitor（图中未画出）切换到TEE，TA通过Internal API完成实际工作。GP标准就像一本说明书，告诉两边该怎么写代码才能互相理解。

做了这么多年TEE，我总结了几条接口适配的经验：

先读标准，再看实现：GP标准文档虽然枯燥，但它是真理。厂商的实现可能有bug，标准不会。
性能瓶颈常在Client API：跨世界调用的开销远大于内部API调用。能用一次InvokeCommand搞定的事，别拆成三次。
注意内存管理：TEE里的内存很宝贵。Internal API分配的内存要记得释放，否则会内存泄漏。我曾经调试一个TA，跑了一周后崩溃，最后发现是内存泄漏。
厂商扩展是把双刃剑：用得好性能翻倍，用不好移植性全无。我的建议是：核心逻辑用GP标准，性能热点用厂商扩展，但要做好宏隔离。

小技巧：调试时可以用TEE_GetPropertyString获取TEE的版本和配置信息。不同厂商的TEE实现细节差异很大，这个API能帮你快速定位问题。

好了，关于TEE接口体系，今天就聊这么多。记住：内部API是TA的生存工具，客户端API是CA的敲门砖，GP标准是大家都要遵守的规矩。搞清楚了这三者的关系，你写TEE代码时就不会迷路了。