面向云平台非可信Hypervisor的保护机制综述*

顾佳男，郑蓓蕾，翁楚良

华东师范大学 数据科学与工程学院，上海 200062

1 引言

近年来，随着人工智能、物联网等新兴领域的成熟，以及多核/众核、GPGPU（general-purpose computing on graphics processing units）、NVM（non-volatile memory）存储介质、RDMA（remote direct memory access）等新型硬件的发展，多租户云平台的作用也在这个大数据时代展现得淋漓尽致。多租户云平台针对用户的服务由原先的应用托管、内容交付、电子商务、网络托管等，加入了海量数据存储、计算等重要的大数据应用场景。以虚拟化技术为基础搭建的多租户云平台，例如亚马逊的EC2[1]、微软的Azure[2]，相比于自主构建的纯硬件环境，在计算资源和存储资源的廉价性、实用性以及扩展性等方面有着诸多的优势。这些优势使得各类多租户云平台在越来越多的大数据应用领域显得有竞争力。如果将数据比喻成当今互联网行业的一个重要能源，那么云平台就是驱动这个能源的重要发动机之一。

Hypervisor是虚拟化技术中最重要的软件层次，也是多租户云平台底层能够有效和安全地驱动数据能源的关键组件之一。在系统虚拟化技术中，Hypervisor扮演着为客户虚拟机映射真实物理资源的角色，同时它也需要为不同客户虚拟机之间的物理资源实现共享和隔离。因此，Hypervisor的功能与效率直接决定系统虚拟化技术的功能与效率，它的安全和可靠更是虚拟化技术的基础。现有很多工作[3-19]就是基于可信Hypervisor来构建针对客户虚拟机的保护机制，以保证其内核和上层应用的安全。

但是，和操作系统内核一样，Hypervisor也面临着来自漏洞和恶意攻击的威胁。一个完整的Hypervisor就如同操作系统内核一般，其代码量也是很庞大的。例如一切以精简出发设计的开源虚拟化技术Xen[20]，其4.8版本的Hypervisor也由 近30万行的代码构成，更不用说代码量更庞大的KVM（kernel-based virtual machine）[21]、VMware[22]等其他虚拟化技术。另外，NVD（National Vulnerability Database）[23]数据库中存有很多针对Xen、KVM和VMware等虚拟化技术的漏洞报告，而文献[24-25]也全面综述了Hypervisor中存在的安全问题。因此，Hypervisor的庞大攻击面以及其在虚拟化技术中的核心地位，使得任意可行的攻击[26-28]对整个多租户云平台的安全造成极大的威胁。

综上所述，设计和实现面向云平台非可信Hypervisor的保护机制迫在眉睫。现有一系列的研究工作运用不同的思想和方法来构建面向云平台非可信Hypervisor的保护机制。本文将对这些研究工作进行梳理，并分析该领域存在的问题和挑战以及研究趋势，从而为未来虚拟化技术在多租户云平台中安全运用的研究提供有价值的参考。与现有综述[29]不同的是，本文从面向云平台非可信Hypervisor的保护机制的构建角度出发，分别深入梳理和分析现有的完整性检测机制、防御机制以及针对非可信Hypervisor的虚拟机隔离机制。

2 面向云平台非可信Hypervisor的保护机制的可行性和分类

本章将介绍构建面向云平台非可信Hypervisor的保护机制的可行性与挑战，并对现有保护机制的构建进行分类。

2.1 可行性与挑战

典型虚拟化技术中的Hypervisor运行在Ring0层级，同时它拥有最高执行权限。而Hypervisor的保护机制运行的不同层级选择都会面临相应挑战，这些挑战也是决定保护机制是否有效的重要因素。

一般来说，在计算机系统中，处在越低层级的管理系统意味着可以对运行在它上层的应用或是系统有着更多的控制权，即执行权限越高。不同的执行权限分别对应CPU（central processing unit）执行的Ring0、Ring1、Ring2、Ring3权限。因此，按照这样的思路，保护机制如果有Ring0的执行权限，而Hypervisor保有Ring0权限或者置于Ring1权限，此时拥有Ring0权限的保护机制则可以针对Hypervisor来全面地执行保护操作。但是，若将保护机制置于Ring0权限，无论Hypervisor是置于Ring0权限或是Ring1权限，其本身对虚拟化系统带来的修改相对于添加一个上层应用来说是比较大的。那么是否能将保护机制直接置于Ring1权限或者Ring3权限，而对Hypervisor不进行任何修改呢？文献[30]论述了此思路的可行性。其基本原理在于，在系统虚拟化中，Hypervisor的存在对上层应用并不是完全透明的。系统虚拟化与裸机之间是会表现出逻辑差异、资源差异和时间差异的，并且这些差异能够被上层应用间接感知。通过对底层的感知，上层的保护机制可以做到对Hypervisor的检测和有针对性的防御。而上层的保护机制是否有效的关键问题在于，其是否能正确理解在Hypervisor中的恶意攻击的基本逻辑和实际影响。

下面列出面向云平台非可信Hypervisor的保护机制所面临的挑战：

第一，语义鸿沟。底层或者上层的保护机制在实际运行中会遇到难以理解Hypervisor所做的映射、调度、隔离等任务操作的问题。

第二，避免引入新的攻击面。保护机制的加入要注意不能过度地“入侵”Hypervisor的运行，以避免新攻击面的引入。

第三，确保保护机制本身的完整性。如果恶意Hypervisor感知到保护机制的存在，它可能有很多方式去绕过或者瓦解保护机制。例如，篡改保护机制的内存、控制流以及任何有效跳转。保护机制需要保证其本身的完整性，使得其运行的过程中不受到恶意Hypervisor的影响。

第四，确保保护机制输入和输出的可信度。任何恶意的Hypervisor都有可能伪造保护机制的输入或者输出，以达到欺骗保护机制的目的。在这种情况下，即使保护机制本身运行正常，如果其检测或者防御的输入和输出没有足够的可信度，那么一切努力都将付之东流。

2.2 分类

如图1所示，根据面向云平台非可信Hypervisor的保护机制的研究现状，可将不同类型和侧重的保护机制进行如下分类。第一类是构建Hypervisor完整性检测机制，其构建方法有：基于快照、基于事件和基于远程验证。这类保护机制旨在检测Hypervisor运行中是否存在破坏其完整性的攻击或漏洞。第二类是构建Hypervisor防御机制，其构建角度有：针对Hypervisor的控制流、指令仿真和精简可信计算基（trusted computing base，TCB）。这类保护机制旨在提高Hypervisor自身抵御攻击和漏洞的能力。第三类是构建针对非可信Hypervisor的虚拟机隔离机制，其构建方法有：基于嵌套虚拟化和基于加密技术，其中加密技术又分为基于软件和基于硬件的加密技术。这类保护机制旨在保证即使面对恶意的Hypervisor，客户虚拟机依然能够保有隐私和完整性。

Fig.1 Classification of protection mechanisms for untrusted Hypervisor in cloud图1 面向云平台非可信Hypervisor的保护机制的分类

3 Hypervisor完整性检测机制

本章将梳理针对非可信Hypervisor的完整性检测机制，其中包括基于快照、基于事件以及基于远程验证的完整性检测机制。

3.1 基于快照的检测

基于快照的检测是最常用的完整性衡量方式。完整性检测机制通过分析其截获的Hypervisor在内存中的快照，来查找恶意攻击的痕迹或者漏洞。

HyperCheck[31]借助x86的SMM（system management mode）来构建基于快照的完整性检测机制以实现针对非可信Hypervisor的保护。在SMM中，CPU的运行会切换到一个单独的SMRAM（system management random access memory）存储器中的地址空间，并且当前运行的代码的所有硬件上下文也都保存在SMRAM存储器中。处于SMM模式中的CPU可以透明地执行SMRAM存储器中的代码。SMRAM存储器可以充当可信的存储空间，因为它无法被任何其他设备访问。因此，只要SMRAM存储器被正确设置后锁定，即使是Hypervisor也不能干扰SMRAM存储器中程序的执行。借助SMM的上述特性，Hyper-Check针对Hypervisor的静态数据结构是否被攻击进行检测。HyperCheck具体由三部分组成：物理内存获取模块、分析模块和CPU寄存器检查模块。物理内存获取模块由网卡设备实现，而网卡的驱动程序和CPU寄存器检查模块一起放入可信的SMRAM中。CPU寄存器检查模块读取CPU寄存器并验证其完整性。分析模块是独立于系统的安全模块。物理内存获取模块通过网卡与分析模块交互，分析模块检查网卡发来的物理内存的内容并验证其是否安全。

上述HyperCheck的完整性检测本身是由Hypervisor触发的。检测触发的不透明性很有可能留下攻击隐患，例如擦洗攻击可以在HyperCheck触发检测之前隐藏自己的痕迹。HyperSentry[32]也用到了SMM来构建基于快照的完整性检测机制，并且还用到了IPMI（intelligent platform management interface）技术[33]进一步构建隐秘信道来实现检测的触发。IPMI是一种面向服务器的平台管理接口，它直接实现在硬件和固件中。IPMI的关键特性在于其管理功能独立于主处理器、BIOS（basic input output system）和任何系统软件。因此，基于IPMI构建的信道可以避免任何恶意Hypervisor等最高权限代码的感知。IPMI能通过直接串接或局域网等方式向远程端计算机提交信息。系统管理员能使用IPMI消息去向目标机器发出请求。HyperSentry正是利用IPMI技术的上述特性构建了隐秘通道，如此一来避免了非可信Hypervisor对检测触发的感知，进一步提高了完整性检测机制的保护效果。具体来说，HyperSentry将完整性检测代码驻留在SMM的SMRAM存储器中，SMRAM存储器提供其基本代码所需的保护。HyperSentry的隐秘通道使用IPMI和目标平台主板上的基板管理控制器远程触发硬件SMI（system management interrupt）中断，从而触发SMM中对Hypervisor的代码、数据和CPU状态的完整性检测。

但是，HyperSentry和HyperCheck中运用的SMM，其安全性不能被视为理所当然，因为SMM的处理程序可以被恶意攻击篡改[34-35]。

Copilot[36]使用专用的PCI（peripheral component interconnect）设备，即EBSA（Intel StrongARM SA-110/21285 evaluation board）[37]来监控系统运行时内存快照的完整性。EBSA具有完整的总线主控功能，并支持与主机存储器的DMA（direct memory access）通信。在EBSA的独立模式下，Copilot将其配置为拒绝来自主机处理器的所有配置读取和写入，从而使其执行路径不受主机上的攻击者的影响。在完整性检测中，一方面通过哈希主机的内核，Copilot可以检测任何对主机内核现有指令的恶意修改。另一方面，Copilot监视恶意攻击可能添加跳转指令的位置或可能导致现有主机内核执行外部程序的函数指针。尽管Copilot利用了PCI设备的特性，既可不被恶意修改也可不被主机系统检测到它的存在，但是它有两个主要缺点：首先，PCI设备上运行的代码与正在运行的系统之间存在语义鸿沟，即PCI设备不能访问CPU状态，例如CR3寄存器的状态。而对CPU状态的访问对于细粒度的完整性检测过程是必不可少的。其次，现有的攻击[38]可以防止Copilot正确地访问物理存储器，使得PCI设备看到的物理内存与CPU看到的不同，因此被篡改的物理内存区域将被隐藏于检测之外。

3.2 基于事件的检测

在3.1节中讨论的HyperSentry、HyperCheck和Copilot的完整性保护机制所采用的方法都是基于快照的检测方法。但是，基于快照的检测通常存在固有的弱点。主要是因为它们只检查在一定间隔内收集的快照，而忽略了间隔中的变化。攻击者恰恰可以利用检查间隔这一关键限制，即在此检测间隔之内完成攻击并恢复攻击前的Hypervisor状态，仿佛没有攻击过一样。这类攻击称为擦洗攻击，HyperSentry利用IPMI技术构建的检测通道使得攻击者无法预测完整性保护机制的检测间隔，这种方法在一定程度上缓解了擦洗攻击的威胁。但是，还存在一种攻击称为瞬态攻击[39]，它属于擦洗攻击的变种，能在极其短的时间内完成攻击。现有一些针对非可信Hypervisor的基于事件的完整性检测工作[40-43]，可以很好地解决瞬态攻击的问题。

MGUARD[41]利用FB-DIMM（fully buffered dual in-line memory module）硬件[44]实现了一种基于事件捕获的完整性检测机制。MGUARD的完整性检测包括检查对DRAM（dynamic random access memory）存储器中的内核和关键数据结构的未授权更改。其基本原理是，当内核被编译并加载到内存中，内核控制数据（例如系统调用表）往往是静态的，对内核控制数据的任何动态修改都被视为恶意。MGUARD通过检查捕获的DRAM页面状态和DRAM页面数据来实现检测。此外，FB-DIMM中包括一个串行接口，可以将捕获的数据传输到集中的位置，以进一步详细分析捕获的数据来检测攻击的存在。MGUARD在系统启动时就连续地监视任何对物理DRAM存储器的访问。利用FB-DIMM硬件，MGUARD透明地对系统进行完整性检测，除了物理攻击以外，它没有其他的攻击面。

Vigilare[42]提出了一种基于事件监听的完整性检测机制。其完整性监控系统构建在位于主机系统外部的单独硬件的独立系统中，它监听主机系统的总线上的流量以监视主机系统的操作。Vigilare可以对几乎所有系统事件的流量进行安全监控，因为I/O设备、内存和处理器之间的所有处理器指令和数据传输都必须通过系统总线。并且Vigilare本身完全独立于主机系统，能够抵御来自主机中的任何潜在危害或攻击。具体来说，Vigilare系统构建在基于ARM的SoC（system on a chip）上运行的Linux内核中。它主要由两部分组成：Snooper和Verifier。Snooper是一个硬件组件，它收集流量并将其传输到Verifier。Verifier是一个精简的计算机系统，经过优化可以分析数据，以确定主机系统的完整性。因为Vigilare的系统不依赖于主机系统，所以主机系统的完整性不会影响Vigilare系统的完整性，并且主机系统无法以任何方式访问Vigilare系统的内存。

ED-monitor[43]构建了与Hypervisor同地址空间的基于事件驱动的Hypervisor完整性检测机制。EDmonitor的基于事件驱动方法与Vigilare基于事件监听的方法本质上是一样的，但是实现方法上有所区别。Vigilare是基于监听总线上的事件来判断是否有破坏完整性的攻击，而ED-monitor是通过在Hypervisor中加入钩子（hook）来触发检测[4]。前者需要独立的硬件系统来保证完整性保护机制本身的安全性，而后者需要依靠特定的软件技术来自我防御。这里特定的软件技术就是ASR（address space randomization）和IPR（instrumentation-based privilege restriction）。ED-monitor将ASR和IPR技术结合来保护其自身的安全。具体来说，ASR是一种用于保护代码和数据免受驻留在同一地址空间中的恶意程序影响的轻量级方法。它使代码和数据随机化，以确保它们的位置在虚拟地址空间中是不可预测的，从而防止恶意程序破坏它们。但是，现有的ASR技术不足以隐藏针对非可信Hypervisor的完整性保护机制，因为恶意的Hypervisor还可以执行特权指令来绕过ASR或者找出保护机制的随机化位置。例如，Hypervisor可以操纵MMU（memory management unit）配置以将Hypervisor的完整性保护机制重新映射到已知地址并借此绕过ASR。为了使基于ASR的保护机制对恶意的Hypervisor有效，ED-monitor限制了Hypervisor直接执行最高权限操作的能力。它利用IPR来消除Hypervisor代码中的所有特权指令，以便限制Hypervisor必须向ED-monitor请求才能去执行特权指令。通过这种方式，ED-monitor可以拦截并验证Hypervisor中的特权操作（特权指令执行、内存管理单元的配置、中断处理等）。另外，为了实现基于事件驱动的检测手段，ED-monitor在发生指定的Hypervisor事件时调用完整性检测程序。ED-monitor利用hook捕获指定的Hypervisor事件。这些hook可以是插入Hypervisor代码中任意位置的代码hook（即跳转指令），或是调用表中的数据hook。当Hypervisor的执行到达hook时，hook便会将控制流传输到EDmonitor来触发完整性检测。

3.3 基于远程验证的检测

Pioneer[45]提出了一个在不可信系统中构建远程验证可执行文件完整性的方法，并且其不需要特定的硬件或者是软件技术来支持。通过Pioneer可以实现基于软件的远程代码验证。其允许验证者从一个可信实体出发，验证在另一个非可信实体上运行的软件堆栈的完整性。验证者和被验证平台通常是不同的物理计算设备。被验证平台上的验证代理对平台的软件堆栈进行完整性测量，并将其测量结果发送给验证者。一方面，Pioneer在不可信系统中动态建立可信计算库，称为动态信任基。动态信任基中包含的所有代码都可保证未被修改。动态信任基一旦建立，它就会测量可执行文件的完整性。可执行文件将在动态信任基的执行环境中执行。另一方面，验证者的代码由三部分组成：校验和代码、哈希函数和发送函数。校验和代码计算整个验证函数的校验和，其需要在可屏蔽中断的最高权限级别执行，因此Pioneer需要最高执行权限。Pioneer使用哈希函数（secure Hash algorithm 1，SHA-1）来进行对可执行文件的完整性测量。发送函数通过通信链路将校验和结果与完整性测量结果返回给调度程序。在验证过程中，验证者使用轮询-响应协议来获得不可信平台上可验证代码执行的保证。该协议有两个步骤：首先，调度程序获得在不受信任的平台上存在动态信任基的保证；其次，调度程序使用动态信任基来获得可验证代码执行的保证。

Pioneer提出的远程验证方法可以用来保护Hypervisor的完整性检测机制的安全，即Pioneer可以用来对完整性检测机制本身的完整性进行实时验证。进一步的，Pioneer还可以用作构建任意安全应用程序的基本原语。

3.4 小结

在Hypervisor的完整性检测机制中，本章分别分析了基于快照、基于事件和基于远程验证的三种构建方法。基于快照的完整性检测相较于基于事件更为通用和直接，但是其安全性较弱。因为快照的捕获需要时间驱动，这就容易留下攻击窗口，例如擦洗攻击和瞬时攻击。基于事件的完整性检测避免了留下时间窗口，更为可靠和安全，但是其对事件的针对性较强，实现方式也更为复杂，因为保护机制需要先识别Hypervisor中的特定事件才能触发监听。基于远程验证的完整性检测则是通过建立动态的可信来触发完整性检测。这种方法在实现上比较灵活，可以作为任意安全程序的构建基础。但在安全性方面，其需要依靠一个可信的主机来保证验证结果的可靠性，因此可信主机需要避免被攻击。在构建上述完整性检测机制的过程中，首先，依靠软件的方式在现实中比起依赖于特殊硬件更为实际和通用，例如ED-monitor中的ASR和IPR只需安装并开启即可。其次，特殊硬件的选择要注意其本身的限制，避免引入新的威胁，例如本章所提的HyperSentry中的SMM和Copilot中的PCI设备分别存在的问题。

4 Hypervisor防御机制

第3章分析了针对非可信Hypervisor的完整性检测方法，采用检测的手段有一个局限性，即它是属于被动防御，不能预防攻击的出现。本章将梳理针对非可信Hypervisor的主动防御工作，即旨在建立可信的Hypervisor。其中包括针对Hypervisor的控制流、指令仿真以及精简TCB的防御机制。

4.1 针对Hypervisor控制流的防御

Hypersafe[46]构造了旨在保证Hypervisor的运行时控制流完整性的保护机制。运行时的控制流完整性包括静态控制流和动态控制流的完整性，其中静态控制流的完整性由Hypervisor的代码和静态控制数据决定，而动态控制流的完整性由运行时的动态控制数据决定。Hypersafe使用不可旁路的内存锁定技术和受限制的指针索引技术来构建防御机制，使得攻击者无法对Hypervisor的控制流的完整性作出破坏操作。具体来说，不可旁路的内存锁定技术保证了Hypervisor的代码和静态控制数据的安全，它本质上是基于x86系统的内存保护机制实现的，即对页表的W⊕X位设置写保护。而为了对页表进行正常的更新操作，Hypersafe利用WP位的硬件功能（即CPU控制寄存器CR0中的写保护位）构造了一种安全的方法来临时绕过写保护，并且这种绕过的方法不会被恶意滥用。受限制的指针索引技术保证了Hypervisor运行时执行路径符合控制流完整性，即保护动态控制数据的安全。它将每个动态控制数据替换为目标表的受限索引。目标表包含Hypervisor的控制流程图允许的所有间接控制转移指令的合法位置。基于目标表，Hypersafe可以替换Hypervisor中所有运行时的动态控制数据。

4.2 针对Hypervisor指令仿真的防御

FWinst[47]针对Hypervisor的指令仿真进行了保护工作。理想情况下，Hypervisor只需要仿真指令集的小部分。但是，在x86架构上，可能需要Hypervisor仿真大多数指令[48-49]，包括仿真以下五方面中除敏感指令外的其他指令：端口I/O、内存映射I/O、影子页表、实模式、迁移。仿真大多数x86指令很复杂，且容易出错。x86仿真器中存在很多漏洞，例如CVE2016-9756、CVE2017-2584、CVE2015-0239和CVE2017-2583[23]。另外，文献[48]证明了任何指令都可以被强制模仿，这种新的攻击媒介允许攻击者有机会利用任何指令中的漏洞实施攻击。

FWinst通过限制和缩小Hypervisor指令仿真的有效攻击面来防御针对指令仿真的攻击。要仿真的合法指令子集取决于调用仿真器的仿真上下文。如果仿真器仅接受每个上下文中的合法指令集，则针对指令的攻击面就会缩小，因为攻击者无法利用当前上下文中不合法的指令中的漏洞。具体来说，FWinst识别五个上下文：端口I/O上下文、内存映射I/O上下文、影子页表上下文、实模式上下文和迁移上下文。并且给出每个上下文的合法指令的列表。为了缩小攻击面，FWinst使用Hypervisor的配置确定哪个上下文有效。当调用Hypervisor来仿真指令时，FWinst会检查当前上下文是否有效。如果FWinst认为当前上下文无效，则不会允许任何指令的仿真，反之则将合法指令传递给仿真器。

FWinst针对指令仿真中的漏洞和攻击进行了一定的限制和防御，但是FWinst目前的工作只针对Linux4.8版本中的KVM，在其他虚拟化技术中是否有效还有待验证。

4.3 构建Hypervisor的精简TCB

Hypervisor是具有广泛攻击面的大型代码库，本文引言中已经提到了这一点。在Hypervisor代码库中，其设计和实现的组件相当复杂，包括复杂的内存虚拟化和客户虚拟机的指令仿真等。这些组件占据其代码库的一半，并且通常是各种可利用漏洞的存在之处。在4.1节和4.2节中提到的Hypersafe和FWinst都是有针对性地对Hypervisor构建防御，但Hypervisor的庞大攻击面这一特性依然存在。根据TCB的可验证原理，更小的代码量通常意味着更可信[50]。因此，有一些研究工作[51-58]针对如何重构Hypervisor，实现既能保留其功能，又能精简其代码量的目的。精简后的Hypervisor便可以是TCB的一部分，并且其代码的正确性易被验证。验证Hypervisor精简TCB的方法有很多，例如seL4[59]和Verve[60]。其中，seL4提供了验证微内核是否存在特定类型的软件漏洞的方法，Verve可以用来验证软件堆栈中Hypervisor的每条指令的类型和内存安全。另外，文献[61]提出了一种快速验证Hypervisor可扩展部分安全性的方法，也可以用来提高精简Hypervisor在功能扩展时的安全。下面举例梳理重构Hypervisor的研究工作。

NOVA[54]借助微内核的思想将Hypervisor的功能细粒度地分解为micro-Hypervisor、根分区管理器、用户层的Hypervisor、设备驱动程序和其他系统服务设备。其中micro-Hypervisor运行在CPU的最高权限，而其余功能模块都运行在用户层。NOVA遵循最小权限原则，它实现的micro-Hypervisor作为TCB，其代码量要比原本的Hypervisor少一个数量级。但NOVA存在的一个问题是，客户虚拟机某些正常功能可能涉及到很多CPU模式的切换，造成性能损失。

Dichotomy[58]基于Hypervisor即服务的思想，将传统的Hypervisor分为hyperplexor和featurevisor两部分。其中hyperplexor为核心部分，它是一个小型、安全且稳定的Hypervisor，仅用于管理物理硬件的调度和为featurevisor提供支持。而featurevisor是一种轻度修改的Hypervisor，它在用户层运行，即在hyperplexor之上运行，负责面向客户虚拟机的具体服务和管理。每个客户虚拟机可以根据所需的服务分配不同的featurevisor。另外，Dichotomy还提出了短暂虚拟化的概念，即featurevisor可以灵活地暂时将客户虚拟机的管理转移给hyperplexor，以此减少上下层切换的开销。

与NOVA和Dichotomy类似的，DeHype[53]也将Hypervisor分解。它将Hypervisor的特权指令代码的最小子集定义为OS（operating systems）扩展，称为HypeLet，而将其他的大多数Hypervisor代码放在用户模式下执行。当用户模式下的Hypervisor发出特权指令请求时，它需要通过系统调用方式进入特权模式执行HypeLet中的相关指令。用户模式运行的Hypervisor基本上作为用户库运行，提供与HypeLet交互的必要功能。而HypeLet是当前虚拟机管理程序代码库添加的唯一特权组件。DeHype是针对KVM的研究工作，其原型中HypeLet只包含两万多代码行并且仅定义了10个系统调用，但其是否适用于其他虚拟化方案还有待验证。

NoHype[51]与上述工作的思想不同，它认为Hypervisor并不是虚拟化管理工作必不可少的一部分，因此它直接将客户虚拟机之间的物理资源进行预分配和隔离，而不再需要Hypervisor。具体来说，它依靠硬件的虚拟化特性[62]，严格地划分客户虚拟机之间的物理资源，使得客户虚拟机只需要在启动时与一个临时的Hypervisor交互，而在其运行期间不再需要与Hypervisor交互。NoHype去掉了传统意义上的Hypervisor管理层，因此大大减少了其TCB的存在。但是，NoHype对没有硬件支持物理隔离的环境并不友好，另外其仍然需要对客户虚拟机的操作系统内核进行微小修改，增加了开发难度。

上述研究对Hypervisor进行重新设计采用的方法不尽相同，但却殊途同归。不同方法有各自的优势和劣势，研究人员需要根据不同的场景选择不同的方式。而如何构建一个完备而又通用的方法，使得Hypervisor的TCB既精简且易于验证，同时性能减损，是留给研究人员继续攻克的问题。

4.4 小结

在Hypervisor的防御机制中，本章梳理了针对控制流、指令仿真和精简TCB的构建方法。三者比较而言，一方面，前两者相比于精简TCB的构建更为实用，可直接被现有实际的Hypervisor所采用，而4.3节所提的精简TCB的方法需要对原有Hypervisor进行不同程度的重构。简单直接的重构需要划分Hypervisor的功能模块，例如NOVA，而复杂的重构需要直接去除Hypervisor层，例如NoHype。另一方面，构建Hypervisor的精简TCB在安全性方面更为全面和可靠。Hypersafe和FWinst都是有侧重的防御工作，两者需要结合才能提供较全面的防御。而精简TCB的构建因为其本身安全性的易于验证，可以提供更直接的全面防御。

5 针对非可信Hypervisor的虚拟机隔离机制

第3、第4章分别分析了Hypervisor的完整性检测机制和防御机制的研究工作。这些工作也都各有侧重和优缺点，因此在实际中可能还是会有绕过检测和防御的攻击方法。本章将梳理致力于隔离恶意Hypervisor和客户虚拟机的研究工作。其中包括基于嵌套虚拟化技术和基于加密技术的隔离机制。

5.1 基于嵌套虚拟化

CloudVisor[63]致力于限制和隔离任何非可信的Hypervisor对上层客户虚拟机的资源（CPU、内存和I/O设备）的非法操作。它利用嵌套虚拟化技术[64-65]，将Hypervisor置于Ring1权限，而其本身运行在Ring0权限，如此一来CloudVisor中保护操作的执行便对任何恶意的Hypervisor来说都是透明的，并且其拥有更高的权限。具体来说，在CPU方面，CloudVisor为Hypervisor和客户虚拟机之间所有控制转移进行必要的转换和保护。而在内存方面，CloudVisor跟踪Hypervisor维护的每个页和每个页表的所有权（即扩展页表），并且不允许Hypervisor直接覆盖扩展页表，它会在Hypervisor页表的更新时检查页面的所有权是否与页表的所有权匹配，如果不匹配则加密页面内容。最后在I/O设备方面，为了保护虚拟磁盘，CloudVisor在客户虚拟机的每次磁盘I/O访问期间透明地加密和解密数据。它使用信息摘要哈希算法（message-digest algorithm，MD5）和Merkle树[66]来确保磁盘数据的完整性。另外，它通过维护每个客户虚拟机的I/O访问权限表来防止来自Hypervisor的DMA攻击。

5.2 基于加密技术

利用加密的手段来保护客户虚拟机免受非可信Hypervisor的入侵是一种有效的办法，因为恶意Hypervisor无法对加密的数据进行攻击。本节将分别分析基于软件和基于硬件的加密技术。

5.2.1 基于软件的加密

文献[67]提出了由AISE（address independent seed encryption）内存加密算法和BMT（Bonsai Merkle tree）哈希树算法组成的软件加密技术。AISE+BMT的加密方法需要信任CPU，因为它依靠CPU运行时对密文元数据的处理逻辑来实现加密。

在AISE中，处理器不会直接加密数据块（Cache数据块），而是通过加密数据块的种子（seed）来产生一个伪随机数，然后将这个伪随机数与数据块的明文进行异或后产生数据块的密文。数据块的seed是地址独立的，并且每加密一次都会发生改变，其具体由三部分组成：LPID（logical per-page ID）、计数器和偏移。LPID对于每个物理内存页面都是唯一的。LPID的值在初始化时分配，与页面地址无关。计数器和页面偏移量是针对每个Cache数据块的值。当计数器溢出，相应的页面将会被分配新的LPID并重新加密。BMT哈希树用来对AISE中的Cache数据块的seed进行完整性保护，它会将seed的密文的哈希值更新到一棵哈希树中，该哈希树的根节点保存在CPU中。当处理器将seed的密文从内存加载到Cache时，处理器会先从BMT获取其对应的哈希值，然后将其与当前加载的密文数据计算所得的哈希值进行比较，以确定当前获取的seed的完整性。

在性能方面，AISE+BMT的加密方法引入的开销较低。首先，加密和解密操作是针对数据的seed而不是具体的数据，因此可以与存储器的加载和存储操作并行化来提升性能。其次，由于seed中的计数器很小，因此其缓存的命中率非常高。再者，BMT可以很大程度上减少内存和缓存中哈希的大小。

SecureME[68]和HyperCoffer[69]都是运用了AISE+BMT的方法来加密客户虚拟机数据的保护机制，但是两者适用的场景有所不同。SecureME利用了Hypervisor来实现其保护机制，并将Hypervisor列为了TCB的一部分，因此它的保护机制无法隔离来自恶意Hypervisor的攻击。而HyperCoffer只信任客户虚拟机的OS内核。在HyperCoffer中，客户虚拟机中的所有数据都受到保护，包括CPU上下文中的数据、Cache数据、内存和I/O数据。因此，在面对非可信Hypervisor时，HyperCoffer能真正对客户虚拟机的安全进行基于加密的隔离保护。

5.2.2 基于硬件的加密

Fidelius[70]使用其改进的AMD的SEV（secure encrypted virtualization）技术[71]实现了对客户虚拟机数据的加密和保护。与5.2.1小节中AISE+BMT的软件加密方法的比较而言，Fidelius使用的SEV更具优势。首先，SEV是在主流处理器的固件中实现的，硬件的支持使其更可靠，并且它可以在实际运用中得到更广泛的支持。其次，SEV授予客户虚拟机以页粒度方式控制加密粒度的能力，因此它更灵活，可以适应更复杂的加密场景。

SEV是集成在AMD-V技术中的内存加密技术，它专门针对虚拟化的场景。SEV实现在独立的SoC固件中，并与容纳在CPU中的存储器控制器协同工作。所有密钥都由独立的安全处理器管理，并安装到内存控制器中，以支持片上的AES（advanced encryption standard）加密引擎。但是，在面向非可信Hypervisor时，只使用SEV的保护并不充分[72-73]。首先，SEV未加密VMCB（virtual machine control block），因此其完整性在当前SEV中不受保护。其次，物理内存映射仍由Hypervisor控制，即使启用了SEV的一种特殊模式SEV-ES（secure encrypted virtualizationencrypted state），暴露物理页表可能导致客户虚拟机受到攻击威胁。再者，启用密钥共享的客户虚拟机无法阻止Hypervisor将密钥暴露给其他恶意的客户虚拟机。最后，SEV不支持DMA在加密数据上操作，因此客户虚拟机的I/O数据是没有加密的。

为了既有效地利用SEV加密技术，又能避免其在面对非可信Hypervisor时暴露的缺陷，Fidelius结合SEV技术进行了如下改进。首先，Fidelius分离Hypervisor对硬件资源的管理功能与提供服务功能。Hypervisor仍然为客户虚拟机提供服务，但是具体的资源管理交由Fidelius验证和管理。这样就避免了恶意Hypervisor对VMCB和SEV密钥等资源的滥用。其次，构造针对物理页表的不可旁路的内存隔离保护。Fidelius利用文献[74-75]中的方法获得与Hypervisor相同的执行权限，并通过4.1节中Hypersafe的不可旁路的内存锁定将物理页表与Hypervisor保持分离。Hypervisor对物理页表只读，而Fidelius参与正常的物理页表操作并基于页面信息表来验证物理页表的更新。最后，通过改进SEV的发送和接收接口，Fidelius可以加密客户虚拟机的磁盘I/O数据。

但是，Fidelius信任客户虚拟机内核，无法隔离来自客户虚拟机内核的攻击。如果需要在完全不可信的环境中只保护客户虚拟机的应用程序，那么真正完全有效的方法是既不信任Hypervisor，也不信任客户虚拟机内核，做到只针对应用程序的加密级别。Intel的SGX（software guard extensions）技术[76]就可以用来实现此场景的需求，例如Haven[77]对SGX的运用。文献[78]将业界的Intel的SGX和AMD的SEV进行了详细的对比。SGX技术拥有和SEV一样的来自主流处理器的广泛支持的特点。但是不同于SEV，SGX技术无法用来加密整个虚拟机，它只支持应用层面的加密。利用SGX技术可以将受保护的应用程序与外界任意软件隔离，构建仅和CPU之间可信的通道。

5.3 小结

在针对非可信Hypervisor的虚拟机隔离机制中，本章梳理了基于嵌套虚拟化和基于加密技术的构建方法。利用嵌套虚拟化可以从执行权限方面隔离Hypervisor，而基于软件和基于硬件的加密技术将客户虚拟机的数据安全地与Hypervisor隔离。本质上它们都旨在使得恶意的Hypervisor无法肆意地破坏客户虚拟机，从而保护了客户虚拟机的安全。两者比较而言，嵌套虚拟化对原有虚拟化系统的改动比较大，不过这种方法的隔离构建更为有效和彻底，例如CloudVisor将Hypervisor置于Ring1权限，全面地限制了Hypervisor作恶的能力。而加密技术在实现上更为简单，例如Fidelius方法可以直接在现有支持AMD的SEV技术的机器中实现。另外，在加密技术中，具体加密方法的选择与运用，还需要研究者结合加密技术支持情况和受保护的对象是虚拟机或是应用程序等条件来权衡。

6 未来研究趋势

性能和安全，在系统领域一直是互相影响的两方面。一方面，安全机制的存在不可避免地会引入额外的开销，导致性能降低；另一方面，在追求极致性能的研究路上又可能留下安全漏洞。现有工作[11，79]同时考虑了系统安全性和效率，分别针对客户虚拟机在安全性方面和隔离性方面存在的问题，构建了相应的保护机制，在保留高性能的同时提高了多租户云平台的可靠性。在未来面向云平台非可信Hypervisor的保护机制研究趋势中，结合性能和安全的考虑，本章给出以下三方面的探讨。

首先，可以构建基于硬件技术的保护机制。纵观虚拟化的发展，早先的虚拟化技术是没有硬件特性的技术支持的，因此其性能并不乐观。在Intel和AMD分别推出Intel-VT和AMD-V后，处理器对虚拟化的支持极大改善了虚拟化的性能。同样的，在安全方面，Intel的SGX和AMD的SEV也都从硬件层面对虚拟化技术提供保护的支持。一般来说，基于硬件实现的保护机制在性能方面要优于纯软件实现保护机制。因此，利用硬件技术来构建保护机制将会一直是一个重要的研究方向。特定硬件能提供的特性也不仅仅在于性能，更有独立于主机系统或执行模式等安全特性，即硬件本身可以成为TCB的一部分。本文所提到的完整性检测机制、防御机制和隔离机制的研究工作中，也都有利用硬件技术构造保护机制的影子。但是，在这个方向中也存在着几点重要考虑因素。一是硬件本身也可能存在漏洞和异常；二是其通用程度。前者是基于硬件的保护机制是否能正确运作的基础，而后者决定了其是否能够在实际中更广泛地运用。

其次，可以构建分布式保护机制来动态地建立安全。在多租户云平台中，恶意的Hypervisor往往只局限于少数服务器中。攻击者对云平台的布局一般是未知的，因此攻击在各个主机之间是独立发生的。同时攻击多个服务器并使它们作恶，其难度要比只攻击单台服务器大很多。因此，可以基于大多数云平台服务器安全的前提，来构建面向云平台非可信Hypervisor的保护机制，以保护少数非可信的云平台服务器。分布式保护机制本质上可以借鉴分布式共识协议在很多应用场景的核心思想。最典型的便是区块链技术中，联盟链里用到的解决拜占庭问题的PBFT（practical Byzantine fault tolerance）共识协议[80]。利用多数派安全的特征，集群可以动态地从其中找出主可信节点，并且可以不断更换主可信节点来进一步提高安全性。当然，分布式的引入可能会带来性能消耗，因此性能止损是构建分布式保护机制的关键挑战之一。

再者，可以构建基于机器学习的保护机制。近年来，人工智能等新兴应用领域在多租户云平台的底层基础支持下，渗入到了各行各业中，也被运用得越来越广泛。但反过来，人工智能中的技术，例如机器学习，其本身处理数据的方式也能够促进云平台的安全构建。机器学习可以用来分析现有攻击的特征，包括其对虚拟化系统带来的硬件和软件上影响的特征信息。在对这些特征信息捕获、分析和建模后，构建的保护机制便可以高效地进行检测、防御和隔离工作，甚至可以预知潜在攻击的威胁。举例来说，硬件性能计数器和系统日志是构建保护机制很好的信息来源和载体。一方面，硬件性能计数器可以用来分析恶意攻击程序运行时触发的硬件事件，包括Cache、分支预测和CPU周期等方面的硬件事件。现有研究工作[81-83]基于硬件性能计数器中的信息，运用机器学习算法实现了对侧信道攻击的实时检测。研究工作[84]也利用硬件性能计数器中的信息构建了针对内核控制流攻击的检测机制。另一方面，系统日志中记录了系统运行中所有重要的状态和事件，是理解系统是否正确运行的宝贵资源。并且，系统日志非常像自然语言，因为其是由遵循严格逻辑和控制流的程序生成的。研究工作[85]即基于大量系统日志信息，构建了检测系统异常和攻击的机器学习模型。目前，机器学习在系统安全方面的研究工作尚且不多，这也是留给研究人员的很好机会。

7 总结

Hypervisor在虚拟化软件层中扮演着至关重要的角色，但它和其他软件层一样受到漏洞和攻击的威胁。为此，需要构建面向云平台非可信Hypervisor的保护机制来提高虚拟化安全性。保护机制的构建可以从完整性检测、主动防御和虚拟机隔离机制这三方面出发。在完整性检测方面，检测机制需正确捕获Hypervisor运行的异常。其实现方式直接决定了检测局限性所在。构建完备的检测机制需要结合检测目标，选择合适的检测手段，确保检测的有效性和检测机制本身的安全性。在主动防御方面，防御机制旨在提高Hypervisor运行的安全性。构建有效的防御机制需要结合Hypervisor的攻击面，充分考虑潜在的威胁，并致力于避免防御机制被绕过和攻击。在虚拟机隔离方面，隔离机制应针对非可信Hypervisor，结合具体的隔离目标和现有的隔离技术，构建恶意攻击无法入侵的屏障。最后，未来的研究工作可以从基于硬件保护、机器学习和分布式保护这三方面出发，综合考虑性能与安全，构建实用的面向云平台非可信Hypervisor的保护机制。