本文将分享发表在 AsiaCCS ’24 上的论文《SoK: Understanding Designs Choices and Pitfalls of Trusted Execution Environments》，文章系统梳理了不同可信执行环境（TEE）设计上的选择和取舍，个人读完之后很有收获，推荐想做或正在做 TEE 设计相关工作的阅读。

TEE 设计核心挑战

文章提出了 TEE 设计过程中的核心挑战：TEE 设计如何保护 TEE 实例使用的资源，同时使不受信任的（宿主机）操作系统能够以有效的方式管理计算资源，以履行 CSP 的职责。

简而言之，就是如何平衡安全隔离和高效性能之间的关系。举个极端的例子，我们可以将虚拟机启动、vCPU 调度、内存分配、异常处理等不可信 hypervisor 的工作完全交给新引入的位于 TCB 中的可信实体（文中称之为 RTPM, TEE Runtime Protection Module）来完成，这样会导致一些问题：在 RTPM 中实现宿主 hypervisor 中复杂的调度策略是不现实的。首先，像 AMD SEV 它的 RTPM 为安全协处理器 PSP 及运行在其中的固件，PSP 只是一颗性能较为孱弱的 Arm 核心，其性能上难以胜任复杂策略；其次，即便是如 Intel TDX 这样基于安全模块的软件实体，也要面临复杂的策略导致的模块代码量的大幅增大，即 TCB 大小扩张带来的攻击面增大。而在 RTPM 中选择简单的策略又会导致性能的严重下降，为此不得不将部分虚拟机资源管理工作交由不可信的 hypervisor 来负责。

TEE 设计选择

在 TEE 提供保护的整个生命周期中，主要分为两个阶段：远程证明和运行时保护。

远程证明

大多数的 TEE 都遵循一套类似的远程证明流程，基本如下：

TEE 实体或是 TEE 实体的拥有者（加载 TEE 实体的实体）向一个可信对象发起远程证明请求，这个可信对象位于 TCB 范围内，包括安全协处理器（如 AMD PSP）和可信固件（TDX module）等。
可信对象生成并且签发一份可核实的认证报告，报告包含 TEE 实体的关键信息，如它的初始状态的安全度量值、平台细节、配置信息等。
TEE 实体的用户在将隐私数据传递到 TEE 前对报告进行验证，以确保 TEE 如预期那样正常初始化并提供保护。

可信启动与远程证明的细节一直是我不太熟悉的部分，之后计划对这部分内容进行梳理，并总结成博客。

运行时保护

TEE 资源管理模型

不同于远程证明，TEE 的运行时保护实现方式多种多样。文章建立了一套 TEE 资源管理模型，将其分为 4 类（如下图所示）：Unprotected mode、RTPM-only mode、RTPM-guarded mode、Instance-assited mode。

Unprotected mode 即 TEE 实体将资源管理的权限完全交给不可信 host 来完成（如几乎所有 CVM 将 vCPU 的调度完全交给不可信 host 来完成）；RTPM-only mode 即 RTPM 完全接管 TEE 实体的资源管理（如 SEV-ES 将虚拟机寄存器保留恢复完全由硬件来完成，且保留的寄存器状态 host 不可见）；RTPM-guarded mode 将 RTPM 作为一个间接层，资源直接由不可信 host 管理，但是需要经过 RTPM 的检查或是中转（如 AMD SEV-SNP 将虚拟机二阶页表的修改权限完全交给不可信 host，并借助 RMP 表保证虚拟机的内存完整性）；Instance-assited mode 将大部分资源交给不可信 host 来管理，但部分资源直接由 TEE 实体自身进行管理（如 Keystone 在 TEE 实体内部处理缺页异常）。

CPU 虚拟化设计选择

CPU 调度

正如前文所提到，绝大多数 TEE 的 CPU 调度基本都采用了 unprotected mode，因为这样能实现高效的资源管理并降低 TCB 的大小。因此，绝大多数 TEE 的威胁模型中都将 Availability 排除出去。

上下文切换

在 TEE 上下文切换过程中，其寄存器状态需要保存到内存中。在没有对这部分内存施加保护的情况下，不可信 host 可以直接对其进行篡改，从而随意改变 TEE 的运行状态，对 TEE 安全性造成极大损害，因此绝大多数 TEE 对此的选择都是 RTPM-only mode。

如 AMD SEV-ES 将原本虚拟机进入（VMRUN）和退出（#VMEXIT）只进行部分寄存器的保留恢复的过程更改为：原子性地对所有寄存器状态进行保留恢复，并保存到 hypervisor 无法访问的内存区域。而基于 RISC-V 架构的 TEE 中，由于有比不可信 host 运行特权级更高的 M-mode 存在，因此通常由运行在 M-mode 下的可信固件负责 TEE 的上下文切换。

中断和指令模拟

中断和指令模拟仅针对虚拟机级的 TEE。其中，AMD SEV 直接使用 unprotected mode，不对此进行保护。而 AMD SEV-ES/SEV-SNP 则通过引入 GHCB 和 #VC 异常引入了一定的 instance-assisted mode 设计（虚拟机内核中的 #VC 处理程序可以对 GHCB 中 host 的返回值进行简单的验证）。而 Intel TDX 和 IBM PEF 等则采用了 RTPM-guarded mode。

内存管理设计选择

虚拟内存管理

绝大多数 TEE 的虚拟管理都采用 instance-assisted mode，这应该很好理解，因为虚拟内存作为一种虚拟的资源，完全可以由 TEE 本身进行管理。具体的例子比如虚拟机内核对虚拟机的（一阶）页表进行管理。

物理内存分配（访问控制）

对于物理内存分配，绝大多数 TEE 都采用 RTPM-guarded mode。通常分为两步：

不可信 host 从内存中选择一些空闲页面分配给 TEE。
RTPM 进行额外的检查。

区别主要在于，检查的时机和方式不同。一些 TEE 选择在实际访存前进行权限检查，如 AMD SEV-SNP 通过引入 RMP-check，检查本次访存的实体是否有权访问该内存页面，从而实现 guest 和 host 之间、不同 guest 之间的内存隔离。而另一些 TEE 选择在创建页表项的阶段进行合法性检查，如 RISC-V Penglai。