在上一讲中我介绍了：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技术就是尝试这一方法的一个典型失败案例。
下一讲将介绍可信计算技术并讨论为什么使用可信计算技术来保护hypervisor，尤其是保护象VMware ESX那种自身含有IO设备驱动器的hypervisor，这种技术方法可以在云计算或基于服务架构的安全保护上找到重要有效的应用。