CloudVisor译稿

   此文为sosp11会议上的《CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization》的译文，译得很笨拙，建议英文较好的同学还是去看原版。

   以下为译文：

    CloudVisor:使用嵌套的虚拟化技术改进多租赁云平台中的虚拟机保护

摘要
   通常以虚拟机的形式出租资源的多租户云，这几年已经从商业上可获得了。不幸的是，由于采用了商品虚拟化设施，特定多租户云中的软件栈会变成非常的庞大和复杂，所以有可能被包括云操作员之类的攻击者利用，导致安全敏感的数据被泄露。
   在这个论文中，我们提出了一个透明的，向下兼容的方法，来保证客户们在商品虚拟化设施中的虚拟机的隐私和完整，甚至面对整个虚拟机监视程序（VMM）和虚拟机管理系统的妥协。我们方法的核心是将资源管理从虚拟层的安全保护中分离。一个小的安全监控器被放置在商品VMM之下，使用嵌套的虚拟化技术，提供对宿主虚拟机的保护。因此，我们的方法允许虚拟化的软件（如VMM、管理虚拟机和工具等）去处理复杂的云租赁虚拟机管理任务，并且不破坏虚拟机中用户数据的安全。
   我们已经通过利用虚拟化的商业硬件支持，完成了一个原型。这个原型系统被称为CloudVisor，它仅仅由5.5k LOC组成，能够使用多个Linux和windows或为guest操作系统来支持Xen VMM。性能评估展示了CloudVisor引发了轻微的IO密集性应用的速度减慢，和其他应用非常小的速度减慢。
目录和课题描述
操作系统：安全和保护
整体术语
设计、安全和性能
关键词
多租赁云，虚拟机安全，嵌套虚拟
1. 引言
   多租赁云提供了弹性可伸缩的计算资源，将用户从类似于配置、管理、维护IT资源这样的笨重任务中解脱出来。举个例子，亚马逊的弹性计算云平台[6]为大量的使用情景（包括应用集群、内容发放、电子商务、网络集群[6]），以基于Xen虚拟机的形式提供了灵活的、可调整大小的计算资源。
   然而，多租赁云也重新定义了计算的威胁模型，提出了新的安全挑战：如果客户的敏感数据被放置到第三方的多租赁云平台上，安全将会成为一个核心的担忧。不幸的是，当前的多租赁云平台采取了商品虚拟设施仅能对于租户的敏感数据安全提供有限的保证。许多云提供者对于用户的内容只提供“你自己的安全”保证[8]。
   当前云缺乏安全保证主要有2个原因：首先，许多云平台为了减轻部署压力，节省开支，总是采取现成的虚拟设施。然而，这也导致了从虚拟栈中租用的虚拟机的安全性下降的可能性。这是因为，商品虚拟设施的可信计算基（TCB，包括虚拟机监视器VMM和虚拟机管理）有着数百万LOC的规模。所以，这个栈容易被侵入和越狱。举个例子，到2010年12月份为止，VMware和Xen已经分别有35和32个被CVE[2]报道的缺陷。
   第二个原因，竞争公司的租户，或者云操作者自身都会是潜在的攻击者，有可能暗地里未经允许访问未加密的敏感数据。举个例子，一个评估云计算风险的报道表明，云计算的一个最大的挑战就是“在它的设施中无形地访问未加密的数据”[26]，谷歌最近也解雇了两名违背用户隐私的雇员[63]。
   为了改善这个问题，之前的努力已经尝试着去完全移除虚拟层[31]，建造一个新的类似于VMM的微核[60]，或者保护VMM的控制流完整性[68]。然而，这样的手段大多数只能保护VMMs避免来自于恶意来客VM的攻击，没有考虑到避免具有管理工具和VM控制权的操作员篡改、偷取用户的私密数据，特别是外部存储设备如虚拟磁盘。此外，他们都要求修改VMM的核心部分[68]，甚至于VMM的完全重构[31,60]，这会给应用到商业成功的虚拟云上造成明显的障碍。
   在这个论文中，我们提出了一个替代性的方法来保护多租赁云平台上的租用虚拟机。我们的方法使用嵌套虚拟的概念[23,13]，引进了一个称为CloudVisor的小型安全监控器放置在大多不需修改的商品VMM下面。不像先前方法中为了多层的虚拟，把虚拟功能合并进商业VMM中[13]，CloudVisor将嵌套虚拟的功能和商品VMM解耦，让它本身只支持一个VMM，所以十分轻量化。
   CloudVisor负责保护虚拟机上资源的隐私和完整性，此时VMM仍然能够负责虚拟机之上的资源分配和管理。这样一个对于安全保护和资源管理间的分割允许CloudVisor和VMM被独立设计、验证和演化。因为对于VM资源的基本保护逻辑已经完全固定了，所以CloudVisor能够足够得小，来验证它的安全属性（比如，使用正式的验证方法[34]）。
   CloudVisor提出了VMM和它的guest VM之间，为了隐私保护和完整性检查的交互。为了保护VM中的内存，CloudVisor在从VMM和其它VM的未认证的映射上，追踪VM的内存页和加密页内容。使用整个虚拟磁盘的加密，磁盘IO数据的隐私被保护起来：在VMM和guest VM之间的磁盘IO被拦截，在磁盘写的时候被加密，在磁盘读的时候被解密。为了防止篡改加密页和持久化存储数据，CloudVisor使用MD5哈希算法和Merkle树[42]在解密中进行磁盘数据的完整性检查。
   在软件栈中，只有CloudVisor在可信计算基中，而其他的软件，比如VMM和management VM都不被信任。CloudVisor的完整性能够使用认证启动（Authenticated Boot）（由受信任的平台模块（TPM）提供）被确保[66]。为了简化CloudVisor的开发和部署，我们利用Intel Trusted eXecution Technology（TXT）[27]，它允许在平台被初始化后开启和测量CloudVisor。通过这样的方式，CloudVisor从大多数硬件初始化的工作中摆脱出来。
   我们已经设计并且完成了一个原型系统，这个系统基于商业可获得的虚拟化的硬件支撑，包括ISA虚拟化（比如VT-x[45]），MMU虚拟化（比如EPT），IO虚拟化（比如IOMMU[5]，SR-IOV[18]）和动态平台测量（比如Intel Trusted eXecution Technology[27]）。CloudVisor包含大约5.5K LOC，能够支持运行大多数不被修改（一个可选的补丁，大概100LOC，用来减少不必要的VM退出，跟Turtles[13]的优化相似）的使用多个Linux和Windows作为guest OS的Xen VMM。我们的性能评估使用了一定范围的基准，评估显示CloudVisor会导致IO密集应用轻微的速度减慢（范围从4.5%到54.5%之内），并且对于其他应用非常小的速度减慢（范围从0.1%到16.8%），与vanilla Xen相比。
   总的来说，这篇论文做出了如下的贡献：
λ 使用嵌套虚拟技术，从虚拟的资源管理中分离出安全保护的案例，这是和商业的虚拟栈向下兼容的，并且显著地减少了TCB的大小，从百万lines of code到只有几千lines of code.
λ 一个保护的技术集，提供了整个VM的保护，阻止攻击者即使他拥有VMM和management VM的全部控制权。
λ 一个原型实现，利用已存在的虚拟化的硬件支持，这个实现表现出低性能开销。
  剩下的论文是这样被组织的。下一个部分说明了虚拟化的多租赁云的风险，描述了CloudVisor的风险模型。部分3首先讨论了我们的设计目标，然后描述了我们的方法和CloudVisor的总体架构。Section4,5,5描述了CloudVisor是怎样保护CPU的状态，内存和硬盘存储。部分7讨论了实现的问题和状态。部分8表现了性能评估结果。部分9讨论了现在的限制和可能的未来工作。最后，部分10将CloudVisor和其他文献关联在一起，部分11总结这篇论文。
2. 动力和风险模型
这个部分首先描述虚拟的多租赁云的攻击面，然后讨论CloudVisor下的风险模型。
2.1虚拟层的攻击面

   虚拟化[24]和云计算有一个良好的保证，因为它在服务器合并、能源节约和减轻管理上的特性。许多云提供者已经使用了虚拟化，在它的云设施和以虚拟机的形式向用户租赁资源（一种“Infrastructure as a Service”云的形式，比如Amazon EC2[6], ,Eucalyptus [46], FlexiScale [20] Nim- bus [64] and RackSpace Cloud [62]。
   虚拟化对于云的安全和可信赖性有好的[16]和坏的[22]影响。在好的方面，许多开箱即用的安全技术现在可以在虚拟层被完成，让它们对于VM的攻击更加有弹性。在坏的方面，商品虚拟软件栈经常会很庞大，而且它们大多数都在可信计算基中。
  图1描述了典型的（无主机的）虚拟化架构和多租赁云的攻击面。因为租赁虚拟机经常通过过于强大的特权接口到VMM，被管理工具管理，它们能够被VMM和management VM中的管理工具任意地检查并且篡改。从原则上说，操作员应该仅仅被授予最小的权限并且不能够修改租户VM。然而，因为总是很困难去精确地定义恰当的权限[35]，所以实际上操作员经常能够得到比他们应该有的多得多的权限。后果就是，不恰当的能够获取用户数据的权限能够将用户数据至于危险的境地(如攻击面3)。举个例子，一个云操作员也许会利用内部的维护接口来转储一个虚拟机的内存镜像来进行脱机分析，暗地里移动/克隆一个虚拟机到一个隐蔽处来重放，甚至拷贝走所有虚拟机的虚拟磁盘。
   更糟糕的是，因为越来越多的功能被整合进虚拟层，比如实时迁移、安全监测和快照，TCB（包括VMM和management VM和管理工具）无论从大小还是复杂度都呈爆炸级的增长。举个例子，Xen的TCB大小，包括VMM，mamagement VM和管理工具已经在每次的主要发布中稳固地增长，正如我们在表格1中看到的。一个敌对者能够通过开发内部安全弱点（攻击面1和2）来增加对虚拟层的攻击。这里，我们故意分开内部（面3）和外部攻击（面1和2），因为在典型的数据中心，经常会有物理分割开的网络对于内部操作员和外部使用者。经常，内部的攻击会更强大并且容易增加，如果一个云操作员存在恶意的话。

   然而，大多数先前的努力旨在保护不受面1和面2的攻击，通过保卫[60,68]或者移除[31]虚拟层，而不是防御利用面3来攻击的攻击者。举个例子，他们不能抵御利用合法的维护操作，比如转储、克隆、移动虚拟机或者虚拟磁盘，进行的攻击。此外，它们需要对云软件栈进行重构。为此，为多租赁云平台提供一个方法，来抵御贯穿3个攻击面的攻击（从篡改租户的虚拟机到小的可信任计算基），是很重要的。这促成了CloudVisor的设计和完成。
2.2假设和风险模型
   敌对者：考虑到在一个多租赁云中有多个攻击面，我们要考虑本地的敌对者和远程的敌对者，并且假定他们对VM管理栈（包括商品管理程序，management VM和工具）享有完全的控制权。一个敌对者也许会利用强大的管理接口来识图转储一个租户虚拟机的内存，偷取虚拟机的虚拟磁盘，甚至给虚拟机注入代码。
   假设：我们假设云提供者本身不怀恶意或者没有想篡改、偷取它租户的敏感信息。风险会来源于它的操作员的无意或故意的坏动作[26,63]。所以，我们假设没有内部的物理攻击，比如将探针放到总线中，冻结所有主要内存，读出数据。实际上，典型的以数据为中心总是会对于物理的进入有严格的控制，并且监督照相机来监测和记录这样的进入。然而，因为磁盘存储会被操作员经过虚拟机管理栈或甚至物理维护（如磁盘替代）轻易的进入，我们假定外部磁盘存储不被信任。
   安全保证：CloudVisor的目的是阻止恶意的VM管理栈监测或者修改一个租户的VM状态，这样就能提供VM状态的保密性和完整性，包括CPU状态，内存页和磁盘IO数据。CloudVisor保证所有的来源不从VM本身（如VMM，其他VM等）的进入，如DMA，内存转储和IO数据，只能看到VM数据的加密版本。当非法篡改一个VM的状态时，CloudVisor使用密码学的方法去核实VM数据的完整性，有序性和新鲜性，并且在篡改失败时停止虚拟机。
   一个恶意的VMM不能发起任意的控制转让从VMM到一个租户的VM。替代的是，在VMM和VM之间的所有控制转让只能够通过一个被良好定义的出入口点被完成，这些出入口点由CloudVisor来调停。VMM不能够假冒一个执行上下文来让一个VM在上面运行。实际上，VM的执行上下文在一个控制转移的过程中被CloudVisor安全地保存和恢复。
   凭借着平台测量技术比如Intel Trusted execution Technology 和TPM，CloudVisor使得云租户确信他们的VM正在运行在被CloudVisor被保护的机器上。因此，攻击者不能够改变启动环境或者愚弄一个租户的VM去运行在一个错误的执行模式上，比如para-virtualized模式和一个不同的分页模式，这将会被CloudVisor监测到并且拒绝。
   不安全的目标：因为租户的VM仍然使用VMM和它的managemnet VM和工具所提供的服务，所以CloudVisor不能保证租户VM的可用性和执行正确性。然而，我们相信这对于多租赁云来说并不是一个问题，因为云提供者的主要目标是在特定的服务层协议上提供实用风格的计算资源给用户。提供退化的甚至是错误的服务会很容易被客户发现，并且这样行为不端的提供者或操作者将很快被从市场中赶出。
   CloudVisor不防卫云上的边信道攻击[49]，因为这种攻击难于部署，用很有限的带宽来泄露数据。然而，CloudVisor确实利用了高级的软件特性，类似于在最近的CPU中运用AES（高级加密标准）指令[4]去阻止加密键的泄露[56]。进一步的，许多注重安全的应用比如OpenSSL有内嵌的机制去阻止变信道攻击。
   CloudVisor也没有提供VM和它外部环境交互时的保护。所以，租户的VM安全最终限制在VM本身。比如，一个敌对者也许仍然能够通过利用VM内部的安全缺陷来攻陷VM。这经常能够被缓和，通过利用传统的应用和操作系统的安全增强机制。CloudVisior保证，当敌对者已经控制一个被攻陷的VM或者甚至已经攻陷了管理软件或者VMM，不能够更进一步地破坏CloudVisior提供给在相同机器上的其他VM的安全保护。
3. 目标和方法
   这个部分首先说明CloudVisor的设计目标，然后描述了实现这个目标的方法。最后，我们展现了CloudVisor的总体架构。
3.1设计考虑
   CloudVisor的主要目标是给现有的虚拟化平台下的一整个VM提供透明的安全保护，而且有着最小化的可信计算基。
   整个VM的保护：我们选择VM层次的保护粒度是基于下面三点考虑。首先，许多云平台，如亚马逊EC2选择以VM的形式为租户提供资源（比如, Infrastructure as a Service）。第二，跟那些有着成百上千复杂的精细的语义的API进程和操作系统之间的交互相比，VM有着简单清楚的抽象，VM和VMM之间的交互是被良好定义的。最后，在VM层级的保护对上层的guest OS是透明的。相比之下，在进程层级上提供保护（比如CHAOS[15,14],Overshadow[17]和SP³[71]）总是会和特定类型的操作系统相耦合，并且当被接入其它操作系统时，需要付出很大的代价。
   不侵入Commodity VMMs:设计一个增强安全的方法，以不侵入的方式来与当今的商业可用虚拟栈一起工作是很重要的。所以，CloudVisor应该使得VMM和management software改变最小化。这能够使得CloudVisor与现有的云设施整合和部署的速度加快。进一步说，CloudVisor能够被分开地设计和验证，跟VMM和management software的演化正交。
   最小化的TCB：先前的经验表明越少的代码量越可靠的软件[21,58]。所以，CloudVisor的TCB大小应该最小化，所以CloudVisor能够验证其正确性。比如，最近的官方验证努力[34]已经在一个通用的OS核上展示了它的成功，以8700LOCs。
3.2方法综述
   不像传统的虚拟系统，CloudVisor将VMM和management VM排除在TCB之外。替代的是，CloudVisor执行在机器的最特权模式中，监测VMM和主机VM的执行和交互，这2个运行在相对特权更少的模式中。因为VM的资源主要包含CPU，内存和IO设备，所以CloudVisor被设计用来保护这样的资源（正如在表格2中展示的那样）。

   使用嵌套虚拟的透明介入：为了使CoudVisor与当前的虚拟栈透明，我们使用嵌套虚拟[23,13]去给一个VMM仍然控制VM的所有资源的错觉。为了实现这个目标，CloudVisor干预了对于VMM和它的VM之间的所有控制转移事件（部分4）。在干预过程中，CloudVisor做必要的转化和保护，并且将（虚拟化的）事件转移给VMM来处理。举个例子，在一个中断过程中，依赖于上下文，CloudVisor将会保存通用寄存器，并且只提供必要的给VMM，来限制暴露给VMM的信息。
  基于VM的内存所有权跟踪：为了保护VM的内存不被VMM和management VM监测，CloudVisor干预了从guest物理地址到主机物理地址的地址转换。特别的是，CloudVisor跟踪VMM维持的每个页和每个页表的所有权（比如extended page table, EPT²）（部分5）。CloudVisor不允许VMM直接重写EPT。在拦截对于VMM的页表做的更新时，CloudVisor检测这个页的所有权是否和这个页表的所有权相匹配，如果不相匹配的话，就加密页的内容。
   一个替代性的保护guest VM的内存的方法是multi-shadowing[17]，它既提供了页的加密版本（被VMM看到）和原始版本（被guest VM看到）。然而，这将会对于每个VM需要2个EPT，对于一些页需要2份拷贝，这会导致增加的内存压力。进一步说，VMM有时需要以原始的格式访问一些guest VM的内存，这就需要CloudVisor提供干预和保护（部分5.3）。简单地为VMM提供页的加密版本将会毁坏整个系统。
  通过加密进行的IO保护：CloudVisor现在提供对VM拥有的虚拟磁盘的保护。对于网络设备，因为典型的安全敏感的应用已经使用了加密的数据通道，比如SSL，CloudVisor不对这些设备提供密码学的保护。为了保护虚拟磁盘，CloudVisor在VM使用磁盘IO时透明地加密和解密数据，包括基于端口的IO和direct memory access（DMA）（在部分6中详细说明）。使用MD5哈希算法和Merkle树[42]去做完整性检查，确保磁盘数据的完整性（部分6）。为了防止VM，VMM和management VM遭受DMA攻击，CloudVisor维持了一个每个VM I/0使用许可表（比如，通过操纵IOMMU³），并且只允许DMA存取他们自己的内存区域。
   2：将guest物理地址转换为主机物理地址。
   3：IOMMU在I0设备的一次内存使用中将guest物理IO地址转化为主机物理地址
  Late Launch去减少CloudVisor的复杂度：因为CloudVisor在VMM之下运行，如果它在VMM之前被引导，CloudVisor需要完成许多机器的初始化程序。这将会增加CloudVisor的复杂度和代码基。所以，CloudVisor利用当前的硬件支持来做动态检测[27,9]，并且在这个系统已经完成引导程序后再引导CloudVisor。特别地，当从VMM收到引导CloudVisor的请求时，CloudVisor引导自身，并且处理器将会发起对于CloudVisor的完整性检测，这样就能防止VMM引导一个CloudVisor的恶意版本。这个检测结果将会被云租户使用，作为远程认证的证据。
3.3CloudVisor架构

   图二展示了CloudVisor的总体架构，它是一个在最特权层级上运行的轻量级的安全监测器，而commodity VMM和control VM和guest VM在相对特权更少的模式。CloudVisor强制隔离和保护每个guest VM使用的资源，确保VMM和它的guest VM的隔离性。传统的虚拟化功能，比如资源管理，VM创建和销毁，时序调度仍被VMM来完成。CloudVisor透明地监测VMM和VM是如何使用硬件资源来强制保护和隔离每个guest VM使用的资源。
   图2也描述了云使用者如何使用CloudVisor去安全地部署他们的服务。一个云租户也许首先使用TPM的TCG 认证协议来认证云平台，来知道是否这个平台运行在一个CloudVisor的可知版本之上。然后，租户会发送VM镜像和相应的metadata文件来在云上运行。跟亚马逊的机器镜像[7]相似，镜像使用一个通用的对称密钥加密。公钥将被用来加密对称密钥，并且用户将会发送密文给CloudVisor。CloudVisor控制平台上的私钥，并且使用它来解密镜像进行引导。在VM镜像的metadata文件中，有一些信息（比如哈希表和初始向量）保证VM镜像的完整性，有序性和新鲜性。Metadata也包括这个VM中描述执行模式的信息（比如分页模式）。在VM的启动过程中，CloudVisor将会使用这些信息来确保VM镜像被正确地执行。
4. 使用嵌套虚拟保护控制转移
CloudVisor干预VMM和它的guest VM之间的控制转移。在虚拟化的硬件支持帮助下（比如VTx[45]或者SVM[9]），这样的控制转移在VM出口（从VM转移到VMM）和入口（从VMM转移返回VM）是抽象的。CloudVisor透明地使用嵌套虚拟[23,13]来保护这样的转移，通过虚拟化这样的事件，做必要的安全保护。这个部分首先说明硬件辅助（嵌套的）虚拟化的必要的背景信息，使用Intel的VT-x作为一个例子，然后描述了CloudVisor是如何利用它来保护控制转移。
4.1硬件辅助（嵌套的）虚拟化

   图3的剩下部分展现了硬件辅助虚拟化的总体架构，VMM在主机模式下的哪里运行，和VM在guest模式下的哪里运行。VMM和指令使用的先前模式被天然的执行。guest VM使用的后来的模式（在这里特权指令能使用关键硬件资源（如IO资源））将会导致从guest mode到host mode（一个VM退出，步骤1）的控制转移。VMM将会处理这个事件（如仿真违背指令），并且使用VM入口去将控制权转移回guest mode（步骤2），在这里guest VM恢复执行。
   对于guest VM的每个虚拟CPU，一个内存中的VM控制集（在Intel术语里的VMCS）被VMM维持。VMCS保存VMM和guest VM的状态，也控制导致VM退出的guest事件。
   使用嵌套虚拟，Cloud Visor现在运行在host mode上，而VMM和guest VM被放置在guest mode下，正如我们在图3的右边所看到的那样。为了强制隔离开VMM和它的guest VM，VMM在guest mode中的一个分开的上下文中运行。要注意的是，将VMM放置到一个更少特权的模式将不会降低VMM的安全性，因为CloudVisor将会确保VMM和它的VM之间的严格隔离。
4.2使用嵌套虚拟保护控制转移
   能够干预：在VMM上下文中执行时，CloudVisor为VMM维持了一个VMCS来控制能够导致VM退出的指令或事件的类型。现在，VMM只会被困于三种与资源隔离相关的架构事件：
（1） NPT/EPT错误，从guest物理地址到host物理地址的转换中导致的错误
（2） 虚拟指令集中的指令执行，如VMRead/VMWrite（VMRead和VMWrite指令读写VM控制集（VMCS）
（3） IOMMU错误，是由device address转化为host address过程中导致的错误。
其他的架构事件，如页错误和中断没有使CloudVisor受困，直接被发送给VMM。
   给每个guest VM的VMCS仍然被VMM创建和维持。当VMCS被安装到CPU上时，CloudVisor重现了一些关键的控制区域。比如，VM出口处理器的入口地址在VMCS中被详细说明。为了干预控制转移，CloudVisor记录了入口地址并且将它替代为CloudVisor内部处理器的入口地址。这样，所有来自于guest VM的VM出口首先被CloudVisor处理，然后传播给VMM。
   安全控制转移：CloudVisor在VM出口的guestVM和VMM之间进行干预，主要由于3个原因：
（1） 当VM被中断时，保护CPU的寄存器上下文
（2） 操纵地址转移来强制进行内存隔离（细节在部分5中）
（3） 拦截并且分析IP指令，来决定VM中的IO缓冲区地址。（细节在部分6中）
   正如在图3的右边部分看到的那样，CloudVisor干预每个VM出口事件（步骤1），保护CPU上下文，并且在必要情况下分析I0指令，然后将VM出口事件转移到VMM（步骤2）。它然后从VMM拦截VM入口请求（步骤3），存储CPU上下文，恢复相应guest VM的执行（步骤4）。
   外界中断和特定指令执行都会导致虚拟机退出。对于外部中断，VMM不需要通用寄存器来处理这个事件。在这种情况下，CloudVisor在把这个事件传播给VMM之前保存并且清除通用寄存器的内容。在VM入口，CloudVisor为guest VM恢复保存的寄存器，并且继续VM运行。
   对于同步指令执行导致的VM退出，CloudVisor只重置一部分寄存器上下文，并且保存对于事件处理很重要的状态。比如，在一个IO指令中的程序计数器和一些通用寄存器应当被暴露给VMM。
   CloudVisor确保对于每个虚拟的CPU，VM入口的CPU上下文和上次VM退出时的上下文一致。所以，VMM不能够通过触发任意中断来转储CPU寄存器信息，在guest VM中重定向控制任意代码，或者篡改guest VM的CPU上下文。
4.3动态嵌套虚拟化
   虽然CloudVisor在VMM之下运行，它并不为了小TCB的便利，包含机器引导程序代码。结果就是，它在VMM和management VM被初始化后再被引导。当CloudVisor引导时，它在host mode下运行，将VMM降级到guest mode，所以有效地在运行中虚拟化VMM。为了确保一个防干扰的动态嵌套虚拟化，CloudVisor采取动态的root of trust（比如Intel TXT[27]和AMD SVM[9]）来确保当处理器初始化CloudVisor时，处理器在一个已知的干净的状态中。CloudVisor二进制的SHA-1哈希被计算出来，存储在TPM[66]中为了未来远程认证。这个在宏指令中被完成，比如在处理器中硬连线的SINIT（Intel TXT）和SKINIT（AMD SVM）。为了多处理器或者多核的平台，在开启CloudVisor前所有的处理器被同步，来确保所有的处理器被同时地嵌套虚拟化。
5. 内存隔离

   为了在CloudVisor ，VMM和guest VM中提供有效的内存隔离，CloudVisor使用商业可用的扩展分页或者嵌套分页技术，为MMU虚拟化提供硬件支持。
5.1使用嵌套/扩展分页技术来隔离
   图4的左边部分展示了在虚拟化系统中的扩展分页的意图用途：VMM本身使用一个转换表来直接将虚拟地址（VA）转化为host物理地址（HPA），并且控制VM如何使用一个扩展页表（EPT）来将guest物理地址（GPA）转化为HPA。Guest VM使用传统页表来管理从VA到GPA的地址转换。
   当CloudVisor被引导时，VMM被降级为在guest mode上运行。一个扩展页表（EPT）被创建给VMM，并且VMM的地址转换然后被配置成使用两步地址转换（使用页表（VA到GPA）和扩展页表（EPT）（GPA到HPA））。正如在图4的右边部分展示的那样，CloudVisor保持了一个一致的GPA到HPA的mapping EPT给VMM（被称作EPT-x）。所以，VMM对于CloudVisor进行的内存虚拟化并不清楚。CloudVisor从EPT-x中移除了它自己的内存来将它自己的内存空间与VMM隔离。EPT-x被保存在CloudVisor内存空间中，并且不能被VMM存取。VMM仍然为每个VM维持着GPA到HPA‘的映射表（被称为EPT-v），但是只被授予了读的权限。
   在原则上，一个guest VM能够被配置来使用软件地址转换（如shadow page table）和 硬件辅助的地址转化。软件地址转换的支持应当在CloudVisor中技术可行，但是也许会更加复杂。为了简化，CloudVisor现在只支持硬件辅助地址转换的平台。如果VMM欺骗guest VM来使用软件地址转化机制，CloudVisor将会拒绝为这个VM认证。
5.2内存所有权跟踪
   为了确保VMM和它的guest VM之间的内存隔离，CloudVisor保持了一个表来跟踪每个物理内存页的所有权。这个表中的值是这个页的所有者ID。每个VM在被引导时被分配了一个独一无二的ID。VMM的ID被固定为0。CloudVisor确保一个物理内存页只能在同一时间被分配给一个所有者。
   在系统启动过程中，所有的除了在CloudVisor中的页都被VMM拥有。当guest VM的EPT被第一次加载进处理器时，CloudVisor进入整个EPT来找到所有被映射的页。这些页被认为被分配给guest VM。CloudVisor改变这些页的所有者给guest VM，并且将它从VMM的EPT中取消映射，这样VMM就再也不够触及这些页了。当一个页从EPT中被取消映射时，页的所有者被设置成VMM，并且这个页在VMM的EPT中被重新映射。
   无论何时VMM更新guest EPT，在EPT中的一个页错误（在Intel词汇中的EPT violation）会发生。CloudVisor通过验证页的所有者来处理错误。当一个新的映射被建立时，CloudVisor确保要被映射的页属于VMM。CloudVisor将它从VMM的EPT中取消映射，并且改变页的所有者给guest VM。当一个已存在的页被取消映射时，CloudVisor加密这个页的内容，把它映射到VMM中的EPT，并且改变VMM的页所有者。CloudVisor不允许一个页被映射到相同的EPT中超过一次。为了重新映射一个页，VMM需要首先取消映射它，然后将它重新映射到新的位置。
   DMA可行的设备能够绕开MMU（内存管理单元）强制的内存存取控制。为了防卫恶意的DMA请求，CloudVisor让受保护的内存区域不被使用IOMMU的DMA设备可达，通过操纵从host 物理地址到设备地址的转换。在系统启动期间，CloudVisor在IOMMU表中取消映射它自己的内存，来阻止DMA请求存取内存。当guest VM启动时，CloudVisor也在DMA可行设备的IOMMU表中取消映射VM的内存。当guest VM关闭时，这些页被返回给VMM，并且CloudVisor重新在IOMMU表中将这些页映射。当一个DMA请求被设置为存取CloudVisor或者guest VM的内存页，一个IOMMU错误就会发生，并且被CloudVisor处理。当前，CloudVisor简单地拒绝这个请求。
5.3合法内存存取
   CloudVisor提供的内存隔离机制确保guest VM的整个内存空间不能被VMM和management VM存取。然而，有几种情况，VMM和management VM应当被允许存取guest VM的一些内存。在这样的情况下，CloudVisor干预并且帮助这样的存取来确保只有最小化的非敏感数据被泄露。
   特权指令，比如IO指令和控制寄存器的存取会导致trap（如VM退出），这些trap会被VMM处理。在一些情况下，VMM在guest VM的内存中需要得到指令操作码来仿效它。在这样的trap中，CloudVisor取得特权操作码，并且将它提供给VMM。因为CloudVisor只允许获取被程序计数器指向的一个操作码，VMM就不能够欺骗CloudVisor来取得任意没有权利的操作码，也不能任意触发陷阱来得到操作码。
   在一次trap中，故障指令的程序计数器是一个虚拟地址，并且内存操作数也被表达成虚拟的地址。VMM需要去查询guest VM中的页表来将虚拟地址翻译成guest物理地址，然后要进一步使用EPT翻译成host物理地址。为了处理这个情况，CloudVisor短暂地允许VMM来间接地读取操作码和内存操作数对应的guest页表条目。当一个trap由特权指令的执行产生时，CloudVisor得到指令的程序计数器并且分析这个指令来获取内存操作数。CloudVisor查询guest VM中的页表来获取需要的页表条目，来翻译程序计数器和内存操作数。当VMM存取页表时，CloudVisor提供给它先前获取的页表条目。为了减少跟特权指令仿真相关联的开销，CloudVisor使用一个缓冲区来高速缓冲每个VCPU的特权指令的页表条目。
   仿效IO存取时，当VMM也需要得到guest IO的缓冲区内容。当VMM存取IO缓冲区时，一个EPT错误会发生，CloudVisor通过复制 给VMM的数据 来处理错误。确切地说，当VMM从或者向guest VM复制数据时，CloudVisor验证guest VM的缓冲区地址是一个已知的IO缓冲区，并且决定是否这个缓冲区被磁盘IO所用（部分6.1）。
6. 磁盘存储保护
   VM的虚拟磁盘也是关键的资源，需要隐私和完整性的保护。有2个供选择的方式来保护虚拟磁盘。第一个是让云使用者使用加密的文件系统来在文件系统层级保护磁盘IO数据，比如Bitlocker[1]和FileVault[3]。这不需要CloudVisor提供对于磁盘IO数据的保护，因为磁盘IO只包括加密数据，并且文件系统本身会确认磁盘数据的完整性和新鲜性。
   为了给租户的VM提供透明的保护，CloudVisor也提供了全磁盘加密和哈希来保护磁盘数据的隐私和完整性。CloudVisor加密VM和VMM之间的数据交换，并且确认磁盘IO数据的完整性，新鲜性和有序性。
6.1处理数据交换
   检索IO配置信息：当VM启动时，guest VM经常探测它的IO配置空间（比如PCI）来识别IO设备和它们的接口。VMM经常虚拟化IO空间并且提供虚拟设备的信息给VM。CloudVisor干预通信，来收集被插入在guest VM中的虚拟设备的信息。以这种方式，CloudVisor能够知道VM使用的IO接口和它们的类型。在IO接口中，CloudVisor对待磁盘IO接口不同于其他接口如VGA，网络和串行控制台。所有通过磁盘IO接口的数据交换都在被复制进VMM前被加密和哈希，并且在被复制进guest VM前被解密。CloudVisor在其他端口（如NICs）上没有加密或解密数据交换。
   干预IO请求：为了决定是否guest VM和VMM之间的IO数据交换是合法的，CloudVisor拦截并且分析来自于guest VM的IO请求。CloudVisor没有仿真IO请求，仅仅记录这些请求。通过从IO指令中分析IO请求，CloudVisor检索IO端口，IO缓冲区的内存地址和缓冲区大小这些信息，为了更进一步的处理。
   有两个可选的方式来处理这些IO请求。第一个是“trap and emulate(仿真)”这些请求。为了确保安全性，CloudVisor使用一个白名单来记录IO请求，然后将它们传播给VMM，VMM会通过复制这些数据到或者从guest VM中的缓冲区来处理这些请求。跟随的数据复制将会trap（如VM退出）给CloudVisor，CloudVisor会使用白名单来验证数据复制。在数据交换之后，相应的记录会从列表中被移除，来阻止VMM再次访问内存页。
   第二个方法是使用CloudVisor中的bounce buffer（弹性缓冲区）来帮助数据交换。当guest VM试着向VMM复制数据时（如一个IO写操作），CloudVisor拦截请求，将数据拷贝进弹性缓冲区，然后给VMM提供一个修改的IO请求来让VMM从弹性缓冲区中读取而不是从guest VM中读取。相似的，当VMM试着向guest VM复制数据时，数据首先被写入弹性缓冲区，然后被guest VM读取。
   从原则上说，第一个基于“trap and emulate”的方法能够处理基于端口的IO和直接内存访问（DMA），然而，如果数据以小块的形式（如4或者8字节）被复制，它将会给CloudVisor引进很大数量的trap（如VM 退出）。一个引发多重trap的DMA请求将会给IO密集型的应用带来很大的性能下降。跟第一个方法相比，弹性缓冲区方法只需要一个额外的数据拷贝。所以，CloudVisor使用第一种方法来应对基于端口的IO和第二种方法来应对DMA。
6.2磁盘IO的隐私和完整性
   CloudVisor使用AES-CBC算法在磁盘扇区的粒度上来加密和解密磁盘数据。一个128比特的AES密钥由用户产生，并且和加密的VM镜像一起被传递给CloudVisor。存储器的AES密钥总是在CloudVisor内部被维护。
   在VM启动的时间，CloudVisor获取了在Merkle哈希树中的哈希和IVs（初始化向量表）的所有的非叶节点，并且就像在内存中的cache那样保存它们。在磁盘读取中，CloudVisor首先hash数据块来验证它的完整性，然后使用AES存储密钥和IV来解密磁盘扇区。在磁盘写入中，每个磁盘扇区产生一个IV，如果它还没被产生的话。数据块被hashed，然后使用存储密钥和IV被加密。
   因为CloudVisor没有控制设备，它不能够读写外部存储空间的metadata。一个方法是让CloudVisor向VMM发起shadow DMA请求。然而，我们的经验表明这有时会在guest VM中导致IO请求的超时。相替代的是，我们在management VM中提供了一个用户层级的代理来帮助进行metadata的获取，更新和cache。这个代理是不被信任的，因为它和management VM中的其他软件有相同的权限。当代理拒绝运行或者错误地运行，CloudVisor总能够通过验证metadata来监测到不良行为。

   正如在图5展示的那样，对于每个磁盘扇区，一个128比特的MD5 hash和一个128比特的IV被存储在management VM中的文件系统中的一个文件中。Hash使用Merkle树来被组织，来保证磁盘数据的新鲜性和有序性。当开始一个guest VM时，这个文件被映射进代理的内存中。代理获取Merkle hash树中的所有非页hash，并且将它们发送给CloudVisor。CloudVisor将这些hash缓存进内存来消除进一步的获取。
   在一次磁盘IO的读取中，虚拟设备的驱动首先从VM中的磁盘映像中读取请求的磁盘块（步骤1），然后代理获取到请求磁盘块的hash和IV，并且将它们放入CloudVisor提供的hash和IV缓冲区（步骤2）。并且CloudVisor来验证所获取的hash的完整性（步骤3）。然后加密文本的MD5 hash被计算（步骤4），并且与获取的hash来做比较（步骤5）。如果计算出的hash和存储的hash相匹配，CloudVisor就使用获取的IV和存储的密钥来解密数据（步骤6）。如果数据有效，CloudVisor将它复制进guest VM中的IO缓冲区，并且在必要的情况下从白名单中移除缓冲区的地址（步骤7）。磁盘IO的写操作和读操作相似，不同之处在于CloudVisor将会生成IVs和hashes并且将它放入metadata文件。
   代理利用操作系统的文件cache来缓冲大多数频繁使用的metadata。在最坏的情况下，为了一次磁盘读，代理需要读取超过两次磁盘来获取相应的hash和IV。
   突然的停电会导致状态的不一致性，因为CloudVisor现在不能够保证磁盘数据,hash和IVs的原子性更新。为了简化起见，CloudVisor假定云服务器配备有电力供给的备份，能够在停电中关闭设备且保证数据不丢失。最近的研究[70]已经表明在一个安全文件系统中提供原子性和一致性并不十分困难。我们计划在未来并入这样的支持。
7. 实现的问题和状态
   CloudVisor已经实现，基于商业可用的虚拟化硬件支持，包括VT-x[45]，EPT[45]，VT-d[5]和TXT[27]。为了防止在VM中基于cache的边信道攻击[56]，CloudVisor使用CPU中的AESNI指令集[56]来做加密。为了简化起见，CloudVisor现在只支持硬件辅助的虚拟化。CloudVisor支持Xen with both Linux和Windows作为guest操作系统，并且能够运行多个单处理器和多处理器的VM。
7.1多VMs和多核支持
   CloudVisor支持多VM来同时地在一个多处理器的机器上运行。为了支持多处理器，CloudVisor为VMM使用的每个CPU核维持了一个VMCS。VMM中所有的CPU核共享一个EPT（如EPX-x）并且CloudVisor从多核到EPT-x序列化存取。在开启过程中，SINIT/SKINIT使用IPIs（内部处理器中断）来广播所有的CPU核，并且在所有的核上同时开启CloudVisor。
7.2VM的生命周期管理
   CloudVisor能够透明地支持VM创建和销毁，和VM保存、恢复和迁移。接下来将简要地介绍CloudVisor所需要的有关行为来提供给VM进行这些操作的保护。
   VM创建和销毁：即使整个VM映像被加密，VM创建仍然能够被CloudVisor以一种透明的方式来支持。当IO数据被复制到guest VM的内存中时，IO数据被透明地解密。在VM销毁过程中，对于VM内存页的存取权利被透明地恢复到VMM中。
   VM快照、保存和恢复：为了支持VM快照、保存和恢复，guest VM的内存完整性和隐私应当要被保证。CloudVisor使用每页的加密和hash来保护内存快照。与磁盘映像的保护相似，内存内容以页的粒度被hash。这些hash被组织成Merkle树，并且以IV数组的形式存储在一起。
   当management VM为了保存而映射并且复制VM的内存，操作并不是由VM自身的IO指令来初始化。CloudVisor将不能够在白名单中找到一个相应条目。在那种情况下，CloudVisor将会使用AES存储密钥和新产生的IV来加密请求页。VMM将会得到一个加密后的内存映像。当恢复内存映像时，VMM把加密内存映像复制进guest的内存空间。CloudVisor发现VM的相应的存储密钥，获取内存映像的IVs和hashes，并且解密页。
   VM迁移：VM迁移过程和VM保存、恢复相似，但是需要一个额外的密钥迁移协议。在迁移存储密钥和root hash之前，位于迁移源和目的地平台上的CloudVisor需要互相验证对方。验证过程跟CloudVisor和云使用者的远程认证过程相似，是一个来自于TCG[52]的标准远程认证协议。
7.3性能优化
   使用硬件支持来加速IO：CloudVisor现在支持虚拟可用的设备，比如SR-IOV NICs，给VM直接分配的设备和虚拟化传统设备。对于前2个情况，因为大多数操作在VM本身上完成而不需要VMM介入，CloudVisor大多数只需要处理初始化工作并且在设备运行时做非常小的工作。
   减少不必要的VM退出：在Intel的平台上，我们发现了很大数量的由于VM读写指令导致的VM退出事件。VMM集中地使用这些指令来检查和更新guest VM的状态。如果不被运行在host mode上时，这些指令总是导致VM退出。这样大数量的VM退出会带来显著的性能开销。为了补救这个情况，CloudVisor为Xen提供了一个可选的补丁，使用对VMCS的内存存取来替代VM的读写指令，跟[13]中使用的方法相似。需要注意的是，给VMCS增加一个内存中的cache将不会引进安全缺陷，因为在VMCS被加载进CPU时，CloudVisor总是会验证VMCS的完整性。
7.4密钥管理
   现在，CloudVisor使用一个简单的密钥管理方案，通过在VM映像中使用密码学的密钥。VM密钥使用机器的公钥（如存储根密钥）来加密，这样VM映像只能被一个已知版本的CloudVisor解密和验证，且这个CloudVisor已被可信任的平台模块（TPM）[66]和Intel的TXT[27]使用认证引导来验证了。当VM被开启时，加密的VM密钥将会被加载进CloudVisor的内存，并且使用平台的公钥（如TPM中的存储根密钥）来解密。解密后的VM密钥会被用来加密/解密VMM和guest VM之间的数据交换。为了减轻用户的部署压力，我们也提供了一个用户层级的工具去将正常的VM映像转化成加密格式，并且产生metadata文件。需要注意的是，这个密钥管理方案和CloudVisor中的保护方法相正交，并且能够轻易地被一个更加复杂的方案所替代。
7.5软复位和硬复位
   一个攻击者也许会发起一个软复位，这个软复位不重置内存，而试图读取一个被租用的VM中的内存内容。在这样的情况下，复位会发送一个相应的INIT信号给处理器，这会导致CloudVisor的一个VMX退出。CloudVisor之后将会擦洗这个被租用的VM上的所有内存，并且通过擦洗它自己的内存来自毁。相似的，如果VMM或者VM崩溃了，CloudVisor在拦截这个事件的过程中将也会做相同的擦洗工作。对于一个硬复位，因为内存将会因为停电而丢失，CloudVisor简单地将硬复位信号报告给CPU。简短地说，CloudVisor使用一个“fail-stop”方式来防止在硬复位和软复位和崩溃过程中可能的攻击。
7.6实现的复杂度
   我们已经基于商业可用的虚拟化硬件支持构建了一个CloudVisor的原型。我们的原型包括为特权操作（如VM退出和EPT错误）准备的事件处理程序集，一个小的指令解释器，一个加密用的AES库。基础代码只有大约5.5K LOCs，能够足够小足够简单来进行验证。也有一个在XEN的QEMU模式中不被信任的用户层级的CloudVisor代理。这个代理包含大约200LOCs，并且处理 为页和IO数据提供的hashes 的管理工作。
  CloudVisor支持Xen with both Linux和Windows作为guest操作系统。CloudVisor对于Intel平台上的Xen使用一个大约100LOCs的可选补丁，在大多数情况下对Xen透明。在CloudVisor上能够同时运行许多不被修改的Linux和Windows VM，以单处理器或多处理器模式。除了Xen，CloudVisor也能够透明地支持VMMs，虽然它对于VMM有很少的假定，这些是我们未来的工作。
8. 性能评估
   我们评估CloudVisor的性能开销，通过使用一系列基准，将它和vanilla Xen比较。因为我们没有一个机器有所有的 被当前实现所需要的特点，我们使用了两个机器来分开展示CloudVisor的功能。第一个机器上配备有Intel Core2 Quad处理器。这个芯片集支持Intel TXT[27]，并且有一个安装好的TPM芯片，但是没有EPT支持[45]。这个机器被用来证明在Xen引导之后，CloudVisor是如何动态地建立一个被信任的可执行环境。我们使用一个Dell R510服务器来作为第二个机器，它配备有2个SR-IOV NICs和一个十亿字节的以太网相连。这个机器有一个2.6GHz 4-core/8-thread Intel processor with VT-x，EPT and AES-NI support and 8GB physical memory。尽管被分开验证，对于功能和性能的评估仍然有效，因为TXT和TPM只在引导事件和VM启动时间有效。CloudVisor在正常的执行时间跟TXT和TPM没有交互。
   我们比较了在CloudVisor上运行的Linux和Windows VM的性能，vanilla Xen-4.0.0. XenLinux-2.6.31.13被用来作为Domain0内核。每个VM配备有一个或者更多个虚拟的CPU，1GB内存，4GB虚拟磁盘和一个虚拟的NIC。这些VMs运行在不被修改的Debian-Linux with kernel version 2.6.31 and Windows XP with SP2，这2个都是x86-64版本的。
   对于Linux VMs的应用基准包括：
（1） Kernel Build（KBuild）that builds a compact (紧凑的)Linux kernel 2.6.31来测量CPU密集型工作量的减慢。
（2） Apache benchemark（ab）on Apache web server 2.2.15 [10]来测量网络IO密集型工作量。
（3） memcached 1.4.5 [19]来测量内存和网络IO密集型工作量
（4） dbench 3.0.4 [65]来测量磁盘IO工作量的减慢。
   SPECjbb[59]被用来评估在Windows VM上的java运行环境中的服务器端的性能。为了理解在加密和hash中的开销，和VM读写优化的效果，我们也使用KBuild和dbench表现了一个细节的性能分析。我们进一步通过在多核和多VM的配置上运行KBuild来评估CloudVisor的性能和可伸缩性。最后，我们使用lmbench-3.0 [41]来量化在原始的操作系统操作中的性能丢失。每个测试都被运行了5次，并且我们报告的是使用性能减慢（计算 (Time(new) - Time(old))/Time(old)）的平均结果。在这个评估过程中，硬件密码学的指令（Intel AES-NI）被用来完成AES的加密和解密。
8.1单处理机VM的性能
   我们使用两个应用来量化在CloudVisor之下的单处理器VM的性能减慢。对于KBuild，我们通过运行“make allnoconfig(kernel的一个选项)”构造了一个紧凑的内核，然后记录完成编译花费的时间。对于Apache，我们使用Apache Benchmark（ab）来在并发层级500上发出1000个请求，来请求一个客户机上的一个4kb的文件，并且收集它的传送率。对于memcached，我们使用了一个远程客户机来向一个memcached服务器发起请求，这个服务器监听UDP端口。对于SPECjbb，我们使用标准的SPECjbb测试脚本来评估 在Windows XP VM上运行的8位数据仓库的商业操作 的平均数量。

   正如在图6中看到的那样，对于KBuild，性能减慢相对来说较高（6.0%）,因为当从磁盘中读文件并且写回文件时，有一些磁盘IO请求相关联。在CloudVisor上的磁盘IO操作需要干预和密码学的操作，这些都是性能减慢的主要来源。对于Apache，因为它大部分包含网络IO，而网络IO不需要CloudVisor的介入，CloudVisor只导致了0.2%的减慢。对于memcached，性能减慢仍然十分小（0.1%）。这是因为它大多数的操作都在内存中，只有小部分的磁盘IO请求。所以它很少给CloudVisor发出自陷指令。对于SPECjbb的性能开销大约是2.6%因为它包含很少的IO操作。对于所有的应用来说，大多数性能减慢来自于对于CloudVisor的额外的VM离开，和一些特权指令的仿真（比如磁盘IO操作）。

   IO性能：因为在CloudVisor中由于密码学的操作，磁盘IO很可能是一个性能瓶颈，我们使用dbench作为一个最坏的基准案例来量化导致的减慢。Dbench模仿真实应用的IO模式来向本地文件系统发出POSIX调用，使得CloudVisor中的IO模块遭受重负。
   正如在图7中展示的那样，当客户的数量很小时，dbench会经历相对小的性能减慢（4.5%, 15.9% and 16.7% for 1, 2 and 4 clients accordingly），是由于在control VM中的文件系统中存放IVs和hashes的 cache有相对更好的局部性。然而，当客户的数量比4更大时，客户之间的干扰导致了IVs和hashes更坏的局部性，所以引发了很大的性能减慢。这能够被解决，或者通过对于一个有充足内存的机器来增加control VM中文件系统的cache，或者在不被信任的用户层级上的代理和CloudVisor上整合一个智能的cache。
   分析性能减慢：为了理解使用VM退出优化的优点，我们描绘出KBuild的执行。我们首先收集了在CloudVisor中的VM退出数据，观察了4717658个VM退出，在CloudVisor中大概有3.31s/102s的时间花费在处理VM退出上。与此相反，在VM退出优化之前，我们观测了9049852个VM退出。因此，优化消除了大约47.9%的VM退出，占用了2.11s在处理VM退出上。
   因为IO密集型的基准强调了CloudVisor中的密码学的模块，我们使用dbench跑32个并发的客户，来描绘由AES加密/解密和hashing导致的减慢。我们使用NULL操作来代替AES密码学的 和/或hashing操作。当没有加密和hashing时，dbench的吞吐量是270MB/S。当只有对于IO数据AES加密被开启时，吞吐量是255MB/S，导致了相对5.9%的减慢。当AEM密码学和hashing都被开启时，吞吐量是233MB/S，导致大约9.4%的减慢。这个评估展示，使用新的AES-NI指令支持，密码学的操作仅仅导致了很小的减慢，即使当CloudVisor处于高负载的情况下。所以，主要的开销来自于IO干预和metadata管理，由于多个客户之间的干扰导致的差局部性，将会进一步变得更糟。
8.2多VM和多核的性能


   为了在多租赁云上评估CloudVisor的性能，我们通过增加被VM管理的核的数目或者增加VM的数量，来扩大系统的规模。图8展示了单个VM在Xen和CloudVisor上运行kbuild工作量的可伸缩性。CloudVisor和Xen相比导致了最多9.4%的减慢，并且在处理器核增加时，减慢并没有成长太多。在guest VM的执行期间，VM退出主要的原因是磁盘IO请求。
   对于在多VM上并发地运行KBuild，评估结果正如在图9中展示的那样。在评估中，每个VM被配备有1个核，512MB内存和一个虚拟磁盘。和Xen相比，CloudVisor引发了最多16.8%的延迟（8VMs）。当VM的数量小于8时，延迟十分温和。在CloudVisor中，每个guest VM的磁盘IO状态在每个VM区域被组织，这个区域能够被同时访问而不需要锁保护。多IO请求能够被CloudVisor并行地处理。然而，随着VM数量的增长，CloudVisor代理使用的缓冲区cache将会产生压力。虽然每个guest VM有它自己的CloudVisor代码实例，在control VM中的实例分享了OS内核中的文件cache。                                                                                                                                                                                                                                                                                                           
8.3OS基元

   Lmbench被用来评估一些原始操作系统操作的延迟。结果被展示在表格3中。CloudVisor对于基元（没有trap to the VMM，就像stat,mmap和Bcopy那样）并没有导致太多的延迟。10k文件删除检测了文件移除每秒的速率。10k文件删除检测了每秒文件移除速率，包含在文件系统中的索引节点更新。Sh pro执行了二进制，包含了昂贵的文件操作。
8.4引导事件和内存开销
   因为CloudVisor要求当引导一个guest VM时，去做加密和完整性检测。我们也比较了在CloudVisor下和Xen下完整地引导一个VM的事件。正如所预期的，当启动一个1GB内存的VM时，在CloudVisor下的VM引导事件遭受了2.7X的延迟（33.3s v1 9.1s）。这是因为在系统引导过程中，频繁的特权指令仿真，IO干预和密码学操作。我们相信这样的开销是值得的，因为CloudVisor确保guest VM的不被篡改的引导程序。
   在Cloudvisor中主要的内存使用，是为了对于每个guest VM和一个弹性缓冲区的非页Merkle树metadata的存储。最大上限是每个VM10MB。CloudVisor剩下部分的内存消耗不足1MB，所以，对于内存充足的commodity server机器，CloudVisor的内存开销是可忽略的。
9. 限制和未来的工作
   CloudVisor是对于利用嵌套虚拟的概念[23,13]，为了TCB的减小和虚拟多租赁云的安全保护，进行的首次尝试。在CloudVisor上仍然有充足的提升空间，这是我们未来的工作方向：
   增强保护：当试着防卫一个敌对的服务提供者[57,17,71，40]时，在CloudVisor和其他相似的系统中都会存在一个通用的问题，因为这个服务提供者（如OS或者VMM）也许会误导或者甚至拒绝为client提供服务（如一个VM或者一个应用）。确切的说，一个恶意的VMM也许会试着误导VM，甚至通过抛弃来自于VM的IO请求。一个可能的解决技术是通过VMM让一个VM或者CloudVisor来proof-check服务。
  我们也调查了对于硬件和软件间的功能分割权衡。因为CloudVisor的功能是简单而固定的，也许对于在硬件或者固件（就像Loki[72]）中完成CloudVisor是可行的。
   对于VMM功能的影响：尽管CloudVisor和虚拟栈中的当今的操作大多兼容，如保存和恢复，它确实会禁止一些需要内省VM内存的VM内省系统[30,29]，因为它们只能看到加密数据。进一步的说，CloudVisor在VM之间遵循一个严格的隔离协议，会阻止一些内存共享系统[67,25,43]工作。这能够被简单地实现，通过允许一些被VM之间只读共享的页，并且在CloudVisor中验证对于这些页的任何修改。最后，CloudVisor现在使用一个对于可能攻击或崩溃的fail stop方法。这能够被fail-safe方法代替，来增强CloudVisor上VM的可靠性。
   VMM合作：我们现在的系统被设计来跟现存的VMM一起工作，保持向后的兼容性。因为优化了VM读写，对于Xen VMM的 使它跟CloudVisor合作的 轻微改变将会进一步的增加CloudVisor的性能，减少CloudVisor的复杂度。
   支持其他的VMM：我们现在只检测了给Xen VMM的CloudVisor，我们未来工作的一部分包括在其他VMM上评估CloudVisor（比如VMware,KVM和BitVisor[57]）和OSes（比如MAC OS和FreeBSD）。进一步说，我们也会调查CloudVisor上VMM怎样能适应支持半虚拟化。
   验证：CloudVisor现在代码基很小，所以能够被官方地确认它的正确性和安全属性[34]，并且通过软件模型检查[28]验证它的实现，这些都会是我们未来的工作。