您现在所在的位置:首页 >> 通知公告 >> 通知公告 >>
发布日期:2014年10月21日
XenAccess介绍

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函数将内存进行映射。最后,结合系统内核结构体的偏移量读取指定的数据,即可完成重构。

注:XenAccess0.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.