微软的Hyper-V的安全性从何而来？

　　微软在新的Hyper-V中一直在着重提出其在安全性方面的优势，而微软或许也希望通过对安全性的阐述来带出两点：1、微软的Hyper-V是与众不同的;2、Hyper-V的微架构相比其它“第三方的解决方案”是有特殊的安全性优势的。

　　确实，由于Hyper-V在微内核上的优势：微内核管理程序包含了尽可能少的代码，在Hyper-V的管理程序中，你既看不到设备驱动程序(驱动程序是跑在每一个独立的分区中，而虚拟机OS虽然在相互独立的单独分区内但是却能够很好的通过Hypervisor直接访问硬件)，同时，Hyper-V也少见第三方代码，因此，微软成功的将Hyper-V的安全隐患降到了最低。

　　但这只是Hyper-V的安全性话题的其中一部分，微软在保护Hyper-V上所投入的力量显然是更为巨大的，且安全性，尤其是在与Windows Server紧密结合之后的安全性，正成为微软与VMware、Xen Source这些第三方解决方案抗衡的重要砝码。

　　微软的Hyper-V的虚拟化前身来自于Virtual Server，这是一个建立在Ring0内核模式和Ring3用户模式下的传统模式，宿主机的Windows和驱动程序及VS底层驱动都是在Ring0下，Virtual Server则是在Windows Server上的，通过IIS来进行管理，与内核进行通信，但反观虚拟机，其Virtual Server则运行于一个高于WIndows的Ring1虚拟内核模式上，特权低于Ring0，但是高于Ring3——问题在于很多特权指令很可能不能够在Ring1上得到完善的支持，当然，我记得微软好像也有一种什么二进制指令翻译的技术进行处理，但是这毕竟不是一个最“根本”的解决途径。

　　在Hyper-V中，不再有宿主机和虚拟机之分，微软带来的新概念是：父分区和子分区，通过在硬件底层安装Hypervisor，然后就在虚拟机上划分多个分区，父分区和子分区虽然看起来可以对应之前的宿主机和虚拟机，但是其地位已经基本平等，他们的内核都是运行在Ring0上，应用程序则运行在Ring3用户模式上，与VS最大的不同是，虚拟机的内核不再运行在Ring1之中，Hypervisor运行的则更为底级，大致是运行在CPU上的一个什么层上，微软的命名也很有意思，叫Ring-1，从图中我们看到，微软虚拟化的功能和结构已经大大的复杂化和体系化(见下图)。

　　好，现在我们已经对Hyper-V的架构有了一定的了解——从第三方的结构上来看，Hypervisor有两点安全性值得我们注意：第一，其不能满足深度防御体系——这一点当然是微软一致推崇的;第二，Hypervisor直接运行在硬件上，导致了特权的最大化，其风险可想而知，因此，Hyper-V既然是基于Hypervisor技术的，也就面临了同样的问题。

　　微软的解决办法是：在Hyper-V中只做内存管理和CPU调度，其他的设备则通过关键的VMbus——这是一种穿越机制，通过VMbus进入Ring0进行转接，从而构建了一个微软Hyper-V的三层架构(当然，就是那个深度防御体系)：调度CPU管理内存的Hypervisor层、存储/网络堆栈和驱动运行的Ring0层以及Ring3层之中的虚拟设备/管理用API/虚拟机(见下图)。

　　不知道有没有人注意到：VMbus是其中的一个安全性的核心，他负责了那些可能会出现问题的命令和代码的执行——基于VMbus的高速内存总线架构是其安全性实现超越主要贡献者，每台虚拟机之间隔离的VMbus调用保证了每个分区，每个虚拟机之间完全的隔离开(或许我们可以说是“类物理机”?)

　　除此以外，我们还会看到，正如我在文章开头所说，Hyper-V底层的Hypervisor代码量很小，不带有第三方驱动，仅仅是负责两件事情的非常精简的架构下——而且还是纯粹的微软的代码(微软自己声称不包含任何的bug)，安全性能够得到大大提升——只做最核心的，不做那些可能会出问题的，Hypervisor会出问题才怪?!

　　当然，这并不是全部的内容，微软的工程师曾经提到过有关Hpyer-V安全加固部分：首先，Hypervisor拥有自己的地址空间，与Guest的地址空间隔离;其次，Hypervisor可以运行在Windows Server 2008上的Server Core上，这是仅仅支持命令行接口的一个最精简的Windows Server，一个没有GUI Shell但是可以运行GUI程序的诡异系统。

　　利用Server Core安装Hyper-V，好处很明显：GUI Shell去掉后，性能更好，而代码量最小之后，系统需要补丁的几率也就越小——我觉得这点最关键，谁都知道，微软的Windows绝对是补丁大王。