【机密计算顶会解读】07：eOPF——用于机密云计算的可扩展编排和保护框架-海口c网

【机密计算顶会解读】07：eOPF——用于机密云计算的可扩展编排和保护框架

article/2025/8/16 1:19:45

导读：本文介绍eOPF框架，通过监控enclave与OS交互，从而提供细粒度控制、共同认证和侧信道防御。

原文链接：An Extensible Orchestration and Protection Framework for Confidential Cloud Computing | USENIX

An Extensible Orchestration and Protection Framework for Confidential Cloud Computing（OSDI’23）

一、研究背景

SGX在管理enclave时的不透明性和对硬件特性的依赖，导致云服务提供商难以有效监控和控制enclave的行为，限制了资源的精细化管理和安全策略的实施；同时，SGX容易受到侧信道攻击，如通过缓存分析泄露信息，暴露了硬件层面的安全漏洞；此外，现有技术缺乏可靠的机制验证enclave与安全服务框架是否共处同一位置，远程用户难以确定enclave是否得到充分保护。

上述问题的根源在于缺少全面监管enclave与操作系统交互的框架和缺乏对enclave的细粒度控制能力，从而限制了云服务提供商提供高级安全服务的能力，也影响了用户对云服务安全性的信任。因此，迫切需要一个能够克服SGX局限性、提供更强大安全保障和灵活管理能力的解决方案。

二、现状分析

三、应对设计

为解决Intel SGX在云计算环境中的局限性，特别是针对资源管理、共同认证以及侧信道攻击漏洞的难题，论文提出了enclave-OS Protection Framework（eOPF）框架，通过提供虚拟机管理程序（hypervisor）级别的工具来监控所有enclave与操作系统的交互，并实现受保护的服务。

eOPF设计的的核心是允许云服务提供商对enclave进行细粒度的控制和监控。通过拦截SGX的监督指令和异常，eOPF能够观察和操纵页表，从而保护enclave的执行环境。此外，eOPF通过内存保护、单步模式和中断拦截机制，可靠地捕获enclave执行期间的所有事件，如enclave的启动和停止事件。
eOPF还设计了一种共同认证协议，通过在enclave创建时嵌入一个秘密标识符（eid），并通过SGX远程证明将此标识符传输给远程用户，以验证enclave是否与eOPF在同一物理位置。通过这种方法，用户可以信任他们的enclave是受到eOPF保护的。
为了解决侧信道攻击问题，eOPF提供了一套补充的防御措施，包括对跨核心（Cross-Core）资源的隔离，以及对每个核心（Per-Core）资源的失效或停用。跨核心资源隔离主要将被所有处理器核心共享的资源划分为不同的分区，确保了攻击者无法从其他核心观察enclave的资源访问情况。对于每个核心资源，eOPF确保没有其他任务在同一核心上并行执行，有效降低了攻击者利用共享核心资源发起攻击的风险。

四、eOPF技术解析

eOPF的关键技术之一是拦截enclave事件。eOPF通过EPT（extended page tables）和VMCS（Virtual Machine Control Structure）实现对SGX指令的拦截，这是通过设置VMCS中的ENCLS指令拦截位和相应的指令位图来完成的。当ENCLS指令被触发时，eOPF首先实现指令所需的特定服务的操作，然后使用其受信任的代码和操作系统提供的参数执行被捕获的指令，最后通过更新处理器的程序计数器来恢复操作系统的执行。

共同认证协议是eOPF的另一个关键技术。首先，云服务提供商在云机器上安装eOPF，用户与eOPF建立安全通信，发送秘密标识符（eid）给eOPF。在enclave创建时，eOPF将eid嵌入enclave内存中。用户随后可以通过SGX远程证明验证enclave中的eid，确保enclave与eOPF处于同一位置，从而确保enclave的安全性。

在侧信道防御方面，对于跨核心资源，eOPF将OS初始化的页表设为只读，防止OS通过page fault和access bit推断enclave信息。同时，eOPF利用CAT（Cache Allocation Technology）将enclave和OS使用的LLC（Last-level cache）进行隔离。对于每个核心资源，如L1/L2缓存和分支预测单元，eOPF在enclave退出时禁用超线程并清空缓存，确保攻击者无法推断enclave行为。

五、验证评估

论文通过SPEC CPU 2006评估了eOPF在实际应用中的性能表现。实验结果表明，eOPF的基础框架（不包含侧信道防御）仅引入了低于2%的性能开销。启用所有侧信道防御措施会提高eOPF的开销，尤其是在处理内存密集型的程序时，如gcc程序的性能开销达到了311%。不过，对于大多数程序，性能开销仍然控制在较低水平，几何平均性能开销为17%。

eOPF的侧信道防御机制在开销上与采用启发式攻击检测的解决方案相近，例如Varys引入了15%的性能开销。但eOPF通过实施失效和隔离策略，提供了更为全面的保护，其效果与使用高成本加密技术的方案（如Raccoon会产生21.8倍的性能开销）相当。