技术领域：
本发明属于虚拟化软件可信计算基
技术领域：
，更具体地，涉及一种缩减宿主型虚拟化软件可信计算基的方法。
背景技术：
：虚拟化软件为充分利用底层物理硬件资源提供了一种解决方案，运行在其上的客户操作系统(guestOS)使用虚拟的硬件资源。虚拟化软件需要对CPU、内存、IO外设等提供虚拟化解决方案，因此通常有庞大的代码基。例如，开源项目Xen超过50万行源代码；KVM项目除了KVM内核模块本身，其底层的Linux系统也包含在可信计算基(TCB)内，特权代码量在数百万行。虚拟化软件分为两种：裸机型(bare-metal)虚拟化管理程序(hypervisor)和宿主型(hosted)hypervisor。Bare-metalhypervisor需要自己对底层的硬件进行管理；hostedhypervisor利用了底层hostOS对硬件进行管理的优势，大大的缩减了管理硬件资源需要的功能(如devicedriver)，该类hypervisor的典型代表是KVM开源软件。KVM是linux内核的一部分并灵活地运用了linux的资源管理功能，容易部署。企业中的虚拟化解决方案开始逐步的像KVM虚拟化迁移，KVM的市场份额不断增加，按照2013年OpenStack的使用用户调研资料显示，搭建OpenStack云平台的用户中有62％的用户选择KVM作为hypervisor。由于hostedhypervisor是hostOS的一部分并依托hostOS提供的功能，例如内存管理、设备驱动管理、CPU调度等操作系统功能，整个hostOS都在hostedhypervisor的TCB中，缩减hostedhypervisor的TCB要比缩减bare-metal要复杂(如，需要考虑hostedhypervisor对hostOS的依赖)。相比于bare-metalhypervisor自己管理物理硬件资源而言，hostedhypervisor拥有更多的安全威胁，庞大的hostOS的所有漏洞都将直接或者间接的影响到guestOS安全。传统的针对解决虚拟化庞大可信计算基的方案有：基于硬件的解决方案和基于软件的方案。从软件的角度，为了不信任虚拟化软件，方案需要构建一个特权级高于虚拟化软件的软件模块，例如CloudVisor监控和干预虚拟化软件和硬件的交互，对于虚拟机中的guestOS而言不用信任虚拟化软件，从而使得虚拟化软件从guestOS的TCB中排除。从硬件的角度，为了不信任任何的上层软件实体，方案需要引入硬件级的可信实体，例如HyperWall修改了MMU的指令时序来控制虚拟化软件和硬件的交互，从而把TCB缩减到了硬件层。以上解决方案存在两个方面的不足：1、由于需要额外的引入一层薄的特权软件层或者修改硬件架构，一定程度上影响了虚拟化的性能开销；2、这些方案作用的对象都是裸机型的虚拟化软件，宿主型的虚拟化软件由于寄住在hostOS里面，并依赖hostOS提供的功能，这些方案未考虑到宿主型虚拟化平台中的guestOS的TCB缩减问题以及该问题的复杂性。技术实现要素：为了解决上述技术问题，本发明提供了一种缩减宿主型虚拟化软件可信计算基的方法，针对宿主操作系统(hostOS)的特权代码，将hostOS的功能通过“库”的形式在用户空间提供给上层应用使用，包括虚拟化软件和其他的应用程序；针对虚拟化软件的特权代码，将虚拟化软件的特权代码降级分离；设置运行在内核空间(kernelspace)的特权代码“minorOS”，用于完成和硬件资源必要的通信；设置非特权级用户空间的OS“libOS”，用于完成OS功能的用户层实现；设置在用户空间运行的虚拟化软件“hypervisor”；设置运行在内核空间的用来处理虚拟化软件请求的特权部分“minorhypervisor”。在本发明的一个实施例中，所述MinorOS是管理底层的硬件平台资源所支持的最小特权代码基，其中，devicedriver设备驱动作为操作系统中大的代码部分，放置在用户空间，其中所述代码为支持各种设备的设备驱动。在本发明的一个实施例中，所述MinorHypervisor是维持虚拟化功能所需要的最小特权代码，其和MinorOS运行在CPU最高特权级，共同组成了VM的TCB；Minorhypervisor用于实现guestOS的资源控制隔离，hypervisor不能随意的查看guestOS的隐私信息。在本发明的一个实施例中，所述LibOS用于完成OS功能的用户层实现，包括设备管理和内存管理；libOS包括有针对内存管理部分的libOS版本和针对设备管理的libOS部分。在本发明的一个实施例中，一个libOS能够被hostapp链接使用，或者能够被运行在用户层的hypervisor链接使用。在本发明的一个实施例中，所述Hypervisor是运行在用户层的虚拟化软件，用于完成虚拟化的大部分功能，提供guestOS虚拟化的资源视图，其与minorhypervisor共同完成对硬件平台的虚拟化。总体而言，通过本发明所构思的以上技术方案与现有技术相比，能够取得下列有益效果：1、HostOS的特权代码的减小受益于libOS方法。Virtualmemory子系统、driver支持子系统、devicedriver、进程管理、文件系统等这些OS功能都可以通过libOS方法实现。操作系统中大部分代码来自于devicedriver和drivezsupport；2、Hypervisor的特权代码的缩减受益于对hypervisor的分层处理。Hypervisor依据对hostOS的依赖以及硬件虚拟化支持可以分为三个层次：a.与hostOS没有交互部分并可以移动用户层执行，这部分可以完全的移动用户层；b.依赖hostOS的功能完成虚拟化，如客户机内存分配依赖于hostOS的内存API，这部分需要在kernelspace和userspace空间分别有对应的处理代码；c.Hypervisor中只能在特权级执行的部分，如硬件虚拟化支持代码(例如，IntelVT-x)，这部分不能被移到用户层。这三部分中，a和b两部分占hypervisor源码中的大部分；3、GuestOS的TCB从两个方面得到有效的缩减。由于加固的minorOS和minorhypervisor拥有对底层的绝对控制权，libOS模块和hypervisor模块被设计为不能任意的读取guestOS的隐私信息(包括内存、IO以及CPU信息)。一方面，hostOS的功能实现在libOS中，其运行在userspace不具有绝对控制权，因此特权代码得到缩减；另一方面，hypervisor将虚拟化软件的功能在userspace中实现也降低了虚拟化软件的特权代码。通过这两方面的特权代码的缩减以及minorOS和minorhypervisor的加固访问控制，虽然libOS和hypervisor能够提供资源抽象层给guestOS，但是无法随意的访问guestOS隐私内存、磁盘等隐私信息。附图说明图1是通用的宿主型虚拟化软件的整体架构；图2是按照本发明针对缩减宿主型虚拟化软件TCB的架构方案；图3是按照发明细化解决方案的模块组件图。具体实施方式为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。本发明提出了一种缩减宿主型虚拟化软件可信计算基的方法。发明包含两个方面：(1)针对hostOS的庞大特权代码，提出一种缩减hostOS的方法；(2)针对寄住在hostOS中的hypervisor提出了保持其对OS的依赖，并减小其特权代码的方法。一方面，发明中的libOS方法能够将hostOS大部分的系统调用在用户层作为library为应用程序服务，这样减小了内核中特权的系统调用实现，同时也减小了由于这类特权代码漏洞所带来的攻击威胁。例如，CVE-2015-7799描述了一个devicedriverbug，攻击者可以利用这个bug来破坏系统的隔离机制从而破坏整个系统，而发明中的devicedriver是运行在用户层的，因此阻止了这类driverbug。另一方面，发明中的hypervisor分层方法是为了保持hypervisor对hostOS的依赖(因为OS此时的功能在用户层实现)，同时也减小了hypervisor特权部分的代码，有效的缩减了hypervisor本身的漏洞所带来的攻击威胁。例如，KVM、Xen、QEMU中都有漏洞CVE-2015-3456(称为“Venom”)，这个漏洞在floppydiskdriver中可以让guestOS逃逸hypervisor的控制进而破坏其它的guestOS甚至底层的系统，由于大部分的hypervisor被降级到用户层执行，因此这类攻击也可以被阻止。为了说明本发明能够有效的缩减guestOS的TCB，图1和图2共同说明了发明的整体架构方案。其中，图1显示了hostedhypervisor的通用模型框架，图2显示了本发明提出的针对该通用模型框架给出缩减TCB的解决方案。首先给出图1整体架构的介绍以及guestOS的TCB：运行在非根模式(non-rootmode，CPU的一种非特权模式，相应的还有rootmode根模式)的guestOS对平台资源拥有最小的权限。平台之下hostOS和hypervisor共同完成对硬件的虚拟化，提供抽象层给guestOS和hostapp(运行在根模式下的主机应用程序)。由于整个hostOS和hypervisor都具有对底层硬件(如，内存)拥有完全的控制权，因此guestOS的TCB必须包含hostOS和hypervisor。其次给出图2整体架构、各组成部分以及虚拟机的TCB分析：本发明针对hostOS的特权代码，将hostOS的功能通过“库”的形式在用户空间(userspace)提供给上层应用使用，包括虚拟化软件和其他的应用程序。因而hostOS的特权功能部分大大减小(由于此时部分功能运行在非特权级)。例如OS的内存管理功能，libOS可以提供内存管理的抽象实现，而把对内层管理功能的底层实现仍然放在特权级使用，这样做很大程度上隔离了特权部分和非特权部分，不像传统的所有代码都运行在内核空间(kernelspace)并拥有最高的控制特权。本发明把运行在可kernelspace的特权代码称为“minorOS”，其完成和硬件资源必要的通信，把非特权级的用户空间的OS称为“libOS”，完成OS功能的用户层实现。通用模型中的hypervisor寄住在hostOS中，运行在最高CPU特权级。在发明提出的方案中，由于需要保持hypervisor对hostOS的依赖，hypervisor需要跟随libOS移动到用户空间执行，否则运行在内核空间的hypervisor也具有对底层的最高控制权，其作为TCB仍然过大。另外，由于OS的功能移到了用户层，如果hypervisor在内核空间使用用户层提供的应用程序编程接口(API)，这样的模式会严重降低虚拟化的性能(因为需要从内核空间到用户空间，再到内核空间的多次模式切换开销)。本发明把在用户空间运行的虚拟化软件称为“hypervisor”，把运行在内核空间的用来处理虚拟化软件请求的特权部分称为“minorhypervisor”。这种特权隔离模式使得hypervisor能够自然的使用libOS的功能，因为libOS提供OS的功能时所给出的API接口保持不变，这样hypervisor使用这些功能仍然可以按照原来的接口。同时minorhypervisor控制着虚拟化软件最为核心的部分，并且运行在最高的特权级，使得TCB进一步缩减。下面描述发明架构中的组成部分(如图2)：(1)MinorOS：管理底层的硬件平台资源所支持的最小特权代码基。其中，devicedriver设备驱动作为操作系统中大的代码部分(OS为了支持各式各样的设备，其必须包含这些设备驱动并放在内核空间运行)需要放在用户空间。为了保护运行在上层的guestOS，需要加固以实现资源的隔离控制，使得libOS不能窃取上层应用隐私信息。(2)MinorHypervisor：维持虚拟化功能所需要的最小特权代码。其和MinorOS运行在CPU最高特权级，共同组成了VM的TCB。Minorhypervisor实现guestOS的资源控制隔离，hypervisor不能随意的查看guestOS的内存、IO等隐私信息，这有效的阻止了被破坏的hypervisor窃取guestOS的隐私，进而获取用户的隐私。(3)LibOS：OS功能的用户层实现，包括：设备管理，内存管理等。因此libOS必须包括有针对内存管理部分的libOS版本和针对设备管理的libOS部分。一个libOS可以被hostapp链接使用，也可以被运行在用户层的hypervisor链接使用。(4)Hypervisor：运行在用户层的虚拟化软件，完成虚拟化的大部分功能，提供guestOS虚拟化的资源视图。其需要与minorhypervisor共同完成对硬件平台的虚拟化。图3给出了实施本发明技术思想的一种优选方案。该图描述了具体实施方式的底层系统架构，并通过hostapp和guestOS的内存请求操作阐述优选方案如何部署每个部分的功能使得guestOS的TCB缩小。Hostapp请求系统分配内存操作分为如下步骤(如图3)：1、Hostapp使用libOS提供的API接口(如，mmap())发起内存申请操作；实际系统应用中，为了不修改后hostapp，需要修改语言运行时库来将hostapp所使用的API重定向到libOS，例如在linux下改变glibc使得mmap()调用会跳转到libOS；2、内存抽象层libOS在user-space空间实现了hostOS的内存管理功能，例如维护vmastruct、实现do_mmap内存映射等。LibOS使用minorOS提供的内存系统调用使用内存资源，例如pagetable操作、physicalmemory分配等底层物理内存操作等；3、部署在minorOS中的“内存内核实现层”以及“访问控制层”用来管理底层的内存和控制上层libOS对内存的访问权限。其中，“内存内核实现层”是系统中实现访问物理内存所需要的底层特权代码，例如，pagetable处理、tlb等物理硬件的管理等。这部分加上“访问控制层”共同组成了加固的“内存内核实现层”。“访问控制层”会通过规则来决策是否为app进行内存分配，例如如果libOS发出的系统调用会包含请求的内存信息，当这些内存不属于它自己的内存时(内存共享除外)，“访问控制层”会拒绝为libOS完成该内存申请操作。4、MinorOS返回内存资源给libOS，libOS进一步管理这部分内存并返回资源给app。GuestOS请求系统分配内存操作分为如下步骤(如图3)：5、在半虚拟化下，guestOS的内存申请操作就是超级调用(hypercall)，由于处理该超级调用的hypervisor运行在用户层，因此超级调用退化为用户空间的函数调用；在全虚拟化下，guestOS会透明的使用内存，hypercall通过全虚拟化内存实现方式来处理。不论是全虚拟化还是半虚拟化，这里同称为guestOS发出内存申请操作；6、运行在用户层的hypervisor接收guestOS的内存请求操作。Hypervisor使用libOS提供的内存分配功能(比如，kmalloc())和minorhypervisor提供的内存虚拟化服务向系统底层提出内存请求申请，例如hypervisor请求minorhypervisor实现EPT(extendpagetable)页表的更新；7、Minorhypervisor接收hypervisor发起的内存请求(如，ept_update())。Minorhypervisor通过“内核内存API”向“内存内核实现层”发出内存请求获取内存资源；8、Minorhypervisor返回内存资源给hypervisor，hypervisor接着返回内存资源给guestOS。不论是hostapp还是guestOS的内存申请操作，最终都需要运行在CPU特权模式下加固的“内存内核实现层”或者minorhypervisor来完成。LibOS内存抽象层和hypervisor在用户空间层截获hostapp和guestOS的内存请求，并通过minorOS中的内存模型和minorhypervisor来完成内存的分配和释放。虽然libOS和hypervisor参与了内存分配和释放功能，但是minorOS中的“访问控制层”会根据规则来判断恶意的内存申请和释放请求。即使libOS和hypervisor被攻击者破坏并获取了它们的访问权限，被攻陷的libOS和hypervisor没有能力破坏“访问控制层”的基本规则，例如hostapp无法通过破坏libOS而随意的窃取其它hostapps的内存；同理，guestOS也无法通过破坏hypervisor随意的访问其他guestOS的资源。因此，对于hostapp或guestOS的隐私资源而言，其可信的代码基是底层的minorOS，libOS和hypervisor被排除在TCB之外。基于此，guestOS的TCB得到了有效的缩减。本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。当前第1页1 2 3