今天要分享的文章是发表于2022 IEEE S&P上的《vSGX: Virtualizing SGX Enclaves on AMD SEV》
近年来,由于对保护程序代码和隐私数据的需求,可信执行环境(TEE)的研究发展迅速,其中有着如Intel SGX这样较为成熟的工业界产品,Intel围绕SGX构建了一个丰富的生态系统。然而根据要求,使用SGX的应用程序中受信任的部分只能在特殊的CPU模式下执行,因此开发人员需要根据标准重建应用程序,使得为SGX开发的应用程序只能运行在SGX上。
对于云供应商来说,他们也试图使TEE的软件应用程序与底层硬件脱钩,如Google的Asylo项目、Amazon的Nitro Enclave。然而这些方案无法实现binary级别的兼容,也即直接按照SGX的语义在云服务器上部署项目,而且云服务器也可能没有SGX所需的硬件配置。此外,SGX的特点是位于用户空间的小型enclave,所有组件则暴露在不受信任的管理程序中,而AMD SEV则是保护整个虚拟机,因而允许灵活地部署现有的应用程序,但代价是受攻击面更大。
文章希望能将二者的优点结合,提出了vSGX,通过虚拟化实现了在AMD SEV上直接执行SGX应用程序的二进制代码。
vSGX的关键思想是利用SEV提供的虚拟机制,在一个独立的虚拟机中执行SGX应用程序可信部分(也即原来运行于SGX enclave中的部分),将该虚拟机称为enclave VM(EVM),而另一个用于运行不可信部分的虚拟机称为app VM (AVM)。vSGX由五个部分构成:①指令仿真;②Enclave管理;③内存管理;④跨虚拟机通信;⑤远程证明
-
1. binary级别的兼容性:能够直接运行未经修改的SGX应用程序binary;
-
2. 保留SGX能提供的enclave安全特性:实现与英特尔SGX相当的安全水平,enclave不受外部的任何组件影响,包括管理程序、操作系统和其他enclave;
-
3. 为应用程序保留SEV的安全性:不会受到来自恶意或被破坏的管理程序的攻击。
-
由于SGX具有一些SEV没有的特殊指令,因而需要捕获并仿真这些指令的执行。
捕获特殊指令的方法为修改了处理非法指令的handler,作者将所有能够支持的特殊指令分为两类Leaf Instruction:ENCLS、ENCLU,通过eax寄存器标记具体的指令。对于EVM中的特殊指令,根据其在SGX中的语义进行仿真执行;而对于在AVM中产生的特殊指令,会将其参数打包发送至EVM中执行,在EVM中执行成功后将需要更新的部分送回AVM。TABLE 1列出了vSGX中实现仿真的指令。
当一个EVM启动时,其中将创建一个管理器,在初始化时为enclave执行提供一个独立的地址空间,并创建两个线程分别用于内存管理与调度,当enclave初始化完成发出ENTER请求后,管理器创建一个新的线程用于enclave执行。每个EVM中的一个管理器对应一个enclave。
vSGX中包含四种地址,分别是:EPC(Enclave Page Cache)地址,虚拟地址、enclave物理地址、管理程序地址,其中管理程序地址由enclave内核管理,而其他地址空间由vSGX管理与使用,Fig. 3是四类地址之间的关系。
简单来说,就是将虚拟地址进行再次映射用于区分AVM与EVM,并对不同的enclave使用不同的秘钥加密以防止内存访问攻击。
一般来说性能较好的虚拟机间通信方案是通过共享内存,但这种方式势必涉及hypervisor,由于威胁模型中hypervisor中并不可信,因此vSGX设计了一个安全通信协议,通过端到端的对称加密使hypervisor不能够读取通信内容。具体的协议内容此处不作展开,与一些网络传输协议十分相似。Fig. 4展示一次了完整的通信过程。
-
TABLE III和Fig. 6是运行BYTEMark(NBench)的性能与和SGX的对比。
此外,文中设计了几组Microbenchmarks用于测试vSGX各个组件的性能,如初始化、跨虚拟机通信、执行特殊指令等。
-
-
给出了WOLFSSL和Graphene-SGX的结果,对应TABLE V和Fig. 7
由于设计限制,因此需要访问不信任区域内存时的性能花销较大,因而vSGX更适合CPU密集型的工作,比如加密操作。
原文始发于微信公众号(COMPASS Lab):【论文分享】vSGX:Virtualizing SGX Enclaves on AMD SEV