【云安全】Security and Performance in the Delegated User-level Virtualization（2023 OSDI）

调查显示，所有已知的威胁主机内核的管理程序漏洞都位于VM plane，委托虚拟化基于一个小型的硬件扩展，将内核中的VM plane完全卸载到一个名为DuVisor的用户空间管理程序，该管理程序直接与其VM交互而不退出主机内核。
我们在开源的RISC - V CPU上实现了基于FireSim的硬件扩展，并在其上搭建了基于Rust的DuVisor。评估结果表明，DuVisor以可忽略的性能开销( < 5 % )显著降低了攻击面。

introduction

虚拟化技术进展

阶段1：单片管理程序将所有函数置于内核模式；

阶段2：将部分功能卸载到用户态辅助进程(例如 IO后端驱动)中，可以复用管理硬件资源的宿主机OS；

阶段3：将部分虚拟化功能卸载到硬件(例如,shadow paging→nested paging)中；

d：本文提出的DuVisor方法，将所有的VM plane功能(例如, VM退出处理)委托给用户空间，并在运行时最小化主机内核和VM之间的直接交互。

• VM plane，运行时处理VM出口和虚拟化资源的所有VM - service函数。在运行时通过处理VM exits频繁地与VM进行交互，通过指令模拟、嵌套分页、设备虚拟化等方式启用各种虚拟资源。

• hypervisor plane，初始化VM plane、管理物理资源和处理紧急事件的所有管理程序- service函数的集合。为VM plane提供物理资源控制和致命错误处理。

安全问题

hypervisor内核内组件拥有最高等级的权限，在运行时与VM直接和最频繁地交互，从而将更多的攻击面暴露给VM。

所有已知的威胁主机内核的管理程序漏洞都存在于VM plane。

• Large vulnerability quantity
  • About 500 CVEs for KVM and Xen
  • Most of them are host-attacking
• Severe security threats
  • Over 90% of the Host-attacking CVEs cause DoS attacks
  • 26% and 34% cause privilege escalation
• Low exploit cost

现有方法局限

大量工作试图剥夺虚拟机管理程序的内核功能：

• NOVA基于微内核架构构建了一个微Hypervisor
• DeHype试图将KVM的大部分部件降级到用户态，而在内核态留下一个HypLet，因为敏感的硬件虚拟化指令只能在这种模式下执行。

然而，这种剥夺性的执行方式存在两个方面的局限性：

• 不可消除的in-kernel漏洞：先前的工作试图将尽可能多的VM平面组件卸载到用户空间。遗憾的是，绝大多数( 58.75 % )的CVEs无法被淘汰，因为它们所在的VM - plane子系统由于硬件特权限制必须以HK模式运行。例如，中断虚拟化子系统访问特权寄存器，因此必须保持在HK模式下。同样，一些内存虚拟化功能，特别是那些为虚拟机配置敏感的stage - 2页表的功能，也必须保持在HK模式下。
• 冗余且代价高昂的mode switching：由于虚拟机管理程序必须使用内核组件来驱动硬件虚拟化扩展，将大部分内核组件移动到用户空间会导致虚拟机与用户级虚拟机管理程序之间由于内核的参与而产生更频繁、更昂贵的交互，从而导致更高的性能开销，因为在每次VM出口处理上都会产生昂贵的VM - VMM通信开销。

挑战和可能

本文的核心思想是将所有在运行时直接与虚拟机交互的hypervisor组件移动到用户空间，以最小化用户模式hypervisor中发现的任何安全缺陷和可靠性问题的影响。

三个挑战：

• 1 )权限限制：现代硬件虚拟化扩展仅在user mode下可配置，需要在host kernel中存在一个hypervisor组件来使用这些扩展
• 2 )安全风险：简单地将VM硬件资源的管理转移到user modde，违背了最小特权原则，扩大了攻击面
• 3 )性能开销：大多数VM的出口都是由内核转发给用户态函数来处理的。然后，控制流必须再次返回内核以恢复VM的执行，导致过多的运行时ring穿越

我们发现硬件虚拟化扩展和内核模式之间的紧耦合是上述挑战的根本原因。

幸运的是，硬件进步使许多以前只能由内核访问的硬件资源暴露给用户模式成为可能。一个突出的例子是英特尔发布了用户级中断，允许用户级进程处理物理中断。另一个例子是物理内存检查，如RISC - V物理内存保护( Physical Memory Protection，PMP ) ，它限制了程序可以访问的物理内存范围。

结合这些最新的硬件趋势，我们认为现在是时候对现有的硬件虚拟化扩展进行改造，并将虚拟化接口安全有效地暴露给用户模式。

本文思路

本文提出了一种将VM plane与hypervisor plane解耦的管理程序设计原则。

遵循解耦原则提出了委托虚拟化扩展( Delegated Virtualization Extension，DV-Ext )，该架构消除了kernel mode提供VM抽象的概念，将硬件虚拟化接口安全暴露给user mode。

• 将与虚拟机直接交互的VM plane卸载为以用户模式运行的每个虚拟机管理程序(称为DuVisor)，DuVisor可以直接利用DV - Ext的寄存器和指令来服务运行时的VM exits，而不必陷于host kernel
• 留下kernel mode的一个很小的DV - driver负责hypervisor plane，DV - driver只是偶尔醒来，为DuVisor进程分配物理资源或处理致命错误

DuVisor在用户态高效地提供了不同的虚拟化功能，具有很强的安全性保证。

• 对于CPU虚拟化，DuVisor进程为每个虚拟CPU ( vCPU )创建一个专用线程( vthread )，vthread使用DV - Ext处理该vCPU在用户模式下的VM出口。
• 对于内存虚拟化，DuVisor为其VM配置了一个stage - 2页表，并在用户模式下通过预先分配的物理内存范围来处理stage - 2页故障。
• 对于设备虚拟化，DuVisor中的半虚拟化( PV )后端驱动直接与VM的前端通信。DuVisor进一步使用用户级发布中断，在向其VM发送通知时完全绕过主机内核。

贡献

• delegated virtualization，卸载部分VM plane功能到user-level的DuVisor，只留少量tiny DV-driver在host kernel，最小化暴露给guest VM的供给面
• 轻量级硬件扩展Dv-Ext，使得DuVisor完全在user mode服务VM
• 构建了Rust-based的DuVisor原型，在RISC-V上实现硬件扩展
• 使用周期精确的FireSim在AWS F1 FPGA上评估性能

2 设计和部件扩展

整体设计

硬件扩展DV-Ext：它授权host kernel来决定是否将hardware virtualization functions委托给HU模式。如果启用委托模式，硬件虚拟化接口可以被非特权软件访问，而不会陷于host kernel。如果不启用，DV - Ext的功能与传统的硬件虚拟化类似，以实现兼容性

DuVisor：HU模式的DuVisor进程利用DV - Ext暴露的硬件接口来控制未修改的VM 。为了支持虚拟机的正常执行，DuVisor通过动态虚拟化物理资源来处理运行时虚拟机的退出。在本文中，该工作流被定义为VM plane，并在HU模式下由DuVisor进程处理。为了支持HU模式下的内存虚拟化，DuVisor进程为其虚拟机构建了一个stage - 2页表。如果页面错误是由于缺少或非法的页面映射导致的，DuVisor会动态地在stage - 2页面表中添加或更新映射条目。与传统的hypervisor一样，DuVisor为每个vCPU生成不同的用户级线程，称为vthreads。还支持该虚拟机的PV I/O设备和虚拟中断(包括定时器)。

DV-Driver：在主机内核中插入一个微小的DV - driver作为hypervisor plane，它偶尔参与管理每个DuVisor的物理资源，而不干扰运行时VM出口的处理。具体来说，DV - driver使用DV - Ext使能/禁用委托模式，并为DuVisor进程分配资源(如物理内存)。为了减轻安全风险，它还限制了DuVisor的物理内存视图，并处理紧急情况。DuVisor仍然依赖于host kernel来调度所有的线程和虚拟机。

威胁模型

• 敌对的租户危害管理程序，进一步攻击主机内核和其他VM；
• DuVisor CAN be comprised
• 硬件实现正确；
• 信任带有DV - driver的主机内核
  

---

3 实验

实现细节和实验评估略

---

4 相关工作

移动内核功能到用户态

将内核特性剥夺到用户空间是增强安全性、易于开发和提高性能的经典方法。

微内核是一种典型的[ 52、62、70、78 ]设计，其中文件系统和驱动程序等系统服务运行在用户态。

对于单体内核，也有类似的方法，在用户空间实现文件系统[ 50、79 ]、调度器[ 57 ]、网络服务[ 75 ]和沙箱[ 53 ]。

在管理程序功能方面，研究重点是通过将管理程序的部分功能移动到用户空间来减少管理程序的TCB，如DeHype [ 91 ]和NOVA [ 87 ]等设计。

与DuVisor不同的是，它们仍然需要内核中的可信模块通过硬件虚拟化接口来执行VM平面的功能。DuVisor是第一个将运行时VM - plane功能完全迁移到用户空间的系统，使单核[ 40、61 ]和微内核的虚拟化架构都受益[ 55 ]。

安全的VM

许多其他研究都探讨了如何在不可靠的管理程序上实现更好的虚拟机隔离。许多努力都集中在减少管理程序TCB [ 66、81、85、92 ]。

• CloudVisor [ 92 ]使用嵌套虚拟化技术来剥夺Xen [ 40 ]管理程序。

• HypSec [ 66 ]从KVM管理程序中分离出一个微小的Corevisor作为TCB。

• 其他方法已经致力于加固管理程序的TCB，例如SeKVM [ 67、68 ]，它们使用形式化验证来确保管理程序的安全保证。

• 与DuVisor不同的是，这些解决方案仍然依赖于内核内的硬件虚拟化接口，与未改进的传统管理程序相比，性能开销较小。

一些解决方案通过提供相互隔离的per-VM hypervisor实例来提高管理程序的可靠性。

• Nexen [ 84 ]将虚拟机管理程序解构为每个虚拟机的非特权服务片。
• HyperLock [ 90 ]将虚拟机管理程序分解为每个虚拟机的孤立影子副本。
• 与DuVisor相比，它们仍然依赖于传统的硬件虚拟化接口，并遭受软件隔离机制的性能惩罚。

另一些人提出了硬件扩展，以从TCB的[ 39、58、60、66、89]中移除脆弱的管理程序。

• NoHype [ 60 ]通过对物理资源进行静态划分和硬件修改来消除管理程序及其攻击面。但是，它不允许资源过度订阅，因此在生产场景中部署是不切实际的。

工业机密虚拟机( CVM )解决方案，例如AMD SEV-SNP [ 1 ]和ARM CCA [ 5、69 ]，利用专门的硬件安全扩展来保护虚拟机的数据免受恶意管理程序的攻击，而恶意管理程序不能访问或污染虚拟机的内存和寄存器。由于CVM和DuVisor都依赖于宿主内核，因此它们都容易受到非管理程序的DoS攻击。

然而，与CVM不同，DuVisor通过将所有VM平面函数剥夺到用户空间，以最小化暴露在VM上的宿主内核运行时攻击面，从而避免了由于内核管理程序漏洞引起的DoS攻击。另一方面，CVM需要修改客户OS设备驱动程序，而DuVisor支持未修改的VM。

CVM和DuVisor是正交技术，可以组合使用以获得更大的效益。DuVisor的设计可以应用于防御CVM内核中管理程序漏洞引起的DoS攻击，我们计划在未来的工作中进行探索。

现有的CVM都是由内核中的管理程序通过安全固件接口(如ARM CCA的RMM和TF - A , Intel TDX模块等)来控制的，而(如ARM CCA的RMM和TF - A , Intel TDX模块等)只能在宿主内核中被调用。通过将这些接口暴露给用户空间，DuVisor可以与CVM一起使用，从而消除内核中共享的管理程序漏洞。