【论文分享】VeriSMo: A Verified Security Module for Confidential VMs

近期在COMPASS LAB上写了一篇论文分享，这里直接搬过来了~
推荐大家关注COMPASS LAB公众号~

OSDI '24 Best Papers:

ServiceLab: Preventing Tiny Performance Regressions at Hyperscale through Pre-Production Testing
Anvil: Verifying Liveness of Cluster Management Controllers
DSig: Breaking the Barrier of Signatures in Data Centers
VeriSMo: A Verified Security Module for Confidential VMs

今天分享的论文《VeriSMo: A Verified Security Module for Confidential VMs》来自2024年OSDI Best Papers。

大家有兴趣的话可以follow其中一位作者——Weidong Cui，该作者另外一篇文章《REPT: Reverse Debugging of Failures in Deployed Software》也荣获过OSDI的最佳论文奖。从作者的主页来看，该作者所在的组（MSR Redmond Security Research Group）最近的工作重点是确保机密云服务的安全。该组在AMD SEV-SNP方面的工作有助于在Azure上启用机密容器。他们建立了一个实用的append-only ledger system，以保护机密服务免受回滚攻击。本次介绍的论文为该作者最新的工作，为机密虚拟机构建完全验证的安全模块。

Background & Motivation

为消除对hypervisor的信任需求，硬件供应商推出了CVM (Confidential Virtual Machine) 以及相应的安全模块 (即，提供之前由hypervisor实现的安全功能) 。比如，AMD的SVSM (Secure VM Service Module) 等安全模块，以提供CVM内特权层中缺少的安全功能。

由于这些安全模块的安全性至关重要，通常使用 Rust 语言实现以利用其内存安全特性。但使用 Rust 实现并不能保证程序逻辑的正确性，unsafe Rust 代码的使用可能会破坏内存安全保证。

VeriSMo Overview

本文实现了AMD SEV-SNP上第一个经过验证的CVM安全模块—VeriSMo。

与其他安全模块类似，VeriSMo提供代码完整性、运行时测量和机密管理等安全功能。安全模块和guest OS之间的隔离基于AMD SEV-SNP上称为虚拟机权限级别 (Virtual Machine Privilege Levels, VMPL) 的新权限维度。VeriSMo在最高权限的VMPL0上运行，为低特权的VMPL3 (例如，应用程序) 提供安全服务 (见Fig. 1)。

与其他安全模块不同，本文对VeriSMo进行了形式化验证，以确保其功能正确性、信息流安全性和VM保密性及完整性。

Key Challenge

不受信任的 hypervisor 可以随时中断VeriSMo的执行并修改硬件状态，这种并发干扰使得在验证VeriSMo强制执行虚拟机的机密性和完整性时使用标准 Floyd-Hoare 推理变得很困难。

为应对该挑战，在验证时需要考虑以下两个层次 (见Fig. 2)：

• hypervisor的并发 (machine-model layer)
• VeriSMo的并发 (implementation layer)

Verification

传统的软件测试只能部分检查某些输入的正确性，无法正式确保正确性。形式验证是为正确性提供形式保证的唯一解决方案。以下是验证的三个目标：

• 功能正确性
• 信息流安全性
• CVM的机密性和完整性

如Fig. 2所示，本文将验证分为两层。在machine-model layer，作者定义了代表各种硬件资源的HW model，以验证CVM的机密性和完整性。在implementation layer，作者使用Rust的所有权检查和Verus (OOPSLA '23) 的权限来验证VeriSMo内部资源中功能正确性以及信息流安全性。

两层之间的交互由VeriSMo实现在执行硬件操作时必须满足的先决条件和VeriSMo实现在硬件操作后可以假设的后置条件来管理。

例如，当写入页表时，VeriSMo必须满足特定的前提条件，并且在页面上执行pvalidate指令后，VeriSMo可以假设有关内存页面的后置条件。上层可以假设满足前提条件，这样就可以使用这些前提条件来验证抽象机是否保留了虚拟机的机密性和完整性。这意味着machine-model layer需要依赖于implementation layer的正确性才能验证。

Machine-Model Layer Verification

所谓CVM的机密性和完整性，具体来说即确保VeriSMo所需的以下安全属性。

• 保证私有内存中虚拟机数据的完整性和保密性。hypervisor无法通过管理程序实体的任何操作序列来改变或显式读取硬件中的VM私有内存。

• 保持VMPL隔离。VMPL3无法显式读取VMPL0私有数据，每当VMPL0读取自己的私有数据时，它都会获得正确的数据，而不是VMPL3篡改的数据。

Abstract Machine Model & Security Property Specifications

• Ψ表示硬件资源(如寄存器、内存、页表和RMP)的内容和属性
• E0表示VeriSMo (VMPL0)
• E3表示guest OS (VMPL3)
• Ehv表示hypervisor
• D表示数据
• M表示私有内存
• S表示机密
• GVA表示guest virtual address
• SPA表示system physical address
• GPA表示Guest Physical Address
• RMP表示Reverse Map Table

操作原语（内存操作 / RMP 操作 / 页表操作等）由不同实体启动来读取或修改硬件资源。例如，定义硬件模型如何在嵌套页表遍历和 RMP 检查之后返回内存值。

Security Property Proof Sketches

为验证 CVM 机密性与完整性，需要证明以下五条引理：

• Ψ下CVM的M包含D，通过Ehv操作后达到状态Ψ‘；Ψ‘下，CVM读取M要么失败，要么返回D。【VM-Private Memory】
• Ψ下CVM的M包含S，通过Ehv操作后达到状态Ψ‘；Ψ‘下，Ehv读取M返回S的密文。【VM-Private Memory】
• Ψ下VMPL0的M包含D，通过Ehv/E3操作后达到状态Ψ‘；Ψ‘下，E0读取M要么失败，要么返回D；E3不可读取M。【VMPL0-Private Memory】
• Ψ下VMPL0访问GVA转换到SPA，通过Ehv/E3操作后达到状态Ψ‘；Ψ‘下，VMPL0访问GVA要么失败，要么转换到SPA。【Correct
  Guest Address Translation】
• 在任何可访问的Ψ下，CVM的GVA到SPA都是一对一映射。【Correct
  Guest Address Translation】

VM-private和VMPL0-private Memory的机密性和完整性，以及正确的页表转换，确保E0通过GVA访问的内存内容与存储在硬件状态中的内容保持一致。 这种一致性允许implementation layer验证专注于软件跟踪的状态，消除了必须担心实际硬件状态的复杂性。

为了在实现验证中将原语操作的前提条件从基于硬件的转换为基于软件的，作者团队证明了如果一个操作成功并且该操作的基于软件的约束为真，那么相应的基于硬件的约束也必须为真。

Implementation Layer Verification

该层验证VeriSMo功能正确性以及信息流安全性。

Permission-based Verification

作者扩展了基于权限的验证技术Verus中描述的基本内存权限的定义，将VeriSMo中Object-based Memory以及Raw Memory的权限均转化为Verus内存权限，以使所有内存访问在 AMD SEVSNP 虚拟机上下文中都是安全的。内存权限被定义为跟踪变量（SnpPointsTo），无法复制或构造。通过结合适当的初始假设来确保所有内存权限的初始唯一性，进而可以保证整个程序中每个权限的唯一性。

Examples to Convert Unsafe Rust to Safe Verus. 为了说明如何使用内存权限将 Rust 的不安全内存访问转换为Verus的安全内存访问操作，以下两个例子演示了如何通过验证(validate，红色闪电)或Rust的借用检查器(borrow checker，画叉圆圈)来识别不安全的访问。

第一个示例（Listing 1 中），0x1000为裸指针，mperm为该裸指针的内存权限。该示例采用指向0x1000处VMPL0私有内存的内存权限引用，因此它可以借用地址0x1000处的值。然而，第8行borrow checker发现无法更改内容，因为借用的权限是不可变的，执行非法写操作。第九行验证器发现，由于内存标识符不匹配，出现非法访问 0x2000 处的原始内存。

第二个示例（Listing 2 中）提供的另一个示例演示了验证过程如何检测不安全的 RMP 更新，从而确保有效的内存状态。它初始化一个未经验证的内存权限，然后在最后将其分配给 VMPL1，以使内存可供 VMPL0 访问。第6行验证器发现，在pvalidate 之后，内存权限仍然没有准备好进行其他 RMP 内存操作，直到操作被确认并且内存内容被清除，导致第 6 行断言失败。此外，第10行验证器发现pvalidate原语函数进行双重验证，使得第 11 行失败。

除了内存权限，该工作还考虑锁权限和寄存器权限。

锁权限. Fig. 3演示了处理内存和锁权限的安全操作。 当VMPL0私有内存被某个CPU上的软件锁定后，其他实体不能并发修改。 因此，可以将内存视为VMPL0的私有内存，并且获取操作将安全地授予内存权限以进行不受限制的内存访问。 对于与hypervisor或guest OS共享的内存，锁定时获得的内存权限只允许复制和写入，而不允许借用引用。 对于无限制的操作，开发人员必须将内存复制到VMPL0私有内存中，或者使用rmpadjust/ alidate操作将其转换到VMPL0私有内存中。

寄存器权限. 大多数寄存器都是由软件私有控制的，因此我们通常可以在适当的引导步骤后保持稳定的不变属性。由于一个CPU有固定数量的寄存器，每个CPU使用一个单独的权限来表示所有CPU的寄存器。一些寄存器需要特殊的许可设计。

不同寄存器存在不同限制：

• 对于像IDTR和GDTR这样保存内存段指针的寄存器，作者保证在对这些寄存器进行写操作时将内存所有权转移给硬件。

• 指令指针(RIP)和堆栈指针(SP)，会以危险的方式无意中影响软件行为。 该工作通过删除访问这些寄存器的权限来防止显式使用它们。

• 对CR3的写操作需要对页表和所有可用的虚拟内存地址都具有可跟踪的可变权限。这可以防止对CR3进行不正确的修改，因为合并CPU使用的所有内存权限非常复杂。

Information-Flow Verification

除了保证安全的内存访问外，防止通过显式或隐式信息流泄露机密也很重要。以下为机密变量泄露的两个例子。Fig .4 (Left) 中，机密变量 high 被通过数据流泄露到公开变量low。Fig .4 (Right) 中，机密变量 high 通过控制流侧信道被泄露。

在VeriSMo中，作者定义了一个精确的跟踪策略，通过监视变量的潜在机密猜测空间来维护安全的信息流。简单来说，每个变量都会有一组可能的值（即，猜测空间）；如果该集合为全集，则相应的变量为认为是机密；如果该集合是单元素，则相应的变量为公开的。

VeriSMo只接受三种类型的机密:

• 硬件生成的VM通信密钥。

• VeriSMo自己的私钥/公钥对。

• guest OS的对称加密密钥。

由于这些机密在VeriSMo中仅由可信的加密函数使用，因此在调用加密函数时，只会遇到有限数量的关于集合大小的证明。通过可信和正式验证的加密库，可简化安全检查，以判断变量是否对实体完全公开或机密。

总体来看，这需要验证器确保机密变量满足以下几点：

• 只有它能作为密钥。

• 位于VMPL0私有内存中。

• 无法用于侧信道泄露（例如，控制流，内存地址等）。

Implementation & Performance

• 使用 UnixBench 工具对运行在VeriSMo安全模块下的 Linux 内核进行性能测试。测试结果显示，VeriSMo引入的性能开销几乎为零，与没有使用安全模块的系统相比，性能下降可以忽略不计 (见Fig. 5)。

• 通过与另外两个原型（linux-sm 和 c-sm）的比较，证明了VeriSMo 在性能上没有因为引入验证而受到影响。

• 验证过程需要大约 6 分钟，展示了通过优化的验证设计和 Verus 对 SMT 解决器的优化，实现了高效的证明时间。

• 通过形式化验证发现了一个潜在的安全漏洞，该漏洞可能允许恶意hypervisor通过特定的内存页面绑定攻击来访问敏感信息，该漏洞被报告给AMD社区并被修复。

Open Source

https://github.com/microsoft/verismo.