Xen虚拟化在云安全中的技术原理与应用实践

Xen是一个基于x86架构的开源虚拟机软件。目前，Xen已应用于许多不同的商业和开源应用程序，如服务器虚拟化、基础设施即服务及桌面虚拟化。

1.Xen简介

Xen是由剑桥大学计算机实验室在2003年发布的一款基于32位x86架构的开源混合模式虚拟机监控器，支持同时运行100个虚拟机。此版本Xen的设计是基于半虚拟化技术实现，要求修改客户机操作系统。

由于Xen的虚拟化技术使虚拟化领域迈出了一大步，因此Xen的创始人成立了他们自己的公司XenSource（目前已被Citrix收购）。成立XenSource的目的是为了基于Xen VMM，为用户提供一个完整的虚拟化解决方案。

2005年，XenSource公司发布Xen 3.0，这是Xen真正意义上的第一个版本。该版本的Xen既能在32位的服务器上运行，同时该版本通过基于Intel和AMD公司的硬件辅助虚拟化技术Intel-VT和AMD-V实现了对硬件虚拟化的支持，大大提高了Xen的兼容性。从而能够运行未经修改的操作系统，即在硬件虚拟化的辅助下，支持完全虚拟化技术。这使得可以在Xen虚拟机中安装无须进行任何修改的Windows操作系统。这也是第一个需要Inter VT或AMD-V技术支持的版本。

Xen以高性能、占用资源少著称，目前已赢得了IBM、AMD、HP、Red Hat和Novell等众多世界级软硬件厂商的高度认可和大力支持，已被国内外众多企事业用户用来搭建云计算环境的虚拟化平台。比如Amazon EC2就是基于Xen。

2.Xen虚拟化架构

Xen 3.0采用了如图3-6所示的虚拟化架构^[20]。

图3-6 Xen 3.0虚拟化架构

在Xen虚拟化架构中，虚拟机被称为虚拟域（Domain）。在这些虚拟域中，虚拟域Domain 0（简称为Dom0）称为特权虚拟域，其他虚拟域Domain U（简称为DomU）称为非特权域，也称为普通域。Xen对控制信息和数据的传输是分开处理的。对于控制信息和消息，Xen提供了超级调用（Hypercall）和事件通道（Event Channel）机制。Hypercall类似于普通操作系统中的系统调用，虚拟机通过Hypercall能够完成相关的特权操作，如建立页表、访问I/O设备等。事件通道是一种异步消息通知机制，主要用于虚拟机和VMM之间的通信。对于数据的传输，Xen使用共享内存的方法，这是基于循环队列数据结构的生产者-消费者模型而实现的。通过页面映射和DMA操作可以实现数据的零复制，大大提升了系统性能。

从图3-6可以看出，在Xen虚拟化架构中，位于最底层的是物理硬件，包括CPU、内存和I/O设备等。

在底层物理硬件之上的是虚拟机监视器VMM（也简称为Xen）。它主要由控制接口、安全硬件接口、事件通道、虚拟CPU以及虚拟MMU组成。VMM模块主要用来向运行在它之上的虚拟机提供虚拟硬件资源，同时将客户操作系统的虚拟地址转换成真正的机器地址，并确保客户操作系统能够正确访问内存。

虚拟CPU用来向客户操作系统提供计算能力，对于客户操作系统来说，虚拟CPU就是未使用虚拟化技术时的物理CPU，客户操作系统所要执行的所有指令都需要交给虚拟CPU来处理，而每个客户操作系统可以拥有多个虚拟CPU。虚拟CPU所接收到的大多数客户操作系统指令都将由物理CPU直接来执行，个别特权指令将由Xen分析处理后再交由物理CPU执行。

由于Xen系统增加了伪物理地址空间，使得内存层次由原来的虚拟地址空间和物理地址空间两层变成了虚拟地址空间、伪物理地址空间和物理地址空间三层。其中，虚拟MMU用于帮助客户操作系统完成由虚拟地址到物理地址的三层转换。

控制接口供Dom0使用，用于使Dom0完成对DomU的控制和管理工作，包括DomU的创建、启动、停止、销毁、DomU的运行控制、CPU的调度、内存分配和设备访问等任务。

安全硬件接口供Dom0和IDD使用，用于完成除CPU和MMU以外的所有硬件虚拟工作，如虚拟硬件中断和驱动程序等，这些工作共同向DomU提供了虚拟硬件服务。

事件通道提供了各个虚拟域之间、各个虚拟域与Xen之间的一种异步事件通知机制，主要实现了Xen体系结构中的各种中断（包括虚拟中断、物理中断和虚拟处理器间中断）和域间通信机制。

在Xen VMM层之上的是各个虚拟域。在Xen中，虚拟域划分为如下四种类型：

（1）特权域Dom0 在Xen系统中有且只能有一个特权域Dom0，它随着Xen的启动而启动。它由后端设备驱动、原生设备驱动、设备管理器、控制软件和设备模型等模块组成。后端设备驱动用于接收来自客户操作系统的设备操作请求；原生设备驱动用于使用操作系统原有的设备驱动对真实的物理设备进行直接访问，从而完成已经过Xen授权的客户操作系统请求；设备管理器用于完成设备的初始化和管理设备访问的相关工作；控制软件利用Xen所提供的控制接口完成对其他域的管理工作，如域的配置、创建、销毁、迁移、启动和停止等，还能对某些域进行授权，使它们能够使用指定的原始设备驱动访问部分真实硬件；设备模型的主要功能是等待来自HVM域的I/O请求，并把请求转发给相应的设备模拟模型。

总之，Dom0用来协助Xen完成对其他虚拟域的管理操作，提供相应的虚拟资源服务。

（2）独立设备驱动域IDD Xen只有一个特权域Dom0，所有硬件设备都需要同Dom0交互。因此，Dom0需要完成的工作既繁冗又复杂，为了能够减轻它的工作负载，也为了避免由于部分设备驱动的缺陷导致Dom0崩溃，进而导致Xen整体宕机。Xen将设备驱动由Dom0中迁移到另一个域中，建立经过Dom0授权的、可以使用特定设备驱动的虚拟域IDD。这样就减轻了Dom0的运行压力，增强了系统的健壮性。

总之，IDD主要用于协助Dom0完成对指定硬件设备的访问。

（3）硬件虚拟域HVM 利用Intel或AMD厂商提供的硬件虚拟化技术，以全虚拟化模式运行未修改内核的客户操作系统。

Xen在Dom0域专门为HVM开发了一个设备模型，用来为虚拟机的虚拟物理设备，实现物理设备的共享。设备模型的实现借鉴了由Fabrice Bellard所编写的模拟处理器的开源软件QEMU。它向HVM提供了虚拟的硬件平台，包括键盘、鼠标、光驱、硬盘、图形卡、声卡和串口等。

设备模型还提供分发机制，通过事件通道实现设备模型和VMM之间的通信，以及设备模型和HVM域的通信。设备模型还通过Hypercall把虚拟域的地址空间映射到自己的进程空间，当I/O请求完成时，设备模型可以把数据访问结果复制到虚拟域中。

（4）普通域DomU 严格地讲，除Dom0之外的所有域都是DomU，但是IDD经过授权后能够直接使用物理设备驱动，因而IDD也属于特权域。无论是HVM还是DomU都不能直接访问物理设备，必须借助Dom0或者IDD才能完成硬件访问，即需要通过前端设备驱动程序向后端设备驱动程序发送操作请求来完成。这些限制避免了各个域都能对硬件访问时可能造成的混乱，保证了域间的隔离性。在这种分离式的设备模型中，前端设备驱动只需完成I/O请求或数据的转发，设计和实现比较简单。

Xen通过上述这些组成部分的通力协作，成功完成x86架构的虚拟化工作。

3.Xen半虚拟化实现

（1）CPU虚拟化 在x86架构下，CPU提供四个不同硬件特权级别。编号为从Ring0（最高特权）到Ring3（最低特权）。目前大多数操作系统只使用了0环和3环这两个特权级，操作系统代码主要在Ring0上执行，因为没有其他的环可以执行特权指令。而Ring3通常用于执行应用程序代码。如图3-7a所示。

在Xen的体系结构中，VMM拥有最高特权级，它替代了操作系统内核，占用了0环，具有最高权限。客户操作系统从0环降到1环。应用程序仍运行在3环上，如图3-7b所示。这就防止了客户操作系统会直接执行特权指令，也保证了操作系统与应用程序之间相隔离的安全性。

图3-7 系统运行特权级

a）无虚拟化 b）半虚拟化特权级环(www.chuimin.cn)

由于客户操作系统的特权级只有Ring1，因此，当客户操作系统执行特权指令时，由于权限不够，会自动触发陷阱，CPU会保存当前各寄存器的状态并将控制权交给相应的异常处理程序。Xen可以通过这种硬件保护机制捕获客户操作系统调用的特权指令。对于调用特权指令的客户操作系统内核代码，只需将其替换成Xen提供的超级调用（Hypercall）。

异常的处理过程可以描述为：客户操作系统通过Hypercall注册异常向量表，VMM将客户操作系统传来的异常向量表存入每个虚拟CPU的一个数据结构中，然后将自己的异常向量表放到真实的CPU上。当异常发生时，首先陷入VMM，调用Xen自己的异常处理函数，Xen的异常处理函数根据需要经过一些特别的操作之后，在客户操作系统建立异常处理函数的栈框，同时修改自己的栈框，将返回目标设置为客户操作系统之前注册的异常处理函数，从而给客户操作系统模拟了一次异常。这样，客户操作系统就可以按照普通的操作系统处理异常的方式来进行处理。由于异常处理需要在客户操作系统和VMM之间进行切换，开销比较大。

（2）内存虚拟化 Xen采用分块共享的方式来虚拟计算机的物理内存，即将机器的内存分配给各个虚拟机，并维护机器内存和虚拟机的“物理内存”间的映射关系。内存地址的层次由原来的虚拟地址和物理地址两层增加为客户操作系统中的虚拟地址VA、物理地址PA和机器地址MA三层。为了区分PA与普通操作系统中的物理地址，也有人把这个地址称为伪物理地址。

内存虚拟化主要解决的就是三层地址转换问题。为此，Xen提供了直接模式和影子模式两种地址转换的方法。

半虚拟化一般采用如图3-8所示的直接模式。

图3-8 直接模式

由于对客户操作系统内核进行了修改，客户操作系统知晓VMM的存在，因此可以在客户操作系统建立的页表中直接存放VA和MA的映射，并让MMU使用，完成VA和MA之间的地址转换。在这种模式下，Xen先将客户操作系统的页表映射为只读，即虚拟机可以直接读取自己的页表，但当客户操作系统第一次试图修改其页表时将产生页错误，从而陷入VMM，VMM中的Virtual MMU模块调用相应的异常处理函数。主要操作是将该页从页表层次结构中卸下，并映射为可写，以后对此页的更新操作不会触发页错误，最后当TLB快表刷新时，将该页再次挂回到页表层次结构中。

在半虚拟化中，客户操作系统的页表被设为写保护，这样每当客户操作系统试图修改其页表时就会产生异常。

（3）I/O虚拟化 除了CPU和内存，计算机的运行离不开I/O设备。同样的，虚拟机的运行也离不开虚拟平台上的各种I/O设备。实际上，要为虚拟机虚拟出I/O设备是比较有难度和挑战性的。首先，I/O设备种类繁多，如鼠标、显示器、键盘、硬盘、网卡和显卡等。即使是同类设备，由于开发商和编程接口不同，也会存在各种差异。其次，从虚拟机的性能方面考虑，虚拟I/O设备带来的开销不能太大，否则将会严重影响系统的性能。

在Xen中，只有Dom0和IDD拥有真正的I/O设备驱动和访问这些设备的权限，其他虚拟机只拥有虚拟的设备，如虚拟网卡和虚拟块设备。

在半虚拟化下，Xen采用分离设备驱动模型来实现I/O虚拟化，如图3-9所示。

图3-9 半虚拟化下I/O设备虚拟化

Xen将设备驱动分为前端设备驱动、后端设备驱动和原生设备驱动。前端设备驱动在DomU中，后端设备驱动和原生设备驱动在Dom0和IDD中。前端驱动以事件通道的方式通知后端驱动需要服务，并把I/O请求通过共享内存机制请求传递给Dom0或IDD中的后端设备驱动，后端设备驱动负责接收这些I/O请求，确认它们是否安全，然后解析收到的I/O请求并映射到实际物理设备，最后交给它的原生设备驱动程序来控制硬件完成I/O请求。当I/O操作完成时，后端驱动以事件通道方式通知前端请求已经完成，并把数据放到共享内存中。前端驱动再通知客户操作系统内核I/O请求已经完成，由内核对结果进行处理。

前端设备驱动实际上是一个伪驱动（Pseudo Driver），它的功能是将I/O请求经过VMM传递给Dom0或IDD上真正的驱动程序。它只是处理数据和消息的转发，设计得比较简单。但后端设备驱动比较复杂，它需要翻译设备地址，确认请求的形成，保证设备访问的安全性等。

4.Xen全虚拟化实现

下面分别从CPU虚拟化、内存虚拟化和I/O虚拟化三个方面出发，探讨在Intel VT-x的辅助下，Xen是如何实现全虚拟化的HVM的。

（1）CPU虚拟化 Intel VT-x对处理器进行了扩展，为CPU增加了一种新的处理器操作，称为VMX（Virtual Machine eXtensions），引入了两种新的CPU工作模式，VMX根（Root）模式和VMX非根（Non-Root）模式。

如图3-10所示，通常VMM（包括Dom0）运行在根模式，其中Xen在0环（0P），Dom0在1环（1P），应用程序在Ring 3。而HVM在非根模式下运行，其中客户操作系统运行在0环（0D），应用程序在3环（3D）。

图3-10 硬件虚拟化下的特权级环

根模式与传统的x86工作模式没有太大的差别，只是引入了一些新的支持VMX的指令。而非根模式是在VMM控制管理下的x86环境，非根模式的处理器行为是受限的。某些VMM设定的指令、事件或状态会导致虚拟机退出到VMM，以确保VMM对系统的完全控制，但客户操作系统并不知道自己运行在虚拟机中。无论是根模式还是非根模式，都支持传统的四个特权级：Ring0～Ring3。这样就能支持不修改的操作系统和应用程序，非根模式下的操作系统虽然运行在Ring0上，但实际上却受根模式的VMM所掌控。

当虚拟机运行过程中需要Xen监控和处理敏感指令时，处理器会发生非根模式到根模式的切换，称为VMExit，这时VMM从VM夺回控制权。Xen处理完成后从根模式切换到非根模式，称为VMEntry，这时控制权从VMM转交给VM。根模式和非根模式的切换是通过新增的CPU指令来完成的。另外，VMEntry和VMExit发生时都会重新加载用于控制和确定处理器的操作模式以及当前执行任务的特性的x86的控制寄存器CR3，从而使得VMM和VM运行在不同的地址空间，有效地解决了隔离保护问题，提高了系统的稳定性。

正是由于VT-x的两个工作模式的思想，使得VMM既能运行在0环也能使客户操作系统运行在0环。

（2）内存虚拟化 在引入硬件虚拟化后，Xen支持不用修改内核的操作系统，但必须使用影子模式完成地址转换。如图3-11所示，在全虚拟化下，VMM对HVM的客户操作系统是透明的，HVM不知道自己运行在虚拟环境中。客户操作系统看到的内存是VMM为其分配的物理地址，而且是一段连续的空间，客户操作系统负责维护虚拟地址VA到物理地址PA的转换页表，而VMM负责维护物理地址PA到真实的机器地址MA的映射，VMM维护的这个页表就是全虚拟化中的“影子页表”（影子页表只是对实际页表的一个备份和实时复制），虚拟机看到的就是这个影子页表，VMM负责维护这个影子页表，包括PA到MA的转换以及页表的同步等。HVM可以把更新操作设为触发VMExit的条件，当虚拟机需要更新页表时，处理器会切换到根模式，然后Xen对影子页表进行修改，使影子页表和虚拟机操作系统页表保持一致。

图3-11 影子页表

对全虚拟化的客户操作系统而言，除去CR3寄存器是虚拟的以外，其他页表结构和通常的操作系统没有区别。

（3）I/O虚拟化 在全虚拟化下，Xen采用设备模型为未修改内核的虚拟机操作系统提供I/O设备抽象，如图3-12所示。客户操作系统借助这些设备模型来完成I/O访问，当HVM访问I/O设备时就会从非根模式切换到根模式，此时HVM处于I/O阻塞状态，运行在根模式的Xen将I/O请求转给Dom0，Dom0使用设备模块和驱动程序进行处理，完成之后再通过事件通道通知Xen，然后解除HVM的阻塞，以共享内存的方式返回结果。

图3-12 全虚拟化下I/O设备虚拟化