OP-TEE(开放可移植可信执行环境)

OP-TEE驱动程序处理基于OP-TEE [1] 的TEE。目前,仅支持基于ARM TrustZone的OP-TEE解决方案。

与OP-TEE通信的最低层级建立在ARM SMC调用约定(SMCCC)[2]之上,这是OP-TEE的SMC接口[3]的基础,该接口由驱动程序在内部使用。在此之上堆叠的是OP-TEE消息协议[4]。

OP-TEE SMC接口提供SMCCC所需的基本功能以及OP-TEE特定的一些附加功能。最有趣的功能是

  • OPTEE_SMC_FUNCID_CALLS_UID(SMCCC的一部分)返回版本信息,然后由TEE_IOC_VERSION返回

  • OPTEE_SMC_CALL_GET_OS_UUID返回特定的OP-TEE实现,用于区分例如TrustZone OP-TEE和在单独的安全协处理器上运行的OP-TEE。

  • OPTEE_SMC_CALL_WITH_ARG驱动OP-TEE消息协议

  • OPTEE_SMC_GET_SHM_CONFIG让驱动程序和OP-TEE就Linux和OP-TEE之间共享内存使用的内存范围达成一致。

GlobalPlatform TEE客户端API [5] 在通用TEE API之上实现。

OP-TEE架构中不同组件之间关系图

   User space                  Kernel                   Secure world
   ~~~~~~~~~~                  ~~~~~~                   ~~~~~~~~~~~~
+--------+                                             +-------------+
| Client |                                             | Trusted     |
+--------+                                             | Application |
   /\                                                  +-------------+
   || +----------+                                           /\
   || |tee-      |                                           ||
   || |supplicant|                                           \/
   || +----------+                                     +-------------+
   \/      /\                                          | TEE Internal|
+-------+  ||                                          | API         |
+ TEE   |  ||            +--------+--------+           +-------------+
| Client|  ||            | TEE    | OP-TEE |           | OP-TEE      |
| API   |  \/            | subsys | driver |           | Trusted OS  |
+-------+----------------+----+-------+----+-----------+-------------+
|      Generic TEE API        |       |     OP-TEE MSG               |
|      IOCTL (TEE_IOC_*)      |       |     SMCCC (OPTEE_SMC_CALL_*) |
+-----------------------------+       +------------------------------+

RPC(远程过程调用)是安全世界对内核驱动程序或tee-supplicant的请求。RPC由来自OPTEE_SMC_CALL_WITH_ARG的特殊范围的SMCCC返回值标识。 打算发送给内核的RPC消息由内核驱动程序处理。 其他RPC消息将转发到tee-supplicant,而无需驱动程序的进一步参与,除了切换共享内存缓冲区表示形式。

OP-TEE设备枚举

OP-TEE提供了一个伪可信应用程序:drivers/tee/optee/device.c,以支持设备枚举。换句话说,OP-TEE驱动程序调用此应用程序来检索可以在TEE总线上注册为设备的受信任应用程序列表。

OP-TEE通知

安全世界可以使用两种通知来使正常世界意识到某些事件。

  1. 使用OPTEE_RPC_CMD_NOTIFICATIONOPTEE_RPC_NOTIFICATION_SEND参数传递同步通知。

  2. 异步通知通过非安全边沿触发中断和来自非安全中断处理程序的快速调用的组合来传递。

同步通知受到依赖RPC传递的限制,这仅在通过OPTEE_SMC_CALL_WITH_ARG使用屈服调用进入安全世界时才可用。 这将安全世界中断处理程序中的此类通知排除在外。

异步通知通过非安全边沿触发中断传递给OP-TEE驱动程序中注册的中断处理程序。 实际的通知值通过快速调用OPTEE_SMC_GET_ASYNC_NOTIF_VALUE检索。 请注意,一个中断可以代表多个通知。

一个通知值OPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF具有特殊含义。 当收到此值时,表示正常世界应该发出屈服调用OPTEE_MSG_CMD_DO_BOTTOM_HALF。 此调用是从协助中断处理程序的线程完成的。 这是安全世界中OP-TEE OS实现设备驱动程序上半部分和下半部分风格的构建块。

OPTEE_INSECURE_LOAD_IMAGE Kconfig选项

OPTEE_INSECURE_LOAD_IMAGE Kconfig 选项允许在内核启动后从内核加载BL32 OP-TEE映像,而不是在内核启动之前从固件加载。 这还需要在Arm的Trusted Firmware中启用相应的选项。 Arm的Trusted Firmware文档[6] 说明了启用此功能相关的安全威胁以及固件和平台级别的缓解措施。

使用此选项时,应解决内核的其他攻击向量/缓解措施。

  1. 引导链安全。

    • 攻击向量:替换rootfs中的OP-TEE OS映像以获得对系统的控制权。

    • 缓解措施:必须有验证内核和rootfs的引导链安全性,否则攻击者可以通过修改rootfs中的OP-TEE二进制文件来修改它。

  2. 备用启动模式。

    • 攻击向量:使用备用启动模式(即恢复模式),OP-TEE驱动程序未加载,使SMC漏洞敞开。

    • 缓解措施:如果有其他启动设备的方法(例如恢复模式),则应确保在该模式下应用相同的缓解措施。

  3. SMC调用之前的攻击。

    • 攻击向量:在发出SMC调用以加载OP-TEE之前执行的代码可能被利用来加载备用OS映像。

    • 缓解措施:必须在打开任何潜在的攻击向量之前加载OP-TEE驱动程序。 这应包括安装任何可修改的文件系统、打开网络端口或与外部设备(例如USB)进行通信。

  4. 阻止加载OP-TEE的SMC调用。

    • 攻击向量:阻止探测驱动程序,因此在需要时不会执行加载OP-TEE的SMC调用,从而使其可以在以后执行并加载修改后的OS。

    • 缓解措施:建议将OP-TEE驱动程序构建为内置驱动程序,而不是模块,以防止可能导致模块无法加载的漏洞。

参考资料

[1] https://github.com/OP-TEE/optee_os

[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html

[3] drivers/tee/optee/optee_smc.h

[4] drivers/tee/optee/optee_msg.h

[5] http://www.globalplatform.org/specificationsdevice.asp 查找

“TEE Client API Specification v1.0”,然后单击下载。

[6] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html