vSGX：在AMD SEV处理器上虚拟化SGX

本文介绍俄亥俄州立大学SecLab和南方科技大学Teecert Labs合作在IEEE S&P 2022上发表的文章：“vSGX: Virtualizing SGX Enclaves on AMD SEV”[1]。

作者

赵士轩*、李梦源*、张殷乾教授^、林志强教授*

*俄亥俄州立大学SecLab
^

背景与动机

TEE（可信执行环境）有许多种类，例如Intel SGX一类的基于enclave（隔区）的TEE和AMD SEV一类的基于加密虚拟机的TEE。对于enclave模型而言，在现在计算领域最为通用的x86平台上，Intel SGX几乎是enclave的黄金标准。Enclave模型有很多好处，例如攻击面小、调用简便等，因此自从在第6代Core处理器中第一次亮相，Intel SGX就获得了很多关注并且也拥有了丰富的生态环境。SGX通过只允许操作系统管理而不允许操作系统读取/篡改enclave的方式保护了enclave的安全。然而作者发现对于Intel SGX而言存在一个巨大的问题：制造商捆绑。使用SGX的应用，必须部署在支持Intel SGX的处理器上。这导致了用户只能接受Intel提供的有限选项。例如在2021年第三季度之前，Intel不在云计算环境使用的Xeon服务器处理器产品线上提供SGX。又例如Intel现在决定在12代Core处理器和其他桌面处理器里取消SGX。而且显而易见用户没有办法在AMD的处理器上运行SGX应用。

除此之外，作者观察到现在云计算平台大多在尝试从硬件上解耦TEE。例如Google Asylo SDK希望通过提供统一的SDK来兼容不同的TEE；又例如Amazon Nitro Enclave希望通过虚拟化的形式来提供一个隔离的运行环境。同时，目前已有尝试实现软件定义的TEE，例如Komodo。因为是靠软件实现的TEE，整体的更新都更加灵活。而Intel SGX是靠微码提供的，对于硬件的绑定较强，无法快速迭代和修复bug。例如支持SGX1的处理器没有可能通过更新来获得SGX2的功能。

相较SGX而言，AMD SEV通过直接提供一个加密的虚拟机的方式来提供安全保证。这种方式可以避免其他虚拟机/宿主机的攻击，但不太容易做到像SGX一样的精巧严格的防护。与Intel不同的是，AMD SEV在所有的EPYC处理器上都提供，这也意味着对于云平台而言，开启SEV并不需要特殊选择。

纵观整体，作者发现SGX提供了很好的安全，并且拥有着丰富的生态环境，但是它面临着制造商捆绑、不合业内趋势且更新不够灵活的问题。AMD SEV提供了很好的云上虚拟机保护，但是不如SGX的保护精密。而业内和工业界对于通过使用软件来实现TEE的功能和硬件兼容性的尝试都无法直接运行现有SGX应用。于是作者希望通过软件的方式在AMD SEV平台上实现SGX的功能和安全性并且在提供对现有应用的二进制兼容的同时保留SEV的安全性。作者称这个系统为vSGX，并希望vSGX用起来像一个SGX硬件模块一样即插即用。

vSGX的架构与设计

在vSGX中，作者将每个SGX的enclave单独放置于一个小型的受SEV保护的VM中，作者称这些VM为EVM（即Enclave VM）。这些EVM内拥有一个小型的操作系统内核，功能仅限于提供基本的内存管理和线程管理以及提供vSGX的服务，除此之外的功能均被裁剪。而对于原本的应用运行的VM（AVM，即App VM），作者允许用户自行安装操作系统和环境，只需要安装所提供的vSGX内核模块即可。一旦安装之后，AVM就好像拥有SGX硬件一样可以直接调用SGX的指令。vSGX的架构如图

vSGX必须能够模拟SGX的指令，管理好内存并且负责好VM之间的通信。

指令模拟：在AMD SEV机器上，显然处理器不支持SGX指令。作者通过截获invalid opcode的handler来获得当前指令并且对其按照手册上规定的语义进行模拟。对于在AVM中的截获的指令，因为SGX的指令均要求操作敏感的处理器内部数据结构，作者将指令的参数打包发送给对应的EVM进行模拟。而EVM模拟后则把结果发送回AVM。对于EVM内的模拟则可直接本地执行。
内存管理：在SGX中，enclave和应用本身都放在进程的用户地址空间内，只是enclave可以访问应用的内存而应用不可以访问enclave的内存。在作者的设计中，作者的内存管理模块维护着从EPC（Enclave Page Cache，也即SGX中的enclave物理内存）到虚拟内存的映射。但由于在EVM内enclave的实际物理内存是系统分配的，因此EPC地址仅用作访问管理数据结构的index。而对于enclave访问应用内存的情况，作者实现了一个fetch-and-map的机制，从AVM来获取对应的内存并映射到EVM中。同时作者还设计了一个同步机制（switchless-syncing）来定时同步两个VM的内存。
跨VM通讯：尽管EVM和AVM之间的通讯可以由任何安全的加密信道来进行，但是考虑到性能开销，作者设计了一套基于加密内存的通信机制。这套机制依靠定制的CPUID leaf来退出到宿主机内，并借由宿主机内的vSGX hub依靠硬件中断传送到对应的目标虚拟机内。离开前要传送的数据会被加密，并且通过唯一的会话ID和CMAC来确保完整性并且防止重放攻击。到达目标机的数据会被解密并校验完整性，同时检查会话ID。通过检查后，数据会被送至分发器来派发给对应的处理函数。对应的处理函数会做好合法性校验。而如果数据没有通过校验或者数据没有对应的处理函数则会被直接丢弃。其流程如图。
控制流：尽管SGX中进入和退出enclave是靠SGX指令实现的，但这些指令在vSGX中需要额外处理。控制流的处理流程如下图。例如当AVM执行EENTER时，作者通过让AVM一侧休眠来转移控制流。在EVM收到EENTER请求后，EVM会创建一个新的线程来执行。而当执行完毕后，线程会结束，并且会返回到AVM。在AVM内，相应的休眠线程会被唤醒来继续执行。类似地，作者对SGX中处理异常的AEX流程也采取了相同的方式实现。
远程证明：SGX中的远程证明（remote attestation）是由软件配合硬件内生成报告的指令实现的。在vSGX中，通过完整实现EREPORT和EGETKEY指令兼容了SGX的远程证明流程。原本嵌入处理器内部的秘密（一个128-bit的整数）现在嵌入在EVM内核中。而EVM的安全性则是通过AMD SEV的远程证明流程实现的。SEV允许一个远程用户部署一个加密的VM镜像并验证处理器和固件的身份，这意味着EVM中的秘密可以在远程嵌入好然后部署。而当EVM被正确部署后，其内部的秘密也是可信的，因此可以使用SGX的流程向用户提供服务。

安全性

vSGX的安全性是由SEV的加密、SGX的语义和作者的系统设计共同实现的。

执行安全：作者的指令均按照SGX的语义实现，这意味着每条指令都有完整的安全合规性检查。同时作者将所有的指令都交付给EVM执行，确保执行的完整性和敏感数据结构的安全性。
对于一个enclave而言，vSGX的EVM内不对enclave提供任何系统服务，因此和SGX一样只能进行纯计算和调用SGX指令。而对于控制流，vSGX的enclave执行均完整发生在EVM内，因此AVM和宿主机均无法干涉。
内存安全：EVM由SEV的加密保护，因此宿主机无法访问其中的内容。而SGX的内存安全和规则则由EVM中的内核实现，它负责确保EPCM中的访问规则均被正确执行到页表中。对于enclave访问外部内存，vSGX通过fetch-and-map机制来获取内存并且通过switchless syncing来定时同步。这一机制严格限制同步的内存地址必须完整在EPC外，从而不会泄露EPC内的enclave内存。
跨VM通信：对于EVM而言，其实唯一的直接攻击面就在跨VM通信上。作者的跨VM通信通过加密和CMAC保证数据的完整和机密。数据内部有会话ID可以避免重放攻击和以及通过CMAC反向猜测数据是否发生变化。同时因为作者确数据分发后的处理函数都能够正确处理数据且未通过校验的数据均被抛弃，因此可以确保通信的安全性。