X86服务器虚拟化的三种技术

      云计算、SaaS等基于服务的计算模式最近异常灼热。服务器虚拟化技术尤其是对低端廉价x86服务器的虚拟化已被公认为是实现这些计算模式的关键技术，对于能否廉价提供云计算、SaaS等服务至关重要。在x86服务器虚拟化方法上有三个知名的技术流派：Para-Virtualization, Full-Virtualization和Hardware-Assisted-Virtualization。本文谨对这三种技术作简要介绍。

　　Para-Virtualization(Citrix的Xen和Microsoft的Hyper-V为典型代表)直译成中文是“在旁边的虚拟化”。形象地说就是：在虚拟化软件hypervisor上面跑着的诸多客户虚拟机(下称guest VMs或guest OSes，客户操作系统)，在它们“旁边”还跑着一个特别OS，叫做“管理OS”或“管理VM”(the Administrative OS/VM，用Citrix Xen的术语叫做Dom0，用Microsoft Hyper-V的术语：the Parent Partition)。这个“管理VM”是让系统管理员用来管理hypervisor的。客户所使用的是那些在它旁边跑的guest VMs(Citrix Xen叫做DomU，Microsoft Hyper-V叫做Child Partitions)。另外这个“管理OS”还采用native OS的方法管理整个硬件平台上的所有输入输出设备驱动器(IO device drivers)，它里面包含了平台上所有输入输出设备驱动器。也就是说Para-Virtualization方法在hypervisor里不对设备驱动器做虚拟(emulation)，而仅对CPU和内存做虚拟，所以Para-Virtualization又被翻译作“半虚拟化”。Para-Virtualization还有一个叫法：OS-Assisted-Virtualization，就是因为guest VMs需要“管理OS”协助。这可以形象地看作是guest OS自身不带有设备驱动器而“向旁寻找”帮助。另外guest OS还会发出一小部分由于硬件不支持而无法被虚拟化的OS指令。在虚拟化理论中，这种不能被虚拟化的guest OS指令属于“低特权态部件发出的敏感指令”：处于低特权态(用户态)的guest OS如果对硬件发出这样的指令，则处于高特权态(内核态)的hypervisor必须先对这些指令进行检查作“无害化”处理后方能交给硬件机器做计算或处理服务。由于以前x86硬件设计上存在缺陷，这一类指令不能自动被hypervisor截获(trap)。对于这些不能自动被hypervisor截获的指令，Para-Virtualization技术采用了在guest OS中人为植入hypercalls的方法使程序流程主动进入hypervisor以获得“无害化”处理。由于需要在guest OS中植入这些hypercalls, 所以Para-Virtualization技术需要对guest OS内核作修改后方能使用于VM内。这一点被认为是Para-Virtualization技术的一个缺点：比如对于非开放源代码OS(如Windows 2000/XP)那就只有OS厂商才能制做guest OS。

　　Full-Virtualization(VMware的ESX)全虚拟化：对于前面提到的guest OS作为“低特权态部件发出的敏感指令”，VMware找到了一个“可执行代码翻译”(binary translation)方法将这些指令的可执行代码转变为一系列新的指令顺序，翻译得到的新指令顺序不仅与原指令具有等价的语义，而且可以得到硬件虚拟化支持。这样一来就无需再人为在guest OS中植入hypercalls了，所以未经修改的guest OS内核可以直接跑在VM里面。而且guest OS更本无法分辨出自己到底是直接跑在机器硬件上还是在一个虚拟硬件的hypervisor上。作为一个全虚拟化的hypervisor，ESX将硬件平台上的所有的输入输出设备也都虚拟化了，所以ESX里面含有所有这些设备驱动器，guest OS无须从一个“管理OS”来获得设备驱动器服务。ESX仍然有“管理OS”，叫做the Management Console，其作用是让系统管理员管理ESX hypervisor，仅此而已。

　　Hardware-Assisted-Virtualization硬件协助的虚拟化：Intel VT-x与AMD-V。这两家x86处理器厂商最近对处理器硬件作了修改，使前面提到的guest OS“低特权态部件发出的敏感指令”能够自动被hypervisor截获。所以在这种新机器上，Para-Virtualization就没有必要再对guest OS内核作修改，Full-Virtualization也无必要对guest OS做可执行代码翻译。所以我们也可以说，如果不考虑Para-Virtualization与Full-Virtualization在IO设备处理上还有不同之处，那么硬件协助的虚拟化技术已经取消了前两种虚拟化技术之间的差别：两者都可以被看作是全虚拟化技术。

　　Intel和AMD在对X86服务器硬件协助的虚拟化技术上还做了如下重要工作：统一管理了平台上输入输出设备对内存的直接访问(Direct Memory Access, DMA)。这改变了以前机器上输入输出设备可以自由任意对内存进行直接访问，这种“无政府主义”的危险状态(非常危险!)。用硬件协助的虚拟化技术对DMA作统一管理，这对于x86平台服务器虚拟化技术运用到云计算加强云计算安全方面有很重要的意义。前面我们提到硬件协助的虚拟化技术取消了Para-Virtualization与Full-Virtualization之间的差别，这样的说法没有考虑到两者在IO设备管理上的不同之处。其实正是在对IO设备DMA的统一管理方面，Citrix Xen或MS Hyper-V与VMware ESX有很不同的性质，在云服务安全上有明显的差异。

X86服务器虚拟化的三种技术（2）

　  Intel的VT(Virtual Technology)和AMD的AMD-V(AMD Virtualization)技术对X86架构处理器打了硬件补丁之后，X86平台在虚拟CPU与内部存储器方面变成了一个支持完全虚拟化的平台，在这方面，Citrix Xen，MS Hyper-V(“在旁边的虚拟化”)与VMware ESX(全虚拟化)之间的差别已不复存在。但我必须提醒：前两者与后者在虚拟输入输出设备(IO Devices)方面仍然存在着一个根本的重要的差别。本讲揭示这一差别。

　　与虚拟CPU和内存的情况一样，虚拟一个IO设备也是让一个虚拟机(VM)感觉到它是在独享该设备。所以IO设备虚拟化任务也是替每一个VM分别管理好所用设备的服务状态(service state)。设想当一个设备(如网卡)在某个时间片断为VM1提供了一个服务片断(读入一页网页)，在下一个时间片断要转而向VM2提供服务时，此时系统就必须先记住该设备为VM1提供当前服务片断后的状态，才可以让设备转向服务于VM2。只有这样做该设备才会知道以后再回到VM1时怎样继续提供尚未完成的服务。因为每一个IO设备都完全受控于一个叫做设备驱动器的软件，所以对一个设备和一个VM之间进行状态跟踪管理也就是针对相应驱动软件的服务状态进行跟踪管理。

　　“在旁边的虚拟化”(Para-Virtualization, Citrix Xen与MS Hyper-V都是)采用了非常简单实用的“在旁边有驱动器”之方法：让所有的客户(guest)VM 都去使用安装在那个“管理OS”(Xen的Dom0，Hyper-V的Parent Partition)里面现成的设备驱动器。这样一来整个平台上的IO设备就可以步调一致井井有条地为每一个客户VM服务了。当一个客户VM中的OS(中自有的设备驱动器)向硬件发出IO设备使用指令时，这些指令会被trap到hypervisor里，再被转到管理OS去使用它里面相应的设备驱动器。

　　与这个方法不同，VMware ESX选择在hypervisor里面置入并管理平台上所有的IO设备驱动器。ESX上的管理OS(又叫做Host OS或Service Console)只负责让系统管理员来管理客户VMs，比如创立、启动客户VM，启动VMotion操作等等，而不负责虚拟任何IO驱动器。另外我们知道ESXi压根就不带有管理OS，系统管理员是通过网络进入hypervisor来管理客户VM的。

　　Intel和AMD在给X86架构打硬件补丁的工作还实现了统一控制平台上IO设备对内存的直接访问(Direct Memory Access, DMA)。这改变了以前机器上IO设备可以随意对主机内存进行直接访问的无政府主义危险状况。诸位不要以为只有中央处理器(CPU)才是平台上唯一的脑子可以对内存进行访问操作。CPU的确可以被看作是平台上的“大脑”，然而平台上还有诸多“小脑”们：几乎每一个现代IO设备都自身带有固件，里面装有可执行指令可对主机内存进行读写访问。在以前的X86硬件上这些小脑们对主机内存进行DMA读写操作根本不必听从大脑的指挥。幸亏在非虚拟情况下平台上只跑一个操作系统，如果某个小脑对主机内存做了错误操作，造成的破坏也许还可以容忍，因为大不了平台崩溃只不过毁掉了跑在一台机器上的应用(一定遇到过Windows的蓝屏吧!)。如今在一个虚拟化的服务器平台上跑着许多不同虚拟机和不同操作系统，无政府主义的危害就不再那么单纯无邪了。小脑的一个误操作有可能打破不同虚拟机之间的隔离，轻者造成所模拟的操作系统出错，重者导致平台上所有的虚拟机全部崩溃。最近在X86硬件上的补丁工作(Intel的 VT-d, AMD的 IOMMU)对主板进行了重新布线，将所有小脑们的IO连线都统一联到北桥上的一个硬件部件IOMMU，于是大脑就可以使用该部件，采用MMU同样的方法统一协调管理小脑们对内存的IO访问了。有了大脑统一协调管理IOMMU，小脑即使误操作也应该无法穿越不同VM之间的隔离。但是这个说法只适用于通常的非恶意系统软硬件错误情形，不适用于在计算机安全上出错的情形。在考虑安全问题时所谓错误都是恶意攻击的结果，是攻击者有意引入的。在考虑安全问题时小脑们的驱动器软件(请回忆，IO设备都是受驱动器控制的)身处于系统软件栈的哪个权限层次就是一个非常重要的问题。这些软件所处的权限层次越接近硬件层，攻击者对它们进行攻击的手段就越有限也越困难。

　　对于“在旁边的虚拟化”方法( Citrix Xen与MS Hyper-V)，前面提过所有设备驱动器软件都安装在管理OS里面。这个管理OS虽然跑在一个低特权态(hypervisor之上的非内核态)，却由于需要向平台上所有客户VMs提供设备驱动器服务因而必须可以操控所有这些客户VMs。于是这个处于低特权态的管理OS就自然形成了一个可以被利用来对任一客户VM进行DMA攻击的最薄弱环节。所有对一般OS有效的攻击方法(我们知道有大量这样的方法)都可以被利用来攻击这个OS中的驱动器软件，对客户VM实施DMA攻击。

　　而VMware ESX的情况不同：平台上所有设备驱动器都是在hypervisor中模拟得到的。hypervisor是直接跑在硬件上的，即处于最高特权态。一般攻击OS的用户态手段都不能对hypervisor产生有效攻击。另外Intel VT-d和AMD IOMMU都格外注重对hypervisor代码与数据施加保护。如果想要通过攻击hypervisor中设备驱动器的方法来对客户VM实施DMA攻击，那要远比这些设备驱动器处身于用户态OS中的情况困难得多。

　　业界诸多专家已经认可如下为不争事实：用可信计算技术来保护hypervisor是一个可行方法，Intel的Trusted eXecution Technology(TXT)就是一个典型案例。而用可信计算技术来保护用户态OS是一个不可行方法，MS的Vista OS中的BitLocker技术就是尝试这一方法的一个典型失败案例。