XHydra：面向虚拟机Xen的安全增强架构*

杨　杰，朱智强

1.解放军信息工程大学密码工程学院，郑州4500012.解放军信息工程大学科研部，郑州450001

ISSN 1673-9418 CODEN JKYTA8

Journal of Frontiers of Computer Science and Technology 1673-9418/2016/10(03)-0311-15

http://www.ceaj.org Tel: +86-10-89056056

* The National High Technology Research and Development Program of China under Grant No. 2012AA012704 (国家高技术研究发展计划(863计划)).

Received 2015-07,Accepted 2015-10.

CNKI网络优先出版: 2015-11-02, http://www.cnki.net/kcms/detail/11.5602.TP.20151102.1547.006.html

XHydra: Xen-Based Virtual Machine Architecture for Enhancing Xen Securityƽ

YANG Jie1+, ZHU Zhiqiang21. Cryptography Engineering Institute, PLAInformation Engineering University, Zhengzhou 450001, China2. Scientific Research Department, PLAInformation Engineering University, Zhengzhou 450001, China+ Corresponding author: E-mail: isyangjie@sina.com

YANG Jie, ZHU Zhiqiang. XHydra: Xen-based virtual machine architecture for enhancing Xen security. Journal of Frontiers of Computer Science and Technology, 2016, 10(3)：311-325.



XHydra：面向虚拟机Xen的安全增强架构*

杨杰1+，朱智强2

1.解放军信息工程大学密码工程学院，郑州450001
2.解放军信息工程大学科研部，郑州450001

ISSN 1673-9418 CODEN JKYTA8

Journal of Frontiers of Computer Science and Technology 1673-9418/2016/10(03)-0311-15

http://www.ceaj.org Tel: +86-10-89056056

* The National High Technology Research and Development Program of China under Grant No. 2012AA012704 (国家高技术研究发展计划(863计划)).

Received 2015-07,Accepted 2015-10.

CNKI网络优先出版: 2015-11-02, http://www.cnki.net/kcms/detail/11.5602.TP.20151102.1547.006.html

XHydra: Xen-Based Virtual Machine Architecture for Enhancing Xen Securityƽ

YANG Jie1+, ZHU Zhiqiang2
1. Cryptography Engineering Institute, PLAInformation Engineering University, Zhengzhou 450001, China
2. Scientific Research Department, PLAInformation Engineering University, Zhengzhou 450001, China
+ Corresponding author: E-mail: isyangjie@sina.com

YANG Jie, ZHU Zhiqiang. XHydra: Xen-based virtual machine architecture for enhancing Xen security. Journal of Frontiers of Computer Science and Technology, 2016, 10(3)：311-325.

摘要：针对开源虚拟化平台Xen的管理虚拟机Dom0服务臃肿和可信计算基庞大等问题，提出了一种基于Xen的安全虚拟机架构XHydra。该架构采用微内核的设计思想和最小特权安全理论，将Dom0分离成多个功能独立、相互隔离且具有最小特权的迷你服务域，并设计了一个服务监视器进行管理。服务监视器通过构建用户虚拟机与迷你服务域之间设备通信的专用通道，实现用户虚拟机和迷你服务域之间的双向隔离。最后基于Xen4.4开发了XHydra的原型系统，提高了平台的安全性，验证了架构的可行性。同时，针对虚拟化平台的存储性能和网络性能进行基准测试，实验结果表明所提方案性能相对于原始Xen仅降低了3%。

关键词：Xen；安全虚拟机；最小特权；服务分离；Dom0虚拟化；XHydra

1　引言

云计算[1-4]利用虚拟化技术将大规模的数据中心以基础设施即服务（infrastructure as a service，IaaS）、平台即服务（platform as a service，PaaS）、软件即服务（software as a service，SaaS）的形式出租给付费用户，云计算服务提供商通过虚拟化技术让多个客户操作系统共享同一台物理主机，为多租户提供服务。在这种多租户环境下，云计算通过虚拟化的“服务整合”，有效降低了企业的运营成本，提高了管理效率，使得大量企业将其线上应用部署到IaaS。但这些都基于同一个前提——虚拟化平台能保证同一台物理主机上的不同虚拟机（virtual machine，VM）之间不能进行违反安全策略的相互访问或干扰。

虚拟化技术作为云计算的重要组成部分，用户越来越看重它们的安全性。然而虚拟化平台能否满足用户的安全需求仍值得商酌。支持者认为虚拟机监视器Hypervisor[5-6]作为整个虚拟化平台的核心，相比于服务器操作系统，具有较小的可信计算基[7]（trusted computing base，TCB），且只提供少量的核心接口，因此其被认为是安全可信的。实际上，虚拟化平台的安全性并不是仅由Hypervisor决定的，它还包括除Hypervisor外的Administrative VM（管理虚拟机）的安全性。Administrative VM管理Guest VM（用户虚拟机），提供设备仿真等虚拟化服务，同时向Guest VM提供了大量的接口，导致其一旦被攻击，会直接影响用户虚拟机的安全，因此虚拟化平台的TCB还应包括整个Administrative VM的TCB，如Xen[5-6,8-9]、KVM（kernel-based virtual machine）[10]、Hyper-V[11]等具有较小TCB的Hypervisor，但它们的TCB却要大于通用的服务器操作系统。虚拟化平台的TCB的大小并不能直接代表其面临的风险，但平台中各客户虚拟机依赖的Administrative VM不仅增大了平台的TCB，而且还包含大量具有较高特权且安全隔离性弱的虚拟化服务，直接影响虚拟化平台的安全。如在Xen中，Dom0包含着系统引导、设备仿真、网络、存储、管理工具和XenStore等虚拟化服务，一旦其中一个服务被攻击，将导致整个平台陷于危险之中。综上可得，如今常用的虚拟化平台面临着严重的安全威胁，即巨大的攻击表面和庞大的TCB。

操作系统的研发历史针对系统TCB庞大的问题提出了一种解决方案，即将系统分离成相互独立的多个服务，这些服务相互隔离且仅拥有其完成相应功能的最小特权。由于虚拟化平台和操作系统都是管理硬件资源的系统软件，该方案同样可用于解决虚拟化平台TCB庞大的问题。同时，操作系统的开发实践表明，将系统的安全性贯穿于系统的整个生命周期才能最大限度保证系统的安全性，如安全操作系统sel4[12-13]。可以看出，对虚拟化平台架构的重新设计是提高其安全性的有效途径之一，但这可能降低其整体功能特性，而无法满足商用环境的需求，如安全虚拟机架构Nova[14]、BitVisor[15]等。

针对虚拟化平台TCB庞大，攻击表面巨大和全新设计平台架构会损害系统功能完整性等问题，本文在Xen的基础上，提出了一种基于Xen的安全虚拟机架构XHydra。该架构在不改变原有虚拟化平台的功能和应用接口的基础上，将Administrative VM分离为相互独立的服务，并利用相互隔离且特权最小的迷你服务虚拟机（mini-service VM，简称迷你服务域）来承载相应的服务。同时，根据Administrative VM的功能接口及它与Hypervisor、Guest VM之间的关系设计了一个虚拟服务监视器Hydravisor。XHydra通过Hydravisor实现对Administrative VM的虚拟化，用户虚拟机与迷你服务域之间的双向屏蔽，迷你服务域管理和用户虚拟机与迷你服务域间的设备通道管理。最后，基于最小特权安全理论和Xen的安全模块XSM（http://wiki.xensource.com/wiki/Xen_Security_ Modules_:_XSM-FLASK）设计了XHydra安全模块，实现了虚拟机粒度的强制访问控制，保证了迷你服务域和Guest VM仅拥有其被赋予的特权，进一步增强了平台的安全性。

2　相关工作

随着虚拟化技术应用范围的扩大，虚拟化平台的安全性得到了深入的研究，相关研究人员提出了多种减小平台TCB和增强平台安全性的解决方案，主要分为以下3种类型。

（1）构建轻量级虚拟机监视器。SecVisor[16]和BitVisor是以系统TCB的大小作为主要评估对象而设计出的轻量级虚拟机的代表。它们利用虚拟机监视器的“干涉”能力来增强商用操作系统的安全特性，但它们不具备商用虚拟机监视器可用于多租户共享的特性，也不适用于多租户共享的应用场景。

Zhang等人提出的CloudVisor[17]利用嵌套虚拟化技术将用户与虚拟机之间以及虚拟机与云操作员之间进行隔离；其次将云操作员所能接触到的数据全部加密，使得操作员接触到的数据均为密文，且具有非常小的可信计算基。但它以硬件虚拟化为基础，不能支持半虚拟化技术，并且依赖于嵌套虚拟化，有一定的性能损耗。

Nova将Administrative VM从系统中移除，并明确地将系统的TCB分离到虚拟机监视器的多个用户进程中。但它存在以下3点不足：首先，由于它需要提供硬件驱动而导致Hypervisor的TCB陡增；其次，它虽然支持同时运行多个不需修改内核的客户操作系统，但并不支持Windows系统；最后，相比于其他架构，它的工具栈功能非常有限。

NoHype[18]提倡将虚拟机监视器整体移出虚拟化平台，并利用静态分离技术将CPU、内存和其他外围设备分配到各个虚拟机。这虽然可以使多个操作系统同时共享一台物理主机，但失去了虚拟化技术的其他优势，如热迁移、内存共享等。

（2）增强TCB组成部分的安全性。对于虚拟化平台TCB的独立组成部分的安全性，可以通过提高其代码的质量和引入访问控制限制其拥有特权来增强。如XenServer（http://xenserver.org/）的XAPI[19]工具栈就利用OCaml[20]言语的静态类型来提高它的健壮性；Xen和Linux分别通过XSM与SELinux（https:// www.nsa.gov/research/selinux/）实施细粒度的访问控制来实现系统安全性增强，但这些技术都不关注整个系统TCB的大小。

（3）分离虚拟化平台TCB，减小每个组成部分的特权。Murray等人将虚拟机创建服务Builder移植到一个隔离特权虚拟机中[21]，从而将Dom0的用户空间从Xen的TCB中移除。但是Dom0的内核空间仍是TCB的一部分，其暴露的接口仍给系统留下安全隐患，如Dom0中的网络驱动。Qubes-OS（https://www. qubes-os.org/doc/SystemDoc/）将网络驱动、设备模型QEMU[22]从Dom0中分离出来，增强了桌面操作系统的安全性和隔离性。Butt等人提出的SSC[23]将Dom0分离成系统级Dom0和用户级Dom0，有效防止了内部攻击，解决了虚拟机管理不灵活的问题。Colp等人提出的Xoar[24]架构，从空间和时间上将Dom0彻底地分离为相互隔离的9部分，并限制每部分的特权，减小了系统的TCB。但它的分离策略相对固定，系统配置管理复杂，降低了系统的灵活性，难以实现虚拟机迁移需求。

3　安全虚拟机架构XHydra

本文在开源虚拟化平台Xen的基础上仿照Hydra （http://en.wikipedia.org/wiki/Lernaean_Hydra）的生理特征设计了一个虚拟机安全架构XHydra1））安全虚拟机架构XHydra的名称来源于古希腊神话故事中的九头蛇Hydra（海德拉），Hydra共有9个头，其中的8个头杀掉后会重生，而中间的那个头却“刀枪不入”。，其主要有以下4个安全目标：

（1）减小系统的TCB。整个虚拟化平台的TCB由虚拟化平台的核心模块TCB组成，且其大小不受与其关联的服务或应用的安全性影响。

（2）减少组件特权。系统中的每个组件只能拥有完成其相应功能的最小特权，同时只向其他组件或应用提供能完成相应功能的最小接口集，有效限制了攻击表面，降低了一次成功攻击带来的危害。

（3）实现迷你服务域和用户虚拟机之间双向屏蔽。在XHydra中，迷你服务域和用户虚拟机都不知道对方的存在，也不能区别它们所处的虚拟化环境是Xen还是XHydra，有效隔离了服务域和用户虚拟机之间的攻击流。

（4）不改变系统的易用性。系统提供给上层应用的接口不变，保证原始应用能够方便快速地迁移到新平台上，有利于新平台的推广应用。

3.1威胁模型

为了保证本文设计的架构安全可靠和设计思路清晰明确，进行以下若干假设。

（1）假设虚拟化平台的Hypervisor是一个设计完美，实现正确，足够小且可验证的安全软件层，能够保证虚拟机运行环境之间的内存隔离、CPU隔离和其他通信机制等的隔离，且能限制虚拟机对物理资源和特权管理接口的访问，但其无法保证虚拟运行环境之间I/O的有效隔离。

（2）假设虚拟化平台的服务虚拟机提供的功能组件中存在Bug，且会给系统带来安全威胁。若这些Bug被恶意利用，会威胁依赖于该功能组件的Guest VM的安全。众所周知，Bug是无法完全消除的，因而本文提出的架构将它们隔离到系统安全边界外。

（3）假设Guest VM不是系统TCB的一部分，用户可以在Guest VM上发起任意恶意攻击，且对其没有任何“知识”要求。同时，本文不考虑虚拟化平台管理员引入的安全威胁。

3.2 XHydra总体架构

在Xen中，由于系统管理员完全控制运行于同一台物理主机上的所有虚拟机，很难使用户相信虚拟机的机密性和完整性没有被破坏，这在一定程度上阻碍了Xen虚拟化方案应用于对安全性要求较高的环境。

本文基于服务虚拟化模型提出的安全虚拟机架构XHydra如图1所示。相比于Xen，XHydra中的服务监视器Hydravisor及其管理的迷你服务域Mini-Service Domain代替了Xen架构中的Dom0，同时替换了Xen Hypervisor中的安全模块。

XHydra将Dom0分离为多个Mini-Service Domain。Mini-Service Domain是指承载某项虚拟化服务，且仅拥有支持该虚拟化服务运行的最小运行环境的虚拟机，又称迷你服务域。如网络域是将Dom0中的网络服务分离出来而成的迷你服务域，其被Hypervisor授权在Intel VT-d[25]或AMD IOMMU[26]等硬件虚拟化技术支持下直接访问物理网卡，为多个DomU（用户域）提供网络服务。同时，为了避免恶意软件或冗余功能代码给Mini-Service Domain带来安全威胁，Mini-Service Domain除了包含实现其被赋予的服务功能的代码外，不包含其他无关代码。对于每一个全虚拟化虚拟机HVM，XHydra都提供一个设备模型域为其专职提供设备虚拟化服务。

Hydravisor主要管理迷你服务域，并为用户域虚拟一个与Dom0无差别的交互环境，同时实现迷你服务域和用户域之间的双向屏蔽。其根据既定的服务分离方案动态创建迷你服务域，并将相应的硬件设备分配给对应的迷你服务域，生成服务信息页，构建虚拟服务模型，从而完成对Dom0的虚拟化。同时，当创建用户域或进行一次新的服务分离方案部署时，Hydravisor需要创建用户域和迷你服务域之间的设备连接，并对这些设备连接进行监控，确保其安全可靠。最后，Hydravisor根据各用户域对I/O资源的访问请求状况，通过Hypervisor调度迷你服务域来响应用户域的I/O访问请求。

XHydra架构仍基于Xen Hypervisor，对Hypervisor不做任何功能性的修改，仅替换了其原有的安全模块，保证了Hypervisor提供给虚拟机的接口不变，且保证了迷你服务域有且仅有完成其被赋予的服务功能所需的最小特权。同样，XHydra使用与Xen完全一样的一个包含如虚拟机内存、CPU等运行时参数的配置文件来描述用户域。当创建用户域时，它们都使用管理工具栈（toolstack）来解析该配置文件，并根据解析的参数来为该用户域构建运行环境。但XHydra在构建用户域运行环境时需要Hydravisor完成其中的I/O运行环境的构建，使用户域“认为”其运行于Xen上。而且，XHydra提供的管理接口与Xen无异。

Fig.1　 Overall of XHydra architecture图1　 XHydra总体架构

3.3 XHydra服务分离

在Xen虚拟机架构中，Dom0作为系统的特权域，为虚拟机系统提供了如I/O虚拟化、XenStore、管理工具栈和Domain Builder等服务。显然，将这些服务从Hypervisor中抽离出来，使其只提供如内存虚拟化、CPU虚拟化、虚拟机调度及事件通道等核心服务，将会有效降低Hypervisor的复杂度和减小攻击表面。

但Xen为了保证Hypervisor的安全性和可靠性，却使Dom0变得异常复杂和庞大。在Dom0中，既有位于内核空间的设备后端驱动等系统关键服务，也有位于用户空间，具有较高特权的工具栈，它们不论是自身存在Bug或遭受恶意攻击都会影响整个虚拟化平台的安全，因而Dom0的内核空间和具有特权的用户进程都是虚拟化平台TCB的组成部分，且增大了整个平台的攻击表面。

在XHydra中，针对原架构中Dom0给系统引入庞大的TCB和巨大攻击表面等问题，采用微内核的设计思想，将Dom0提供的服务按照一定规则进行划分，并用相互隔离的迷你虚拟机来承载这些新划分的服务，如图2所示。

Fig.2　 Service separation of XHydra图2　 XHydra服务分离示意图

（1）服务S（service）表示XHydra中辅助Hypervisor为用户提供一个完整的虚拟化平台的原子服务组件。其主要有安全属性SA（security attribute）和功能属性FA（function attribute）这两大属性。

（2）服务划分SP（service partitioning）表示XHydra中所有服务组成的集合的划分。XHydra中所有服务组成的集合用S′={S(S.SA,S.FA)}表示，若由服务组成的集合′,′′满足′′⊆′，′=′且′=∅, 1≤i,j≤l，则SP= {,′′}。

（3）XHydra服务分离方案SsS（service separation scheme）是指根据SA和FA对XHydra中的服务进行一次划分的方案。一种XHydra服务分离方案实际可以用一不存在冲突的服务划分来表示，记作SsS⇔SP。

系统管理员执行过程1即可产生其需要的XHydra服务分离方案，然后将生成的SsS部署到迷你服务虚拟机上。

过程1服务分离过程

1.将Dom0中的虚拟化服务按照功能特点和安全特点细化为原子服务S，得到服务集合S；

2. SP′:= Generate_Set_Partitionings(S)；

3. SsS := {}

4. For all SP in SP′

5. Find_SsS := true

6. For all S′in SP

7. If (Conflict_Detection (S′) == true) //检测服务之间是否存在安全或功能实现上的冲突

8. Find_SsS := false；

9. Break；

10. If (Find_SsS == true)

11. SsS := SsS∪{SP}；

SsS即为所有可用的服务分离方案的集合，Hydravisor根据SsS自行选择当前系统使用的服务分离方案。

3.4服务监视器Hydravisor

Hydravisor将迷你服务域虚拟化为Dom0，同时将Dom0虚拟化为迷你服务域，为用户域提供与Dom0无差别的服务接口，并实现迷你服务域和用户域之间的双向屏蔽。如图1所示，Hydravisor主要由虚拟服务仓库、虚拟服务控制器、服务域管理器、HydraStore和XHydra安全代理这5部分组成。其中虚拟服务仓库主要用于存储整个虚拟化平台所有虚拟服务和与虚拟服务相关联的信息。

3.4.1服务域管理器

服务域管理器（service domain manager，SDM）协同Hydravisor的其他功能组件管理虚拟服务承载虚拟机或服务域。SDM主要完成服务域创建、服务域重启、服务域关闭、服务域暂停、服务域恢复、服务域销毁和服务域调度等服务域管理任务。

服务域管理器根据XHydra服务分离方案创建服务域，并协同虚拟服务控制器实现服务域的全生命周期管理。同时，服务域管理器根据各虚拟服务上关联的设备通道的I/O状态来调度服务域，保证系统整体性能最优。

3.4.2 HydraStore

HydraStore在XHydra中承担系统配置信息的存储和管理任务，实现迷你服务域与用户域之间的双向屏蔽，并建立用户域和迷你服务域之间的服务依赖关系。

HydraStore的架构如图3所示，其主要由Xen-Store、服务依赖映射器和服务依赖仓库这3部分组成。其中，XenStore是将位于Xen虚拟化平台Dom0中的XenStore无差别地移植到Hydravisor中形成的，其提供给用户域和服务域的接口不变，即不需要对用户域和迷你服务域做任何修改。

虚拟服务（virtual service，VS）是指XHydra服务分离方案SsS的元素（简称服务项），该服务项由单独的迷你服务域承载。

服务依赖关系是指一个虚拟机的运行依赖于另一个虚拟机提供的虚拟服务，简记为SDR=domi≺domj，即虚拟机domi服务依赖于虚拟机domj。其中domj∈DomS∪{Hydravisor}，domi∈DomU∪DomS∪{Hydravisor}，DomS表示所有迷你服务域构成的集合，DomU表示所有用户域构成的集合。

在HydraStore中，XenStore仅仅记录了用户域服务依赖于Hydravisor (DomU≺Hydravisor)和Hydravisor服务依赖于服务域(Hydravisor≺DomS)的相关配置信息，且用户域和迷你服务域都只能通过XenStore提供的接口来获取它们所需的配置信息。同时，XHydra使用与Xen相同的配置文件来描述虚拟机，从而在XHydra中，Hydravisor和用户域、Hydravisor和迷你服务域之间互相可见，但用户域和迷你服务域不知道对方的存在。即从用户域来看，其无法分辨出运行环境是Xen虚拟化平台还是XHydra虚拟化平台，保证了XHydra与Xen之间的虚拟机无障碍迁移，并隔离了服务域和用户域之间的攻击流。

Fig.3　 Architecture of HydraStore图3　 HydraStore架构

服务依赖映射器利用虚拟服务模型中的服务分离方案和XenStore中记录的用户域配置信息将DomU≺Hydravisor映射为DomU≺DomS，然后对DomU≺Hydravisor和DomU≺DomS进行依赖关系计算得到Hydravisor≺DomS，并将其存储到XenStore中，以保证迷你服务域能够根据XenStore正确无误地提供相应服务。

服务依赖仓库存储着用户域和迷你服务域之间的依赖关系，以及基于该依赖关系下的设备依赖关系。服务依赖映射器实时监控XenStore中配置信息的变动，当配置信息改变时，其对变动的配置信息进行映射，并将映射结果记录在服务依赖仓库中，通知虚拟服务控制器服务依赖关系或该依赖关系下的设备依赖关系已改变。

3.4.3虚拟服务控制器

虚拟服务控制器（virtual service controller，VSC），是Hydravisor的控制中心，它直接管理虚拟服务模型中的虚拟服务及与虚拟服务相关联的设备通道（服务虚拟机后端设备与被服务的虚拟机前端设备之间进行通信的通道），并协同服务域管理器、Hydra-Store等组件共同完成对Dom0的虚拟化，其虚拟化过程如过程2所示。VSC与Hydravisor其他组件间的关系如图4所示。

过程2 Hydravisor虚拟化Dom0的过程

1.根据服务分离模型生成服务分离方案SsS ;

6. HydraStore完成DomU对DomS的服务依赖关系映射；

其中Admin表示虚拟平台管理员或具有特权的用户；形如AB的表达式表示A对B以∂实施控制θ，θ表示控制命令，∂表示控制参数；在形如β(α)的表达式中，α表征β的属性；形如ϕ||φ的表达式表示ϕ与φ之间是并列关系；形如{σ}表示与σ同一类型的所有实例的集合。

Fig.4　 Relationships between virtual service controller and other components of Hydravisor图4　虚拟服务控制器与Hydravisor其他组件间的关系

4　 XHydra安全模块

XHydra安全模块（XHydra security module，XHSM）在Xen安全模块XSM的基础上，引入具有高抽象策略的基于接口的访问控制模型，以确保迷你服务域、用户域仅拥有其被赋予的最小特权，同时简化安全策略和安全策略管理。

4.1基于接口的访问控制模型

基于接口的访问控制模型（interface based access control model, IFBAC）以最小特权安全理论为安全准则，根据主体的安全标识、接口的安全标识和访问控制策略决定主体能否访问相应接口。IFBAC实施强制访问控制，且其访问控制策略能直观地体现相应的安全目标。

（1）IFBAC元素

定义和说明如表1所示。

Table 1　 Elements of IFBAC and their descriptions表1　 IFBAC模型定义的部分元素及说明

（2）系统状态表示

系统状态由主体、客体、接口及标识主体、客体和接口的访问类属性函数组成，状态v∈V可用一个有序三元组(S,I,f)表示。定义规则γ为函数γ：R×V→D×V，即对给定请求和状态，规则γ决定系统产生的下一个响应和状态，其中判定集D中的yes表示该请求被执行，no表示该请求被拒绝，?表示规则γ不能处理该请求。

（3）安全状态定义

状态v=(S,I,f)是安全的，则当且仅当有s∈S⇒[I∈A(S)⇒fS⊳fI]成立，其中⊳表示前者支配后者，即f(S)⊇f(I)，A(S)表示能够被S访问的所有接口。

（4）状态转换规则

定义域：Ri=(Sj,Ik)∈R，R的定义域记为{ } R。

显然，根据系统安全状态定义，当主体Sj的安全级支配接口Ik的安全级时，Sj可调用Ik，且系统的状态仍然是安全的。

4.2 XHydra访问控制框架

XHydra访问控制框架如图5所示，其访问控制的粒度是虚拟机，并在主体对客体访问时，实施了两层访问控制。当主体S以接口I的方式访问客体O时，首先由访问控制点1判定主体S能否访问接口I，若能访问，则转向访问控制点2，由它判定主体S能否访问客体O，否则主体S不能以接口I的方式访问客体O。

Fig.5　 Architecture of XHydra access control module图5　 XHydra访问控制框架

访问控制点1采用基于接口的访问控制模型，在XHydra中IFBAC的主体为用户域或迷你服务域，接口为Hypervisor向虚拟机提供的超级调用，记为I∈{Hypercall1, Hypercall2, Hypercallq}，权限标识分别表示主体拥有的权限和访问接口需要的权限，记为P。每个主体可以拥有多个权限标识，而每个接口则有且仅有一个权限标识，同时它们权限标识的集合代表它们的安全标识。XHydra中权限标识划分示例如表2所示。

Table 2　 Example of permissions identification divisionof IFBAC in XHydra表2　 XHydra中IFBAC模型的权限标识划分示例

访问控制点2利用XSM中的Flask安全模块来实施访问控制，Flask相关安全定义和安全策略与其在XSM中的相关信息相同，因而不需要对其做任何改动。

5　 XHydra原型系统

本文基于开源虚拟化平台Xen4.4实现了XHydra的原型系统，能够良好地支持X86架构的CPU。由于Fedora（https://getfedora.org/）操作系统对Xen虚拟化平台支持较好，且Fedora Project开源社区允许用户自由修改和发布Fedora，因而采用Fedora20及其相应的开发工具和程序库来对XHydra原型系统进行开发工作。

5.1 XHydra服务分离

根据XHydra服务分离方案，将Dom0中承载的服务进行分离，并将分离后的服务部署到客户操作系统与服务相契合的虚拟机上。

XHydra原型系统根据过程1生成一种服务分离方案，在该方案中，分离出的服务、承载该服务的客户操作系统和服务的功能描述如表3所示，但其仅代表XHydra服务分离方案中的一种。

Table 3　 Service separation scheme of XHydra prototype表3　 XHydra原型系统服务分离方案

下面以Network Service分离为例描述服务分离实现的过程。首先定制承载Network Service的操作系统Fedora20，定制后的Fedora20中仅保留PCI前端驱动、物理网卡驱动、后端网卡驱动等驱动程序，libx-enstore.so、libxenlight.so等Xen运行环境依赖库，相关网络脚本和上述组件运行依赖的最小运行环境。随后通过PCI Service将物理网卡分配给网络域，最后创建网络域，并将相关信息注册到XenStore中，当其正常运行后即可提供网络虚拟化服务。

5.2 Hydravisor

Hydravisor是在Mini-OS（http://www.cs.uic.edu/~ spopuri/minios.html）的基础上实现的。Mini-OS是随Xen发布的一个运行在半虚拟化环境下的轻量级操作系统内核，它具有非常小的可信计算基，且已经实现了对XenStore的移植，可以有效地减少开发工作量。在Hydravisor的实现过程中，主要有两个关键点：

第一个关键点是实现用户域和迷你服务域之间的双向屏蔽。要实现迷你服务域和用户域之间的相互隔离，则要求用户域不知道为其提供服务的迷你服务域，同样迷你服务域也不知道它在为用户域提供服务，但依赖于XenStore构建的前后端驱动模型则要求迷你服务域和用户域之间知道对方存在，如用户域将内存页共享给服务域时，需要知道迷你服务域的ID。因而通过实现HydraStore，将用户域和迷你服务域之间的关系映射为用户域服务依赖于Hydravisor和Hydravisor服务依赖于迷你服务域，保证用户域将Hydravisor当作Dom0，而迷你服务域将Hydravisor当作用户域，很好地解决了关键点一面临的难题。实现HydraStore需要在XenStore的基础上添加480行ocaml代码，但对XenStore不做任何改变。

第二个关键点就是在第一个关键点的基础上如何实现用户域和迷你服务域之间的前后端设备通信。由于不能直接运用Xen的前后端驱动模型，又不能改变用户域原有的前后端通信机制，因而如图4所示，通过设备通道来同时实现对服务域的后端设备和用户域的前端设备的虚拟，即设备通道对于用户域是后端设备，而对于迷你服务域是前端设备，用户域与设备通道、设备通道与迷你服务域即可按照Xen前后端设备模型进行正常通信，从而避免了对前后端驱动的修改。但是不同的设备，其前后端驱动有一定的差异，因而为了适配不同的设备，需要实现与设备对应的设备通道，但有大于90%的设备通道代码可以重用。

6　 XHydra安全性和性能分析

6.1安全性分析

众所周知，系统安全研究中最大挑战就是对系统安全的评估，对于XHydra的安全性评估也不例外。针对这一难题，本文不直接对XHydra的安全性进行评估，而通过将其与Xen进行对比来评估安全性。主要通过对系统的TCB大小、攻击表面和系统的安全机制来对比分析XHydra的安全性，并通过模拟攻击实验证明安全对比分析的正确性。

在XHydra中，各迷你服务域对物理资源和虚拟资源的访问都要受到Hypervisor的控制，同时相互隔离的各迷你服务域仅具备完成相应功能服务的最小特权和支持服务正常运行的最小运行环境。Hydravisor实现了迷你服务域之间，以及迷你服务域和用户虚拟机之间的逻辑隔离。因而迷你服务域不应成为系统的TCB，而Hydravisor是实现Dom0虚拟化的核心，且具有较高的特权，所以Hydravisor应该成为XHydra的TCB的一部分。XHydra和Xen基于相同的Hypervisor，因而在除去Hypervisor的TCB的条件下，系统的可信计算基从原来Dom0的7 600 KLOC减少到Hydravisor的20 KLOC。

XHydra的各迷你服务域均按照其提供的服务进行细粒度剪裁定制，即除了该服务和支撑该服务运行的最小运行环境外，其他的所有软件和文件等都被移出迷你服务域。显然各迷你服务域的攻击表面仅来自于其承载的服务。而Dom0的攻击表面来源除了其承载的服务，还包括其他与虚拟化无关的进程和服务。因此，Dom0的攻击表面明显大于各迷你服务域的攻击表面，而且各迷你服务域的攻击表面被隔离，使攻击者更加难以实施攻击。

在Xen中，Dom0所有服务都运行在最高特权下，且从Hypervisor这一层很难对它们实施访问控制，其中一个服务被攻陷，则整个虚拟化平台就被攻击者控制，导致其停止提供服务，进而使其上运行的虚拟机被强迫关机下线，并且需要较长时间才能恢复。而在XHydra中，通过Hydravisor既能对服务实施访问控制，又可以通过XHydra安全模块限制各迷你服务域的特权。同时，Hydravisor可以隔离用户虚拟机与迷你服务域之间的双向攻击流，利用设备通道来避免由迷你服务域的崩溃而引发的虚拟化平台崩溃，且迷你服务域在崩溃后，将被其立即恢复到正常运行状态。

为了模拟Dom0和XHydra原型系统的网络域被恶意攻击后关机的场景，分别在Dom0和网络域植入具有root运行权限的自启动脚本hacker.sh，其代码如图6所示。当分别启动XHydra原型系统和Xen 10 min后，它们的运行状态如图7所示。其中，Xen直接关机停止运行，而XHydra原型系统仍正常运行，仅用户域约有40 s不能联网（网络域重启导致），但其网络连接显示正常（这是由于设备通道为用户域虚拟了后端虚拟设备，其仍可正常连接）。该模拟攻击实验很好地证明了上述安全分析的正确性。综上分析可知，XHydra的安全性相对于Xen有很大的提升。

Fig.6　 Code of attacking hacker.sh图6　模拟攻击脚本hacker.sh的代码

Fig.7　 States of Xen and XHydra when their servicedomains were attacked图7　 Xen和XHydra的服务域被攻击后各自状态示意图

6.2实验性能分析

由于XHydra相对于Xen虚拟化平台最根本的改变是通过Hydravisor实现了对Dom0的虚拟化，即XHydra利用Hydravisor和迷你服务域替换了Xen虚拟化平台中的Dom0，因而XHydra和Xen虚拟化平台的性能对比实验主要比较运行于它们之上的用户域虚拟机的I/O处理性能和服务域虚拟机的内存开销。本文所有实验的硬件环境为支持Intel VT-x的Intel Core i3-2130 3.39 GHz的四核处理器，Lenovo QiTianM4350主板，500 GB Western Digital磁盘和Realtek RTL8111/8186/8411网卡。性能对比实验的软件配置如表4所示。

Table 4　 Software configuration of performance comparison experiments between XHydra and Xen表4　 XHydra和Xen性能对比实验的软件配置

XHydra和Xen的客户域的配置均为2个虚拟CPU，1 GB内存，1个虚拟网卡和10 GB的虚拟磁盘。XHydra每个服务域配置1个虚拟CPU，内存的配置如表5所示，Hydravisor配置为128 MB内存和2个虚拟CPU；Xen中的Dom0配置4个虚拟CPU，1 GB的内存。

Table 5　 Memory configuration of Mini-ServiceDomains of XHydra prototype表5　 XHydra原型系统中各迷你服务域的内存配置

由表5可知在XHydra的原型系统中各迷你服务域和Hydravisor的内存开销总和为1 024 MB。其中不包括PCI Service Domain和Qemu Domain的内存开销，因为PCI Service Domain在服务分离完成后，则被Hydravisor销毁。同样Qemu Domain作为HVM的设备模型，其内存开销应该计入用户域的性能开销。XHydra原型系统中非用户域的内存开销和Xen 中Dom0的内存开销基本持平，当然XHydra的服务分离方案有很多种，其内存开销也各不相同，但都在用户可接受范围之内。

XHydra和Xen虚拟化平台的I/O性能对比实验主要对比它们的存储性能和网络性能。存储性能通过PostMark（http://openbenchmarking.org/test/pts/postmark）工具来测试，网络性能通过命令scp在千兆局域网环境下拷贝文件来测试。

PostMark是由著名的NSA软件承包商NetApp开发的一款用来测试产品后端存储性能的测试工具，主要用于测试文件系统在邮件系统或电子商务系统中的性能，而邮件系统和电子商务系统等应用是通过云计算进行服务整合的主要对象，因而通过PostMark的存储性能测试可以较好地反映虚拟化平台的存储性能。实验中，PostMark未改变的参数配置如表6所示，变动的参数取PostMark的3种经典配置参数，分别为表示初始创建文件数量的number和表示create/delete和read/append事务执行次数的transactions，分别取值为（1 000，50 000）、（20 000，50 000）和（20 000，100 000）。测试结果如图8~图13所示，无论是在半虚拟化环境下，还是全虚拟化环境下，XHydra的磁盘性能的各项测试结果相对于Xen的各项测试结果降低了1.0%～2.5%。同时，半虚拟化环境下的存储性能均优于全虚拟化环境下的存储性能，这是由于I/O虚拟化方式不同带来的性能差异。

Table 6　 Parameters configuration of PostMark表6　 PostMark未改变的参数配置

Fig.8　 Transactions performed per second in paravirtualization environment图8　半虚拟化环境下每秒执行的事务数量

Fig.9　 Transactions performed per second in full virtualization environment图9　全虚拟化环境下每秒执行的事务数量

Fig.10　 Data read per second in paravirtualization environment图10　半虚拟化环境下每秒读取的数据大小

Fig.11　 Data read per second in full virtualization environment图11　全虚拟化环境下每秒读取的数据大小

用Linux命令scp远程拷贝大小分别为512 MB 和2 GB的文件，并将文件分别写入到/dev/null（消除磁盘带来的影响）和磁盘，以文件拷贝速度来衡量网络的吞吐量。测试结果如图14和图15所示，在半虚拟化环境下，XHydra的网络吞吐量在各项测试中相对于Xen降低了2%～3%。在全虚拟化环境下，XHydra的网络吞吐量在某些测试中略低于Xen，在某些测试中还略高于Xen，这是由于将设备模型QEMU从Dom0中分离出来后带来的性能提升。

Fig.12　 Data written per second in paravirtualizationenvironment图12　半虚拟化环境下每秒写入的数据大小

Fig.13　 Data written per second in full virtualizationenvironment图13　全虚拟化环境下每秒写入的数据大小

Fig.14　 Network throughput in paravirtualizationenvironment图14　半虚拟化环境下网络吞吐量

Fig.15　 Network throughput in full virtualizationenvironment图15　全虚拟化环境下网络吞吐量

综上可得，XHydra的性能相对于Xen降低了大约3%，但XHydra相对于Xen给用户提供了更高的安全保障，在信息安全形式日益严峻的今天，损失不到3%的性能换来系统的安全性增强，对用户来说完全是可以接受的。

7　结束语

随着虚拟化技术的发展，虚拟化平台的安全已经成为人们关注的焦点。在现有虚拟化架构下，由于用户对更多企业级的虚拟化特性的需求不断增加，导致管理虚拟机臃肿复杂，给虚拟化平台带来了大量的安全风险和不稳定因素。

本文提出的安全架构XHydra采用微内核的设计准则和最小特权的安全思想，将Xen虚拟化平台的管理虚拟机Dom0虚拟为多个相互隔离且特权最小的迷你服务域，同时利用Hydravisor实现了用户虚拟机与迷你服务域之间的双向屏蔽。通过实验分析表明，在不改变任何功能特性和用户使用习惯的基础上，XHydra相对于Xen具有更小的可信计算基和更高的可靠性，但会有3%左右的性能损耗。XHydra虽然是基于Xen虚拟化平台设计实现的，但其设计思想仍可用于与Xen架构类似的虚拟化平台（如Hyper-V）的安全性增强。

由实验可知，XHydra原型系统的性能相对于Xen降低了3%左右，造成系统性能下降的原因除了系统实现外，主要是Hypervisor的调度算法与XHydra架构不相适应。同时，XHydra并不能防御来自内部的攻击，且目前支持的服务分离方案仅实现了两种，那么对系统的进一步完善和优化系统性能将是下一步需要进行的工作。

References:

[1] Gomes D G, Calheiros R N, Tolosana-Calasanz R. Introduction to the special issue on cloud computing[J]. Computers and Electrical Engineering, 2015, 42: 31-32.

[2] Lin Chuang, Su Wenbo, Meng Kun, et al. Cloud computing security: archtecture, mechnism, modeling[J]. Chinese Journal of Computers, 2013, 36(9): 1765-1784.

[3] He Wu, Xu Lida. A state-of-the-art survey of cloud manufacturing[J]. International Journal of Computer Integrated Manufacturing, 2015, 28(3): 239-250.

[4] Huo Zheng, Meng Xiaofeng, Xu Jianliang. Privacy-preserving query processing in cloud computing[J]. Journal of Frontiers of Computer Science and Technology, 2012, 6(5): 385-396.

[5] Barham P, Dragovic B, Fraser K, et al. Xen and the art of virtualization[C]//Proceedings of the 19th ACM Symposium on Operating Systems Principles, Bolton Landing, USA, Oct 19-22, 2003. NewYork, USA:ACM, 2003: 164-177.

[6] Pratt I, Fraser K, Hand S, et al. Xen 3.0 and the art of virtualization[C]//Proceedings of the 2005 Linux Symposium, Ottawa, Canada, Jul 20-23, 2005. New York, USA: ACM, 2005: 65-77.

[7] Mohanty S D, Thotakura V, Ramkumar M. An efficient trusted computing base for MANET security[J]. Journal of Information Security, 2014, 5(4): 192-206.

[8] Boen J. Researches on the virtual iecurity issues based on Xen cloud computing platform[J]. Applied Mechanics & Materials, 2014, 687: 2858-2861.

[9] Kumar P. Open source virtual machines on Xen: creation, implementaion and analysis[J]. Journal of Information Sciences and Computing Technologies, 2015, 3(1): 186-190.

[10] Kivity A, Kamay Y, Laor D, et al. KVM: the Linux virtual machine monitor[C]//Proceedings of the 2007 Linux Symposium, Ottawa, Canada, Jun 27-30, 2007: 225-230.

[11] Rzecki K, Niedźwiecki M, Sośnicki T, et al. Experimental verification of Hyper-V performance isolation quality level [J]. Computer Science, 2014, 15(2): 159-172.

[12] Murray T, Matichuk D, Brassil M, et al. seL4: from general purpose to a proof of information flow enforcement[C]// Proceedings of the 2013 IEEE Symposium on Security & Privacy, Berkeley, USA, May 19- 22, 2013. Piscataway, USA: IEEE, 2013: 415-429.

[13] Elphinstone K, Heiser G. From L3 to seL4 what have we learnt in 20 years of L4 microkernels?[C]//Proceedings of the 24th ACM Symposium on Operating Systems Principles, Farmington, USA, Nov 3-6, 2013. NewYork, USA: ACM, 2013: 133-150.

[14] Steinberg U, Kauer B. NOVA: a microhypervisor-based secure virtualization architecture[C]//Proceedings of the 5th European Conference on Computer Systems, Paris, France, Apr 13-16, 2010. New York, USA:ACM, 2010: 209-222.

[15] Hirano M, Chadwick D W, Yamaguchi S. Use of role based access control for security-purpose hypervisors[C]//Proceedings of the 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, Melbourne, Jul 16-18, 2013. Piscataway, USA: IEEE, 2013: 1613-1619.

[16] Sun Jianhua, Chen Hao, Chang Cheng, et al. Kernel code integrity protection based on a virtualized memory architecture[J]. Computing and Informatics, 2013, 32(2): 295-311.

[17] Zhang Fengzhe, Chen Jin, Chen Haibo, et al. CloudVisor: retrofitting protection of virtual machines in multi- tenant cloud with nested virtualization[C]//Proceedings of the 23rd ACM Symposium on Operating Systems Principles, Cascais, Portugal, Oct 23-26, 2011. New York, USA: ACM, 2011: 203-216.

[18] de Souza W, Tomlinson A. Understanding threats in a cloud infrastructure with no hypervisor[C]//Proceedings of the 2013 World Congress on Internet Security, London, UK, Dec 9-12, 2013. Piscataway, USA: IEEE, 2013: 128-133.

[19] Almurayh A, Semwal S. Controlling Xen cloud platform via smart phones[C]//Proceedings of the 2013 IEEE 14th International Conference on Information Reuse and Integration, San Francisco, USA, Aug 14-16, 2013. Piscataway, USA: IEEE, 2013: 676-683.

[20] Leroy X, Doligez D, Frisch A, et al. The OCaml system release 4.02[R]. Institut National de Recherche en Informatique et en Automatique, 2014.

[21] Murray D G, Milos G, Hand S. Improving Xen security through disaggregation[C]//Proceedings of the 4th ACMSIGPLAN/SIGOPS International Conference on Virtual Execution Environments, Seattle, USA , Mar 5- 7, 2008. NewYork, USA:ACM, 2008: 151-160.

[22] Liang Yi, Shao Yuanhua, Yang Guowu, et al. Register allocation for QEMU dynamic binary translation systems[J]. International Journal of Hybrid Information Technology, 2015, 8(2): 199-210.

[23] Butt S, Lagar-Cavilla H A, Srivastava A, et al. Self-service cloud computing[C]//Proceedings of the 19th ACM Conference on Computer and Communications Security, Raleigh, USA, Oct 16-18, 2012.

[24] Colp P, Nanavati M, Zhu J, et al. Breaking up is hard to do: security and functionality in a commodity hypervisor[C]// Proceedings of the 23rd ACM Symposium on Operating Systems Principles, Cascais, Portugal, Oct 23-26, 2011. New York, USA:ACM, 2011: 189-202.

[25] Yao Jiewen, Zimmer V J. White paper a tour beyond BIOS using Intel®VT-d for DMA Protection in UEFI BIOS. Intel Corporation, 2015.

[26] Malka M, Amit N, Ben-Yehuda M, et al. rIOMMU: efficient IOMMU for I/O devices that employ ring buffers[C]// Proceedings of the 20th International Conference on Architectural Support for Programming Languages and Operating Systems, Istanbul, Turkey, Mar 14-18, 2015. New York, USA: ACM, 2015: 355-368.

附中文参考文献：

[2]林闯,苏文博,孟坤,等.云计算安全:架构,机制与模型评价[J].计算机学报, 2013, 36(9): 1765-1784.

[4]霍峥,孟小峰,徐建良.云计算中面向隐私保护的查询处理技术研究[J].计算机科学与探索, 2012, 6(5): 385-396.

YANG Jie was born in 1990. He is an M.S. candidate at PLA Information Engineering University. His research interests include cloud security, virtualization security and computer security model, ect.杨杰（1990—），男，四川巴中人，解放军信息工程大学硕士研究生，主要研究领域为云安全，虚拟化安全，计算机安全模型等。

ZHU Zhiqiang was born in 1961. He received the Ph.D. degree in cloud computing from Wuhan University in 2011. Now he is a professor and M.S. supervisor at PLA Information Engineering University. His research interests include information security strategy, cloud security and trusted computing, etc.朱智强（1961—），男，河南信阳人，2011年于武汉大学获得博士学位，现为解放军信息工程大学科研部长、教授、硕士生导师，主要研究领域为信息安全战略，云计算安全，可信计算等。

Abstract:This paper presents XHydra, a Xen-based virtual machine (VM) security architecture, which focuses on the problems of XenƳs administrative VM with bloated services and a large aggregate TCB (trusted computing base). XHydra separates Dom0 into single-purpose mini-service domains with least privilege and isolated runtime environment, based on the modularity and isolated principles used in micro-kernels.And, this architecture manages the separated mini-service domains and bi-directional shields between DomU and mini-service domains, and bridges the device channel, the device communication between DomU and mini-service domain is supported through an ingenious service monitor called Hydravisor. Finally, this paper gives a prototype XHydra based on Xen4.4, which improves the security of virtualization platform and proves that XHydra is a feasible architecture. Experiments show that, for the benchmark tests about disk performance and network performance of the prototype system, the proposed approach just incurs about 3% performance overhead compared to Xen.

Key words:Xen; security virtual machine; least privilege; service separation; Dom0 virtualization; XHydra

doi:10.3778/j.issn.1673-9418.1507024 E-mail: fcst@vip.163.com

文献标志码：A

中图分类号：TP309