今天要介绍的是一篇AsiaCCS 2024的录用论文 SoK: Understanding Designs Choices and Pitfalls of Trusted Execution Environments，作者对主流的商业和开源TEE实现进行了分析，总结了其中的设计缺陷：
这都已经2024年了，TEE也不是什么新鲜事物了，如果你到现在都完全没接触过，那么这篇论文的第二章是一个很不错的入门。特别是对TEE的威胁模型，以及在TEE中非常关键的概念——remote attestation（论文第三章也展开了进行详细介绍）一定需要理解清楚，这样文章后面的内容才能理解。
回到本文研究的主题上，这篇论文中的一个主要贡献来自于作者设计的TEE Runtime Architectural Framework，也就是TRAF工具。这个TRAF用来分析TEE的行为，也就是TEE运行过程中的一些主要的事件。下图展示了TEE和外围的host OS以及硬件资源进行交互的抽象示意图，这里面涉及到的事件主要包含了和内存、CPU以及硬件I/O打交道涉及的一些操作（论文里面还专门提到，要是对这些不熟悉，可以去读一下我们专栏推荐的那本“夫妻店”操作系统教科书——【G.O.S.S.I.P 阅读推荐 2023-08-28 操作系统的“三座大山”】）：
至于TRAF是怎么去审查TEE的行为呢？它首先通过将TEE分为四种类别来开展分析，具体的分类按照下图所示的原则。首先我们来简单解释一下这个图中的一些重点概念，图中的Privileged SW（特权代码，你可以简单把它认为是操作系统，当然并不是所有情况下都是，这里泛指所有有能力管理硬件资源的代码），而其中那个RTPM指的是TEE Runtime Protection Module，也就是一个相对来说比较独立且安全的模块（可能是硬件实现也可能是软件实现），作用是不受软件干扰（例如在OS被恶意篡改和控制的情况下）、能够可靠地直接访问外围资源。
具体到实际中，TEE会采取下列四种不同的模式来访问相关的运行时资源：
Unprotected mode：在这种模式中，TEE自己不去访问硬件资源，而是交给其他特权代码；
RTPM-only mode：这种模式里面，硬件资源的访问都要通过RTPM来进行；
RTPM-guarded mode：这种模式中，硬件资源访问由特权代码去操作，但是会被RTPM监管；
Instance-assisted mode：这种模式比较特殊，既不是RTPM也不是特权代码来访问硬件资源，而是由TEE去访问，注意此时也需要特权代码介入，因为此时TEE访问的资源（比如内存）并非直接访问（比如直接物理地址读写），而还是要有一些中间过渡（nested page table之类）。
可能我们会以为，不同的TEE实现会唯一地选择上述模式中的一种，其实并不是，现实中的TEE会混合使用上面的所有模式：对于不同的资源的使用和管理，选择不同的模式。下表是本文作者对当前主流的一些TEE实现的调研，对它们访问CPU、内存和外围硬件（I/O）所使用的模式进行的统计。
从上表中我们看到，绝大部分的TEE都采用了Unprotected mode来进行CPU调度，也就是让把这部分工作交给操作系统等特权代码来做，因为对CPU的使用时间的管理其实很麻烦，也没必要让RTPM来做。不过在涉及到上下文切换（context switch）时，有一些敏感的寄存器需要保护，那就得要RTPM介入了。后面我们会看到，正是因为AMD-SEV这个实现比较奇特的TEE没有保护好上下文切换（没使用RTPM-only mode），导致了相关的攻击。
在对于内存的使用和保护方面，由于TEE本身（不管是像Intel SGX这种进程级别的TEE，还是其他的以一个独立的OS/VM运行的TEE）对内存的使用还是基于虚拟地址访问，因此大家也就不约而同地使用了Instance-assisted mode；而各家的实现差异主要体现在物理内存分配和缺页处理这两方面。TEE一般会让操作系统去选择空闲的物理内存，然后让自己的RTPM检查访问权限（可能在页表初始化的时候检查，也可能是在实际访问的时候检查）；而对于缺页的处理，各家TEE在这里的差别是比较明显的，有一些TEE（例如AMD SEV-SNP和Intel SGX）采用了RTPM-guarded mode，也就是把页表更新交给特权代码，这留下了一定的安全风险；而另一些采用RTPM-only mode的TEE（例如IPADS实验室推出的蓬莱TEE）不允许除了RTPM之外的代码来更新页表；还有一些TEE干脆把这个事情在TEE内部解决了，也就是说TEE要去处理一些物理内存的事务，这个可能会增加代码的复杂度。
最后是关于外设I/O的资源管理，大部分的TEE选择了Unprotected mode，这里的设计哲学是压根不管数据传输信道的安全，通过软件设计来保证端到端的机密性和完整性。当然，这样会增加很多额外的运算开销，为此现在的硬件厂商也在想办法推行新的trusted I/O机制（嘿嘿又可以刷论文了）。
基于上面的这种视角，作者就可以对现有的TEE实现进行安全审查，看问题出在哪里。论文中主要抓住了AMD家的SEV系列TEE的问题（虽然SEV好像是个比较异类的TEE）。当然，作者也说了，本文对于侧信道攻击和利用预测执行进行的攻击不予考虑，这部分内容也有一些其他的文献去介绍了，作者在最后补了一个Table 2给大家参考。
论文：https://people.csail.mit.edu/mengyuanli/files/asiaccs_sok.pdf