G.O.S.S.I.P 阅读推荐 2025-04-04 The Road to Trust

今天给大家介绍的论文是来自 NDSS 2025 的 The Road to Trust: Building Enclaves within Confidential VMs，这是一个在 AMD SEV-SNP 这一虚拟机型 TEE 上运行类似 Intel SGX 的用户态 enclave 的框架，类似在 AMD SEV-SNP 上兼容了 Intel SGX。论文作者团队来自信工所、蚂蚁集团以及中科大，王晓峰老师也参与了工作。

TEE 方案根据保护目标的不同，可以区分为两种。以 Intel SGX 为代表的 TEE 仅仅保护一个程序（比如一个用户态应用，或者甚至是应用的一部分），并且限制了只能跑经过验证的代码。这样有个缺点，就是需要开发者去适配 Intel SGX。而像 AMD SEV、Intel TDX、ARM CCA 这种 TEE 方案则会保护一整个 VM，好处就是里面运行的 VM 一行代码都不用改。

但 VM-based TEEs 存在一个问题：VM 对于可信应用来说太大了，里面包括了很多未经认证或检查的代码。我们知道 TCB 越大，组件发生漏洞的可能性越大。如果攻击者控制了 VM 内部的代码，他就可以破坏 VM-based TEEs 的威胁模型。

那么，有没有办法在 VM-based TEEs 中引入隔离呢？这篇工作实现的 NestedSGX 就是这样的一个框架。

我们刚刚提到， VM-based TEEs 的好处之一就是兼容性。但如果我们想要区分 VM 中的可信应用代码和其他代码，就一定要对 VM 内部的操作系统或其他组件做一些修改才行。既然对通用系统的兼容性都要破坏了，比起自己新定义一个 enclave 应用标准，不如我们直接来兼容已有的应用层可信框架 Intel SGX 吧。（不过这篇工作和已有的 vSGX 不同，后者在二进制层面兼容，而本工作是在源码层面兼容）这时小编突然想起了一个 meme：

作者选择在 AMD SEV-SNP 上进行开发。我们为对其不熟悉的读者简单介绍一下，SEV 是 AMD 的 TEE 方案，自 2016 年诞生起已经进化了四次，四个形态分别是 SEV、SEV-ES、SEV-SNP 以及 SEV-TIO，大部分宝可梦都没有这么多形态。SEV-SNP 提供了一个重要的功能 Reverse Map Table（RMP），记录了每个物理内存页的所属（如 hypervisor、某个 VM 等）。只要好好配置这个表，硬件就能禁止恶意的特权软件（hypervisor）访问被保护的 VM。

论文重点利用了 SEV-SNP 的一个可选的特性 Virtual Machine Privilege Levels（VMPLs）。这是一个与 x86 已有的特权级别非常类似的系统。它提供了 VMPL0~VMPL3 由高到低四个级别，在 RMP 中记录某个 VMPL 对于该页的访问权限限制后，硬件会根据当前 CPU 上下文中当前所属的 VMPL 来判断访问是否合法。高 VMPL 的软件可以使用 RMPADJUST 指令来修改低 VMPL 对某个页的权限。 这个特性的一大特色是它和其他保护措施是正交的（orthogonal），即两者独立且互补。因此，系统软件开发者可以拿它来做一些额外的保护措施。

在 NestedSGX 的设计中，VMPLs 被用来区分 Enclave 和 VM 中的不可信组件。负责安全功能的 Security Monitor 和 Enclave 被划分到 VMPL0 中运行，而可能出问题的 Guest OS 和其他应用则被分到 VMPL1 中。

虽然图里看起来 Enclave 的权限要比 Guest OS 高，但恶意的 Enclave 无法直接攻击 Guest OS：VMPL 不会影响传统的页表保护，而页表可以确保用户态无法访问内核态的内存这一防护仍然奏效。

除了内存的隔离外，另一个需要实现的功能是对于 Enclave 的 Measurement、attestation 和 sealing。借助 SEV 中已有的安全协处理器 AMD-SP 提供的相关基础设施，NestedSGX 中的 Security Monitor 将会负责加载和测量 Enclave，同时允许 Guest OS 自由运行应用而不参与验证。

除了上面两种机制外，工作的一大部分在于实现与 Intel SGX 的兼容以及工程上的实现，具体细节请感兴趣的读者直接参考原文。

作者基于 AMD 提供的软件栈（有 QEMU, Open Virtual Machine Firmware (OVMF) 和 Linux 内核）实现了 NestedSGX，往 Linux Secure VM Service Module 里新增了 5500 行代码。性能方面，NestedSGX 在上下文切换方面比原版 Intel SGX 慢约 1.9-2.1 倍，但在多数测试中开销较小，计算和内存密集型任务的平均开销差异低于2%，I/O 密集型任务的开销差异低于15.68%。作者还测试了一些真实的应用，见下图：

局限性方面，由于设计因素，NestedSGX 目前不支持 SGX 的 user_check 和 Enclave 与 APP 之间的内存共享，也不支持将 enclave 的内存交换到磁盘等等。作者表示这些我们都可以修。

总结：NestedSGX 在 VM-based TEE 中实现了对一个 Enclave 应用的保护，对传统的威胁模型进行了强化。基于 Intel SGX SDK 进行开发的应用可以在这套系统上直接运行，依靠 AMD SEV-SNP 提供的 VMPLs 等硬件功能得到良好的安全保护，同时不会引入过大的开销。

原文：https://www.ndss-symposium.org/wp-content/uploads/2025-385-paper.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2025-04-04 The Road to Trust