【机密计算顶会解读】09:vSGX——在AMD SEV处理器上虚拟化SGX
导读:本文介绍vSGX可信执行环境架构,通过软件的方式在AMD SEV平台上实现SGX的功能和安全性,并且在提供对现有应用的二进制兼容的同时保留SEV的安全性。
原文链接:vSGX: Virtualizing SGX Enclaves on AMD SEV | IEEE Conference Publication | IEEE Xplore
vSGX: Virtualizing SGX Enclaves on AMD SEV(IEEE Symposium on Security and Privacy 2022)
一、背景介绍
在云服务中,可信执行环境的使用保证了程序数据的机密性和完整性不受恶意的系统软件和运营商的影响,Intel、AMD则分别推出了Intel SGX、AMD SEV可信执行环境系统。其中,Intel SGX属于enclave类型的TEE,目前已经构建了一个丰富的生态系统,并发展成较为成熟的可信执行环境架构。然而,Intel SGX扩展指令集只有在特定的Intel SGX硬件支持下才能执行,开发人员需要根据Intel软件规范使用Intel SGX SDK构建应用程序。这导致了“制造商捆绑”问题的产生,即:为某个特定种类的环境开发的程序只能绑定在这个制造商的硬件上运行。
与此同时,许多云计算平台正在尝试从硬件上解耦可信执行环境,通过将可信执行环境软件与底层可信执行环境硬件分离使得开发完成的应用程序能够“一次构建,任意部署”。例如,Google Asylo SDK希望通过提供统一的SDK来兼容不同的TEE;Amazon Nitro Enclave希望通过虚拟化的形式来提供一个隔离的运行环境。此外,还有尝试实现软件定义的TEE,例如Komodo。
二、应对机制
AMD SEV通过直接提供一个加密虚拟机的方式来提供安全保证,这种方式可以避免其他虚拟机/宿主机的攻击,但不太容易做到像SGX一样的精巧严格的防护。并且,AMD SEV在所有的EPYC处理器上都提供,这也意味着对于云平台而言,开启SEV并不需要特殊选择。
因此一个可行的应对办法是:通过软件的方式在AMD SEV平台上实现SGX的功能和安全性,并且在提供对现有应用的二进制兼容的同时保留SEV的安全性。由此,vSGX系统被针对性地设计出来。vSGX是一种新的可信执行环境架构,它基于AMD SEV的硬件虚拟化和隔离来安全地执行Intel SGX程序,并且通过使用指令模拟,跨虚拟机内存同步以及基于AMD SEV的内存加密和隔离机制,为Intel SGX应用程序提供兼容的同时保证了应用程序的机密性和完整性。
三、vSGX 系统设计
在vSGX中,我们利用SEV提供的硬件虚拟机隔离来保证SGX中的enclave的内存隔离需求。我们将enclave运行在一个单独的虚拟机中,称之为EVM(Enclave Virtual Machine)。这些EVM内拥有一个小型的操作系统内核,功能仅限于提供基本的内存管理和线程管理以及提供vSGX的服务,除此之外的功能均被裁剪。而对于原本的应用运行的虚拟机,我们称之为AVM(App Virtual Machine)。在其中我们允许用户自行安装操作系统和环境,只需要安装我们提供的vSGX内核模块即可。一旦安装之后,AVM就好像拥有SGX硬件一样可以直接调用SGX的指令。
vSGX系统共包含5个模块:(1)指令模拟(2)内存管理(3)Enclave管理器(4)跨虚拟机通信(5)远程证明,其架构如图1。
图1. vSGX的架构
2.1 指令模拟
在AMD SEV机器上,显然处理器不支持SGX指令。我们通过截获invalid opcode的handler来获得当前指令并且对其按照手册上规定的语义进行模拟并修改相应的寄存器。Intel SGX中可用的enclave指令被分为两个指令助记符下的叶函数:ENCLS和ENCLU。每个叶函数使用EAX寄存器指定,并且通过其他可能需要的额外隐式输入寄存器作为参数。
对于在AVM中的截获的指令,因为SGX的指令均要求操作敏感的处理器内部数据结构,我们将指令的参数打包发送给对应的EVM进行模拟。而EVM模拟后则把结果发送回AVM。对于EVM内的模拟则可直接本地执行。
表1. vSGX的指令兼容情况
对于如EENTER、EEXIT等的控制流指令与AEX机制,我们设计了一套完整的控制流转移流程。详细流程见图2。应用程序可以使用EENTER指令进入EVM的enclave中进行隐私数据处理,该指令在AVM中被无效操作码处理程序#UD trap handler捕获(如图中步骤1),无效操作码处理程序准备需要传入EVM的参数并进入EVM中执行(步骤2)。此时,AVM中的应用程序线程将会暂停,等待EXIT指令的执行。当enclave处理完成时使用EEXIT指令退出,AVM中的无效操作码处理程序会捕获EEXIT指令(步骤➃)并恢复其中线程的执行(步骤7)。
EVM收到EENTER请求后(步骤3),将会创建一个线程或者选择一个已有的线程处理该请求(步骤4),请求处理完成后,EVM中的线程会调用EEXIT指令退出enclave(步骤5),EEXIT指令以AVM中类似的方式由无效操作码处理程序捕获并发送请求至AVM(步骤6),这时如果enclave线程已经不再需要,处理程序会结束该线程。AVM中的无效操作码处理程序会捕获EVM传入的EEXIT请求并且恢复AVM中应用程序的执行。
在vSGX中,EVM中的中断由可信的EVM内核执行,而故障处理由异步enclave退出程序AEX执行。在EVM中,如果enclave线程出现了故障(步骤1),故障处理程序将会调用异步enclave退出处理程序AEX handler(步骤2),并且将当前线程休眠。异步enclave退出处理程序会产生当前enclave寄存器的综合状态报告并发送给AVM(步骤3),AVM中的应用程序将会被唤醒并针对当前enclave寄存器的综合状态调用相应的异常处理程序处理该故障(步骤4)。在故障处理完成后,应用程序有可能会崩溃,或者故障被正确地处理。如果故障被正确地处理,系统会进入异步退出指针AEP(步骤5),该指针所指的程序使用ERESUME(步骤6)恢复EVM中enclave的执行(步骤9)。
图2. vSGX的控制流
2.2 内存管理
在vSGX中包含四种地址空间,分别是:EPC(Enclave Page Cache)地址空间、 虚拟地址空间、EVM物理地址空间、管理程序地址空间,其中管理程序地址空间与enclave执行无关,而其他地址空间由vSGX管理与使用。四种地址的关系如图3所示 。
图3. vSGX中的地址空间与其相互关系
在SGX中,enclave和应用本身都存在于进程的用户地址空间内,只是enclave可以访问应用的内存而应用不可以访问enclave的内存。在我们的设计中,我们的内存管理模块维护着从EPC(Enclave Page Cache,也即SGX中的enclave物理内存)到虚拟内存的映射。在AVM中,EPC地址用作物理地址。但在EVM内由于enclave的实际物理内存是系统分配的,因此EPC地址仅用作访问管理数据结构的index。
内存的隔离由AMD SEV提供。每个EVM只为一个enclave提供服务,因此任何当前enclave的代码与当前EVM的内部辅助程序以外的代码都将无法访问enclave内部的内容。在SEV中,每个虚拟机采用独立的密钥加密,因此也阻止了跨虚拟机的攻击。
而对于enclave访问应用内存的情况,我们实现了一个fetch-and-map的机制,从AVM来获取对应的内存并映射到EVM中。同时我们设计了一个同步机制switchless-syncing来定时同步两个VM的内存。其中enclave中的隐私代码以及数据段内存在两种机制下均拒绝访问以保证其安全性。
2.3 Enclave管理器
在Intel SGX中,enclave是作为用户空间的程序存在的,我们EVM中创建一个用于管理enclave的用户空间进程来提供一个用户控件的执行环境。Enclave管理程序将会在新的EVM启动之后进行创建并且为enclave的创建做好准备。Enclave管理程序将会为EVM中的enclave应用程序创建与自己隔离的地址空间和相应的线程,当一个enclave应用程序被正确设置并脱离enclave管理程序的管理后,我们才能切换到该enclave应用程序以确保安全性。
2.4 跨虚拟机通信
尽管EVM和AVM之间的通讯可以由任何安全的加密信道来进行,但是考虑到性能开销,我们设计了一套基于加密内存的通信机制。这套机制依靠定制的CPUID leaf来退出到宿主机内,并借由宿主机内的vSGX hub依靠硬件中断传送到对应的目标虚拟机内。离开前要传送的数据会被加密,并且我们通过唯一的会话ID和CMAC来确保完整性并且防止重放攻击。到达目标机的数据会被解密并校验完整性,同时检查会话ID。通过检查后,数据会被送至分发器来派发给对应的处理函数。对应的处理函数会做好合法性校验。而如果数据没有通过校验或者数据没有对应的处理函数则会被直接丢弃。其流程如图4。
vSGX加密了传输的数据,因此可以防止操作系统或超级管理员获取传输的信息。信息传输的接收方需要通过会话ID以及序列号将接受到的数据串联成原始数据以保证在数据包乱序、重发、并发的情况仍然保持数据的完整性与机密性。
图4. 跨虚拟机通讯的流程
2.5 远程证明
SGX中的远程证明(remote attestation)是由软件配合硬件内生成报告的指令实现的。在vSGX中,我们通过完整实现`EREPORT`和`EGETKEY`指令兼容了SGX的远程证明流程。原本嵌入处理器内部的秘密(一个128-bit的整数)现在嵌入在EVM内核中。而EVM的安全性则是通过AMD SEV的远程证明流程实现的。SEV允许一个远程用户部署一个加密的VM镜像并验证处理器和固件的身份,这意味着EVM中的秘密可以在远程嵌入好然后部署。而当EVM被正确部署后,其内部的秘密也是可信的,因此可以使用SGX的流程向用户提供服务。
四、 性能与兼容性
我们实现了vSGX并在一台真实的AMD SEV-ES的服务器上进行了实验。实验的服务器配置为AMD EPYC 7251,64 GiB内存。
3.1 兼容性
我们测试了多种SGX应用,包含使用Intel SGX SDK的应用以及不使用的,来证明vSGX的兼容性。我们测试过的程序有
- Graphene SGX (包含Nginx和其他demo)
- wolfSSL
- BYTEmark
- GMP Library for Intel SGX (and examples)
其中wolfSSL、GMP Library代表了典型的vSGX使用场景,其性能表现良好。而Graphene SGX作为一个LibOS,其复杂度非常之高表明了vSGX的兼容性良好,但其性能因为其实现的原因并不算非常高。我们也并不推荐在vSGX上使用Graphene SGX。
3.2 微观性能测试
在微观跑分中我们主要关注vSGX的每条指令以及各个组件的性能表现。我们测试了每条指令的执行时间,见表2。可见跨VM通讯的指令平均需要1ms,本地执行的指令仅需数us。
表2. vSGX各条指令的开销
我们还测试了enclave初始化、ECall性能、跨虚拟机通信、内存访问性能和内存同步性能。结果可参考图5。
图5. vSGX的微观流程性能
其中跨虚拟机通信的流程标号与图4一致。
3.3 宏观性能测试
对于宏观性能,我们分为计算跑分测试和应用测试。计算跑分我们选择了BYTEmark。我们对比了其与一个普通AMD SEV虚拟机的性能和与一台Intel Core i7机器上的SGX性能,其结果如图6。
图6. BYTEmark性能
可见如果不涉及到I/O(如大量ECall或者大量不可信空间内存访问),则性能几乎没有太大影响。但是I/O越多性能受影响越大。
对于应用测试,我们选用了Graphene-SGX与wolfSSL。Graphene SGX是一个LibOS,可以使任意Linux程序直接在其中执行。其初始化会一次性分配大量内存,其性能如图7。
图7. vSGX上的Graphene-SGX性能
对于Nginx这类高I/O需求的程序,其性能依然受影响较大。然而对于如GMP这类计算类工作,则几乎不受影响。启动时间大部分都浪费在了大量的EEXTEND指令上来计算measurement。优化方式可以包括积攒这些指令之后一次性执行。然而这样会与SGX语义产生偏差,其影响我们留做将来研究。
wolfSSL是一个可以用于SGX的SSL加密库。我们使用其自带的跑分工具进行测试并与之在Intel Core上的性能做对比,其结果如表3。
表3. vSGX上的wolfSSL的表现
结论:可见性能大部分情况下与SGX不相上下。其开销几何平均大概vSGX为Intel SGX的1.9倍。
本账号发布内容均为原创,欢迎转载,转载请注明出处。更多资讯请移步【机密计算前沿技术】服务号,欢迎交流!