1.Xen虚拟平台

Xen Hypervisor 位于操作系统与硬件之间，为其上层运行的操作系统内核提供虚拟化的硬件环境。Xen采用混合模式（Hybrid Model），因此在Xen上的多个Domain中存在一个特权域（Privileged Domain）用来辅助Xen管理其他Domain，提供相应的虚拟资源服务，特别是其他Domain对I/O设备的访问。这个特权域称为Domain 0（Dom0），而其他则成为Domain U（DomU）。Xen的体系结构如图1‑1所示。

图 1‑1 Xen体系结构

      Xen向Domain提供一个抽象层（包含管理和虚拟硬件的API）。其中，Dom0拥有真实的设备驱动（Native Device Driver，原生设备驱动），能够直接访问物理硬件。它负责与Xen提供的管理API交互，并通过用户模式下的管理工具来管理Xen的虚拟机环境，启动和停止其他Domain，并通过控制接口（Control Interface）控制其他Domain的CPU调度、内存分配以及设备访问，如物理磁盘存储和网络接口等。同其他虚拟机系统一样，在Domain中运行的操作系统称为客户操作系统（Guest OS，GOS）。

Xen的体系结构中包含控制接口、安全硬件接口、VCPU、虚拟MMU、事件通道、设备管理器、控制面板、原生设备驱动、前端/后端设备驱动和设备模型等多个关键模块。

1).控制接口

Xen提供的控制接口仅能被Dom0使用，用以帮助Dom0控制和管理其他的Domain。通过控制接口，Dom0不仅能够创建、销毁Domain，控制Domain的运行、暂停、恢复以及迁移，还能够实现对其他Domain的CPU调度、内存分配以及设备访问。

2).安全硬件接口

作为Xen的核心组件之一，安全硬件接口（Safe Hardware Interface）需要完成除虚拟CPU、MMU之外的所有的硬件虚拟工作，包括DMA、I/O、驱动程序、虚拟的PCI地址空间配置、虚拟硬件中断等。安全硬件接口只能被拥有原生设备驱动的Domain使用，向其他Domain仅提供虚拟硬件服务。这些工作是通过建立在拥有原生设备驱动的Domain和其他Domain之间的设备通道（Device Channel）完成的。设备通道并不是Xen系统中存在的独立概念，而是借由事件通道和共享内存实现的。其他Domain中的Guest OS通过设备通道向拥有原生设备驱动的Domain提交异步I/O请求，再由拥有原生设备驱动的Domain通过安全硬件接口完成请求。

3).VCPU

为了能够使运行在Guest OS中的应用程序能够正常执行，Xen为每个Domain建立了VCPU结构，用于接收Guest OS中传递的指令。其中，大部分指令都被VCPU直接交由物理CPU执行，而对于特权指令和临界指令则需要交由Xen内核代为执行。

4).虚拟MMU

虚拟MMU（Virtual MMU）被用来帮助Guest OS完成地址转换，即由虚拟地址到机器地址的转换。在Xen系统中增加了客户物理地址层，使得地址层由原来的二层结构变成三层结构，Xen即通过虚拟MMU完成地址转换。

5).事件通道

事件通道（Event Channel）是用于Domain和Xen之间、Domain和Domain之间的一种异步事件通知机制，用于处理Guest OS中的虚拟中断、物理中断以及Domain之间的通信等。

6).设备管理器

设备管理器（Device Manager）位于Dom0中，作为系统BIOS的拓展，用于向所有的设备提供一系列通用的管理接口。设备管理器负责在Domain启动时加载特定的设备驱动、建立管理设备通道、提供配置设备硬件的接口以及处理设备访问错误。

7).控制面板

控制面板（Control Panel）是运行在Dom0中的一系列控制软件的集合，用于Dom0同Xen中的控制接口交互，完成对整个Xen系统的管理工作，相当于系统的总控台。

8).原生设备驱动

原生设备驱动是指原来操作系统中使用的一般设备驱动。在Xen系统中，只有经过授权的Domain才有权使用原生设备驱动访问真实的硬件设备。通过支持原生设备驱动，Xen能够最大限度地利用原有操作系统中的设备驱动，减少Xen的开发难度，提高效率。

9).前端/后端设备驱动

前端/后端设备驱动（Front-end/Back-end Device Driver）共同组成了Xen的分离设备驱动模型（Device Driver Model），负责完成Domain对硬件设备的访问。其中，位于其他Domain内的前端设备驱动将I/O请求发送给位于Dom0内的后端驱动设备。后端驱动设备接收请求后，对其进行安全检查，然后将通过检查的I/O请求交由原生设备驱动处理。

Xen3.0版本引入硬件虚拟化技术，使得Xen能够支持不修改内核的Guest OS。运行未修改内核操作系统的Domain称为硬件虚拟机（Hardware Virtual Machine，HVM）或硬件虚拟域。运行在Xen之上的虚拟域包括四种类型：特权域、独立设备驱动域、硬件虚拟域、非特权域。

2.基于VMM的恶意软件检测模型

现有的安全软件采用基于主机的恶意软件检测模型，如图2‑1所示。模型主要运行于被监控主机内部，可以获取主机操作系统的详细信息，有助于准确检测恶意行为。但与此同时，正是由于基于主机的恶意软件检测模型处于目标系统内部，其自身的安全性容易受到恶意代码的影响，导致检测结果准确性降低。

随着云计算和虚拟化技术的发展，基于虚拟机监视器（virtual machine monitor，VMM）的恶意软件安全模型被提出，如图2‑2所示。VMM是位于硬件资源与操作系统之间的软件层，其为上层虚拟机（virtual machine，VM）提供抽象的硬件资源，并进行统一管理和监控。VMM在“隔离、检测、干涉”三方面的特性，使其为Rootkit等恶意代码的检测提供良好的平台。其中，“隔离”指客户操作系统（Guest OS）中的恶意代码无法渗透和攻击VMM和宿主系统；“检测”指VMM可以访问所有Guest OS的内存；“干涉”指VMM可以拦截Guest OS中的任意操作。

基于VMM的恶意软件检测模型被置于目标VM外部，利用VMM高于VM操作系统的权限和良好的隔离性有效抵御恶意代码的攻击，增强系统抗干扰能力，从而提高检测准确率。然而也正是因为VMM与Guest OS之间的隔离机制，导致VMM无法获取Guest OS中完整的视图信息，这也给恶意代码的防护带来极大的挑战。

图 2‑1 基于主机的恶意软件检测模型

图 2‑2 基于VMM的恶意软件检测模型

3.XenAccess（VMI）

3.1原理概述

2007年，佐治亚理工大学的Bryan D. Payne设计并实现了XenAccess开源函数库。XenAccess函数库基于以下6项基本设计原则。

1. 不允许大量修改VMM。VMM属于可信计算基的一部分，其设计初衷是使内核尽可能的简单，仅包括调度模块和控制模块等，删除任何冗余功能，从而减少可能的漏洞。如果VMM满足Rootkit等恶意软件检测的基本条件，则不应该再对VMM进行任何修改。如果VMM不满足Rootkit等恶意软件的检测条件，则应尽可能少地破坏VMM的原始架构。

2. 不允许修改VM或目标操作系统。由于Windows系列的操作系统本身不是开源的，所以针对VM或目标操作系统的修改在很多情况下是不现实的。另外，这种修改往往以增加额外的事件通道为代价，会破坏虚拟平台原始的隔离机制，从而引入新的安全威胁。

3. 较小的性能影响。这条原则保证检测模型的存在不能影响系统内程序的正常运行。

4. 支持检测功能的迅速开发和拓展。模型需要提供基础的API，可用于新功能的迅速开发。同时API的设计应尽可能简便，保证功能的可拓展性。

5. 支持对于目标操作系统内任意数据的检测。检测模型应具有目标操作系统的完整视图。

6. 目标操作系统无法对模型进行干扰或攻击。检测模型必须与目标操作系统隔离，从而保证安全性。如果模型的部分功能需要在可信计算基之外实现，那么需要采取额外的保护措施对这部分功能进行保护，并验证保护的完备性和有效性。

XenAccess支持对于VM系统内存和磁盘的检测，如图3‑1所示。针对内存检测功能，XenAccess首先通过System.map文件读取目标系统中IDT、GDT、system_call_table等关键数据的内存地址，进而利用xenstore和xenctrl函数库对目标系统的内存页进行映射并检测；针对磁盘检测功能，XenAccess利用用户层驱动Blktap，检测从目标系统前端驱动发出的磁盘操作请求，进而检测磁盘操作数据。

图 3‑1 XenAccess架构图

XenAccess提供的内存检测和映射API如下所示。

1.      xa_init():初始化指定VM的访问接口，获取相应的虚拟机基本信息，包括System.map文件地址、操作系统类型、xen版本等；

2.      xa_destory(): 释放与目标VM的访问接口；

3.      xa_access_kernel_sysmbol(): 基于内核符号地址，将目标VM的内存映射到Domain 0中进行访问；

4.      xa_access_virtual_address(): 基于内核空间的虚拟地址，将目标VM的内存映射到Domain 0中进行访问；

5.      xa_access_user_virtual_address(): 基于用户空间的虚拟地址，将目标VM的内存映射到Domain 0中进行访问。

XenAccess提供的磁盘检测和访问拦截API如下所示。

1.      xadisk_init(): 打开FS镜像文件，并初始化库函数的主要数据结构；

2.      xadisk_destory(): 关闭镜像文件，释放全局结构体的空间；

3.      xadisk_set_watch(): 在指定文件系统目录设置监测点；

4.      xadisk_unset_watch(): 删除指定目录的监测点；

5.      xadisk_activate(): 创建线程并运行检测引擎；

6.      xadisk_deactivate(): 结束检测线程。

图 3‑2 XenAccess原理图

3.2内存映射

XenAccess利用内存映射的方法读取DomU中的内存数据。内存映射的方法主要是利用XenCtrl中的xc_map_foreign_range函数。针对读取数据类型的不同，可将映射的内容分为两种类型：数据和指针。

针对数据的映射方法如图3‑3所示，创建Dom0中的虚拟地址0xdddddddd和机器地址0xyyyyyyyy的映射关系，从而读取Dom U内存中的数据。

针对指针的映射方法如图3‑4所示，其方法要稍微复杂些。由于指针中包含的是数据的地址信息，因此需要通过两次映射才能获取目标数据。

图 3‑3数据内存映射

图 3‑4 指针内存映射

3.3进程链表重构

XenAccess函数库给出了重构进程链表的样例程序，其工作流程如所示。XenAccess在初始化过程中，获取XenCtrl的操作句柄，并逐步完成对xa_instance结构体的填充。之后，通过System.map读取init_task的虚拟地址信息。init_task标识系统进程链表的起始节点地址。根据该虚拟地址，通过页表的遍历获取其对应的机器地址，进而以该机器地址为参数利用xc_map_foreign_range函数将内存进行映射。最后，结合系统内核结构体的偏移量读取指定的数据，即可完成重构。

注：XenAccess到0.5版本后更名为libvmi，并在Google Code中进行更新和维护。http://code.google.com/p/vmitools/

参考文献：

[1]      Payne B D, Carbone M D P D, Lee W. Secure and flexible monitoring of virtual machines[C]. 23rd Annual Computer Security Applications Conference, Miami Beach, FL, United states, 2007: 385-97.

[2]    石磊, 邹德清, 金海. Xen虚拟化技术[M]. 武汉: 华中科技大学出版社, 2009.