CN111966470B - 虚拟机监控器的加载方法、装置和电子设备 - Google Patents

Abstract

本说明书实施例提出了一种虚拟机监控器的加载方法、装置和电子设备，其中，上述虚拟机监控器的加载方法中，操作系统的启动加载器(boot loader)加载Host OS kernel和initramfs之后，上述Host OS kernel将上述initramfs安装到内存中的临时根目录(/)，将控制权转移给上述initramfs的内存中的临时根目录下的初始化程序(/init)，进入早期用户空间开始执行，然后上述initramfs的初始化程序调用钩子函数进行hypervisor的加载，在上述hypervisor加载完成之后，上述initramfs的初始化程序完成对磁盘上的真正根文件系统的安装(mount)，并将控制权移交给上述真正根文件系统下的初始化程序。从而可以实现在系统完成内核加载之后并且进入用户空间之前实现虚拟机监控器的可信加载。

Description

虚拟机监控器的加载方法、装置和电子设备

【技术领域】

本说明书实施例涉及互联网技术领域，尤其涉及一种虚拟机监控器的加载方法、装置和电子设备。

【背景技术】

虚拟化是云计算的基础支撑技术，而虚拟机监控器(hypervisor，或者virtualmachine monitor，VMM)是实现硬件虚拟化功能和虚拟机(Virtual Machine，VM)管理的核心部件。虚拟机监控器启动时的完整性如果不能得以保证，则会危及运行在虚拟机监控器之上的虚拟机、容器或可信执行环境(Trusted Execution Environment，TEE)的安全性。对此，业界通行的做法是在虚拟机监控器加载时对其进行完整性度量并将度量值扩展到可信平台模块(Trusted Platform Module，TPM)的平台配置寄存器(Platform ConfigurationRegister，PCR)中。有些虚拟机监控器在加载时依赖于所在主机的操作系统内核(hostoperation system kernel，Host OS kernel)提供的功能，因此需要在主机内核启动完成之后才能加载。此时虚拟机监控器的可信加载时机和方法，会对自身的安全性和系统架构的灵活性产生重要的影响。

如果在系统启动进入用户空间后加载虚拟机监控器，先于虚拟机监控器启动的用户程序(例如：系统服务和/或用户进程等)可以对虚拟机监控器的可信加载过程进行攻击，破坏虚拟机监控器的启动完整性。如果在内核启动时加载虚拟机监控器，这种架构需要将虚拟机监控器直接编译进内核(kernel)，破坏虚拟机监控器和内核各自的独立性，造成部署困难和升级维护代价高的问题。

【发明内容】

本说明书实施例提供了一种虚拟机监控器的加载方法、装置和电子设备，以实现在操作系统完成内核加载之后，并且进入用户空间之前完成虚拟机监控器的可信加载，保持虚拟机监控器和主机操作系统内核各自的独立性。

第一方面，本说明书实施例提供一种虚拟机监控器的加载方法，包括：操作系统的启动加载器加载临时文件系统和虚拟机监控器所在主机的操作系统内核，对所述临时文件系统和所述主机的操作系统内核的完整性进行度量，并将所述临时文件系统和所述主机的操作系统内核的完整性度量值扩展到可信平台模块的寄存器中；其中，所述临时文件系统中包括所述虚拟机监控器；所述主机的操作系统内核将所述临时文件系统安装到内存中的临时根目录，将控制权转移给所述临时文件系统的临时根目录下的初始化程序，进入早期用户空间开始执行；所述临时文件系统的初始化程序调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；所述钩子函数启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序；在所述虚拟机监控器加载完成之后，所述临时文件系统的初始化程序完成对磁盘上的真正根文件系统的安装，并将控制权移交给所述真正根文件系统下的初始化程序，开始进入用户空间执行。

上述虚拟机监控器的加载方法中，操作系统的启动加载器(boot loader)加载Host OS kernel和initramfs之后，上述Host OS kernel将上述initramfs安装到内存中的临时根目录(/)，将控制权转移给上述initramfs的临时根目录下的初始化程序(/init)，进入早期用户空间开始执行。然后上述initramfs的初始化程序调用钩子函数进行hypervisor的加载，在上述hypervisor加载完成之后，上述initramfs的初始化程序完成对磁盘上的真正根文件系统的安装(mount)，并将控制权移交给上述真正根文件系统下的初始化程序，开始进入用户空间执行。从而可以实现在系统完成内核加载之后并且进入用户空间之前实现虚拟机监控器的可信加载，不依赖于专门的CPU硬件特性，具有良好的平台适应性；并且虚拟机监控器会在任意用户空间程序执行之前完成加载，用户空间程序无法攻击虚拟机监控器的加载过程，安全性强；另外，上述加载方法保持了Host OS kernel和虚拟机监控器各自的独立性。从initramfs中加载虚拟机监控器，不需要对Host OS kernel进行任何修改。当虚拟机监控器进行升级时，只需要制作新的initramfs，无需重新编译和升级内核。

其中一种可能的实现方式中，所述临时文件系统的初始化程序调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数包括：所述临时文件系统的初始化程序直接调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；或者，所述临时文件系统的初始化程序创建子进程，由创建的子进程调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数。

其中一种可能的实现方式中，所述钩子函数启动所述虚拟机监控器的加载过程包括：所述钩子函数直接启动所述虚拟机监控器的加载过程；或者，所述钩子函数借助中间媒介启动所述虚拟机监控器的加载过程。

其中一种可能的实现方式中，所述操作系统的启动加载器加载临时文件系统和虚拟机监控器所在主机的操作系统内核之前，还包括：将所述虚拟机监控器放入所述临时文件系统的镜像。

其中一种可能的实现方式中，所述虚拟机监控器包括类型1.5虚拟机监控器，所述类型1.5虚拟机监控器包括：所述类型1.5虚拟机监控器应用、所述类型1.5虚拟机监控器驱动、所述类型1.5虚拟机监控器的镜像和所述类型1.5虚拟机监控器的配置文件；所述将所述虚拟机监控器放入所述临时文件系统包括：将所述类型1.5虚拟机监控器应用静态编译，将静态编译得到的可执行文件放到所述临时文件系统的镜像目录中；将所述类型1.5虚拟机监控器的配置文件放置到所述临时文件系统的配置文件目录中；将所述类型1.5虚拟机监控器驱动放置到所述临时文件系统的驱动目录中；将所述类型1.5虚拟机监控器的镜像放置到所述临时文件系统的固件目录中；在所述临时文件系统中注册用于启动所述类型1.5虚拟机监控器的加载过程的钩子函数；所述钩子函数将所述类型1.5虚拟机监控器驱动加载到所述主机的操作系统；所述钩子函数指示所述类型1.5虚拟机监控器驱动去加载所述类型1.5虚拟机监控器的镜像；制作新的临时文件系统，并使用所述新的临时文件系统替换原有的临时文件系统。

其中一种可能的实现方式中，所述钩子函数启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序包括：所述钩子函数加载所述类型1.5虚拟机监控器驱动到所述主机的操作系统内核；所述钩子函数调用所述类型1.5虚拟机监控器应用，以启动所述类型1.5虚拟机监控器的加载过程；所述类型1.5虚拟机监控器应用向所述类型1.5虚拟机监控器驱动发送消息，以指示所述类型1.5虚拟机监控器驱动加载所述类型1.5虚拟机监控器的镜像；所述类型1.5虚拟机监控器驱动加载所述类型1.5虚拟机监控器的镜像；在所述类型1.5虚拟机监控器的镜像加载完成后，所述钩子函数中对所述类型1.5虚拟机监控器应用的调用完成，返回执行所述临时文件系统的初始化程序。

其中一种可能的实现方式中，所述虚拟机监控器包括类型2虚拟机监控器；所述钩子函数启动所述虚拟机监控器的加载过程包括：所述钩子函数将所述类型2虚拟机监控器内核模块加载到所述主机的操作系统内核中。

第二方面，本说明书实施例提供一种虚拟机监控器的加载装置，包括：操作系统的启动加载器，用于加载临时文件系统和虚拟机监控器所在主机的操作系统内核，对所述临时文件系统和所述主机的操作系统内核的完整性进行度量，并将所述临时文件系统和所述主机的操作系统内核的完整性度量值扩展到可信平台模块的寄存器中；其中，所述临时文件系统中包括所述虚拟机监控器；所述主机的操作系统内核，用于将所述临时文件系统安装到内存中的临时根目录，将控制权转移给所述临时文件系统的临时根目录下的初始化程序，进入早期用户空间开始执行；临时文件系统的初始化程序模块，用于调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；钩子函数模块，用于启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序；所述临时文件系统的初始化程序模块，还用于在所述虚拟机监控器加载完成之后，完成对磁盘上的真正根文件系统的安装，并将控制权移交给所述真正根文件系统下的初始化程序，开始进入用户空间执行。

第三方面，本说明书实施例提供一种电子设备，包括：至少一个处理器；以及与所述处理器通信连接的至少一个存储器，其中：所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第一方面提供的方法。

第四方面，本说明书实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第一方面提供的方法。

应当理解的是，本说明书实施例的第二～四方面与本说明书实施例的第一方面的技术方案一致，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

【附图说明】

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本说明书虚拟机监控器的加载方法一个实施例的流程图；

图2为本说明书虚拟机监控器的加载方法另一个实施例的流程图；

图3为本说明书虚拟机监控器的加载方法再一个实施例的流程图；

图4为本说明书虚拟机监控器的加载装置一个实施例的结构示意图；

图5为本说明书虚拟机监控器的加载装置另一个实施例的结构示意图；

图6为本说明书电子设备一个实施例的结构示意图。

【具体实施方式】

为了更好的理解本说明书的技术方案，下面结合附图对本说明书实施例进行详细描述。

应当明确，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本说明书保护的范围。

虚拟化是云计算的基础支撑技术，而虚拟机监控器是实现硬件虚拟化功能和虚拟机管理的核心部件。虚拟机监控器启动时的完整性如果不能得以保证，则会危及运行在虚拟机监控器之上的虚拟机、容器或TEE的安全性。

现有相关技术中，虚拟机监控器的可信加载时机和方法，会对自身的安全性和系统架构的灵活性产生重要的影响。

虚拟机监控器运行在高特权级模式，为其上运行的软件系统(通常是VM)提供CPU，内存和外设的虚拟化和资源管理功能。一个完整性缺失的虚拟机监控器会造成上层软件系统安全性的彻底缺失。例如：一个被注入恶意代码的虚拟机监控器可以随意窃取VM中正在处理的用户数据；一个被黑客攻陷的虚拟机监控器可以提供有安全缺陷的内存管理和访问接口，造成其上运行的VM或者TEE执行恶意的代码。因此，构建一个安全的系统首先需要采取措施确保虚拟机监控器启动时代码和数据的完整性，常用的方法是在主机系统启动过程中，负责加载虚拟机监控器的软件或者固件先度量虚拟机监控器的完整性，将完整性度量值扩展到TPM的PCR中，以便后继通过远程验证机制(remote attestation)向验证者证明自身完整性。

目前主要有三种类型的虚拟机监控器。类型1(也称为类型I)虚拟机监控器直接运行在主机的硬件上来控制硬件和管理虚拟机，典型代表是Xen。这种虚拟机监控器一般由操作系统的启动加载器(boot loader)加载，其加载和运行不依赖于另外一个Host OSkernel。由于通常需要虚拟机监控器自己负责主机硬件初始化等工作，类型1虚拟机监控器代码规模庞大，功能结构复杂，运行效率也不高。

类型2(也称类型II)虚拟机监控器运行在操作系统环境下，依赖于Host OSkernel进行加载和运行，其代表是Linux KVM，VMware 5.5以前版本等。类型2虚拟机监控器由于可以依赖Host OS kernel进行主机硬件初始化和管理，所以自身代码规模相对较小，功能架构清晰，运行效率高。这种虚拟机监控器由于在运行时也需要依赖于Host OSkernel，因此在基于类型2虚拟机监控器构建安全系统时很难保持较小的可信计算基(trusted computing base，TCB)，因为Host OS kernel与虚拟机监控器都会进入TCB。

类型1.5虚拟机监控器，通常依赖于Host OS Kernel进行加载，但一旦运行起来可以完全摆脱对Host OS kernel的依赖并可以完全虚拟化Host OS，典型代表是jailhouse。类型1.5虚拟机监控器由于无需自己负责硬件初始化，可以保持相对较小的代码规模和清晰的功能结构。另外由于这种虚拟机监控器在运行时可以不依赖于并且可以虚拟化HostOS，因此基于这种虚拟机监控器构建的安全系统可以保持相对比较小的TCB。

由于不依赖于Host OS kernel进行加载，类型1虚拟机监控器可以很容易地实现可信加载。一般，系统启动时boot loader(如grub)对虚拟机监控器进行完整性度量，将完整性度量值扩展到TPM的PCR中，然后加载虚拟机监控器。类型2和类型1.5虚拟机监控器由于在加载时依赖于Host OS kernel提供的功能，其加载时机和方法会对自身的安全性和系统架构的灵活性产生重要的影响。对这些类型的虚拟机监控器的加载过程而言，Host OSkernel是可信的，因为boot loader在加载Host OS kernel时会对其镜像(image)进行度量。而Host OS的用户，特别是具有根(root)权限的用户，可能是恶意的。进而，Host OS上的系统服务和用户应用可能是恶意的，一方面系统必须允许这些服务和应用可以被不断升级，另一方面这些服务和应用的启动顺序也不固定，导致度量这些系统和服务时的随机性，可能影响后续的远程验证过程。Host OS的恶意用户可能是因为对组织心怀不满而希望通过攻击虚拟机监控器的加载过程从中获利或者制造破坏效果的系统管理员或者普通系统用户。在一种攻击形式下，Host OS的恶意用户可以编写自己的系统服务去模拟虚拟机监控器的加载过程并在加载虚拟机监控器之前向TPM的PCR中扩展已知的代表良好虚拟机监控器配置的完整性度量值，进而向远端的验证者假冒虚拟机监控器。

另外一种攻击形式下，Host OS恶意用户可以编写应用程序，在等待负责加载虚拟机监控器的程序完成对虚拟机监控器的度量并扩展度量值到TPM的PCR之后，打断虚拟机监控器的加载过程，并利用此时PCR中的虚拟机监控器度量值向远端验证者假冒虚拟机监控器。由此可见，虚拟机监控器的可信加载过程需要抵御Host OS恶意系统服务和用户程序的攻击。

Linux系统启动时boot loader会从/boot分区加载内核和临时文件系统(initramfs)的镜像(image)到内存中，然后启动内核的执行。内核会检测initramfs的存在并在内存中将其安装(mount)到内存中的临时根目录(/)，然后执行根目录下的初始化程序(/init)。初始化程序开始执行后，从硬盘安装真正的根文件系统(real root filesystem)，然后切换根文件系统到真正根文件系统并将控制权移交给真正根文件系统上的初始化程序。其中切换根文件系统并移交控制权这个步骤被称为switching root。Linux系统启动先后经历三个空间：kernel启动时使用kernel空间、initramfs的初始化程序开始执行时进入早期用户空间(early user space)，以及真正根文件系统上的初始化程序(也称systemd)开始执行时进入用户空间(user space)。

下面对现有相关技术中提供的虚拟机监控器的加载方案进行介绍。

方案一：基于动态可信度量根(dynamic root of trust measurement，DRTM)后加载(late launch)。

一种DRTM技术的典型代表是因特尔(Intel)的可信执行技术(trusted executiontechnology，TXT)，这种技术允许在Host OS启动完成后的任意时刻通过专门的中央处理单元(central processing unit，CPU)指令构建一个可信的执行环境去执行虚拟机监控器的加载，以CPU中固化的密钥作为信任根逐级度量启动链条上的下一环节，最终完成虚拟机监控器的加载并把其完整性度量值扩展到TPM寄存器中。TXT提供专门的CPU指令构建可信的虚拟机监控器加载环境，确保没有恶意代码可以干扰这个过程。

这种方法的优势是：可以根据业务需要，在Host OS启动后的任意时刻可信地加载虚拟机监控器。

但是，这种方法需要依赖于专门的DRTM硬件特性，限制了这种方法的平台适用性。因为在很多平台上可能没有类似TXT的DRTM硬件功能，而在一些已经上线的服务器平台上，TXT功能可能是关闭的，重新开启TXT功能会带来额外的管理和配置负担，部分管理人员也担心开启这样的安全功能，可能会引发系统稳定性问题。

方案二：在系统启动进入用户空间后从真正根文件系统中加载虚拟机监控器，将虚拟机监控器的镜像(image)存放在真正根文件系统中，系统启动进入用户空间后，通过用户空间程序启动虚拟机监控器的加载过程。

具体地，可以将虚拟机监控器的镜像存放在真正根文件系统的某个目录下，通过系统守护进程(systemd)启动的系统服务去启动虚拟机监控器的加载。为了提高虚拟机监控器加载过程的安全性，需要在系统进入用户空间后尽早地加载虚拟机监控器，而systemd是从真正根文件系统中启动的第一个用户进程(进程号为1)，因此基于systemd启动的服务可以实现在系统进入用户空间后尽早地加载虚拟机监控器。

这种方法的优势是：不依赖专门的硬件特性(例如：TXT)，所以平台适应性强；另外，从真正根文件系统中加载虚拟监控器不需要对Host OS kernel进行任何修改，较好地保持了虚拟机监控器和Host OS kernel各自的独立性。这允许虚拟机监控器可以独立地升级，而不影响Host OS kernel。

但是，这种方法难以保证虚拟机监控器加载过程的安全性。虚拟机监控器存放在真正根文件系统中，则其加载过程依赖于磁盘管理、设备管理和内核模块管理等系统服务。这些系统服务处于Host OS的控制之下且在虚拟机监控器加载之前运行，可以造成Host OS恶意系统服务和用户程序的攻击。另外用户空间程序众多且启动顺序无法固定，这造成难以确定在虚拟机监控器加载之前运行的所有应用并对其进行完整性度量。最后，用户空间程序相对于内核需要更频繁的升级，难以形成稳定的完整性度量值。

方案三：从Host OS kernel镜像中加载虚拟机监控器。

为了实现尽早加载虚拟机监控器以抵御用户程序的攻击，可以把虚拟机监控器的镜像直接编译到Host OS kernel的镜像中，并在内核启动过程中去加载虚拟机监控器。此时虚拟机监控器的加载，发生在内核空间中。

这种方案的优势，可以确保操作系统在执行用户空间的任何程序之前，完成虚拟机监控器的可信加载，从而具有较高的安全性。

但是，这种方法破坏了Host OS kernel和虚拟机监控器各自的独立性。首先，在Host OS kernel中添加加载虚拟机监控器的代码，增加了内核的代码规模，将内核的处理逻辑复杂化，并可能引入安全漏洞。其次，将虚拟机监控器融入到内核镜像中，需要对内核进行重新编译。再次，每次升级虚拟机监控器都需要升级整个内核。

基于以上问题，本说明书实施例提供了一种虚拟机监控器的加载方法，可以在早期用户空间中对虚拟机监控器进行可信加载，在Host OS kernel启动完成后，并在操作系统进入用户空间之前，实现虚拟机监控器的可信加载，从而可以确保虚拟机监控器加载过程的安全性，并且可以保持虚拟机监控器和Host OS kernel各自的独立性。

本说明书实施例将虚拟机监控器的镜像放置在临时文件系统(initramfs)中，在系统完成内核加载之后并且进入用户空间之前实现虚拟机监控器的可信加载，具有如下优势：

1)不依赖于专门的CPU硬件特性，具有良好的平台适应性；

2)安全性强。虚拟机监控器的镜像位于initramfs中，而intramfs的镜像由操作系统的启动加载器(boot loader)进行完整性度量，这意味着在早期用户空间中执行的任何程序(包括虚拟机监控器)的完整性都已得到度量。虚拟机监控器会在任意用户空间程序执行之前完成加载，用户空间程序无法攻击虚拟机监控器的加载过程。

3)保持了Host OS kernel和虚拟机监控器各自的独立性。从initramfs中加载虚拟机监控器，不需要对Host OS kernel进行任何修改。当虚拟机监控器进行升级时，只需要制作新的initramfs，无需重新编译和升级内核。

本说明书实施例提供的虚拟机监控器的加载方法的核心技术思路是将虚拟机监控器的镜像(image)放置到临时文件系统(initramfs)中，在initramfs中注册初始化程序(/init)提供的钩子函数(hook)，利用钩子函数在早期用户空间中完成加载和度量虚拟机监控器的过程；在系统启动时，通过boot loader度量包含虚拟机监控器的initramfs的完整性，并将完整性度量值扩展到TPM的PCR中。

因为boot loader会度量整个initramfs的完整性，所以所有在早期用户空间运行的程序的完整性都会被度量。这确保了initramfs中如果有恶意程序可以攻击虚拟机监控器的加载过程，则一定会在TPM寄存器中留下记录，进而通过远程验证过程可以检测出来。由于虚拟机监控器从initramfs中的加载发生在早期用户空间，也就是系统进入用户空间之前，所以用户空间中的程序无法攻击虚拟机监控器的加载过程。

虚拟机监控器的加载要依赖于Host OS kernel，boot loader加载内核时会度量内核镜像的完整性并扩展完整性度量值到TPM的PCR中，本说明书实施例中，虚拟机监控器的加载发生在早期用户空间，此时内核已经被可信加载并完成启动过程，所以虚拟机监控器的加载可以顺利进行。

图1为本说明书虚拟机监控器的加载方法一个实施例的流程图，参见图1，临时文件系统(initramfs)中包含了一组早期用户空间程序，用于在操作系统进入用户空间之前完成真正根文件系统的初始化。本实施例将虚拟机监控器(hypervisor)的镜像放置到initramfs中，在操作系统启动进入用户空间之前完成对虚拟机监控器的加载。操作系统启动时，操作系统的启动加载器(boot loader)会加载主机的操作系统内核(Host OSkernel)和initramfs，并分别度量它们的完整性，将完整性度量值扩展到TPM的PCR，然后启动主机的操作系统内核。主机的操作系统内核会将控制权移交给initramfs的初始化(/init)程序，/init程序执行时会最终调用到钩子函数(hook)，启动虚拟机监控器的加载，并在操作系统进入用户空间之前完成虚拟机监控器的加载。需要注意的是，initramfs的/init程序会最终调用到虚拟机监控器在initramfs中注册的钩子函数，以启动虚拟机监控器的加载过程，这并不意味着/init程序会直接调用钩子函数，也可以是/init程序创建其他子进程，然后创建的子进程调用上述钩子函数以启动虚拟机监控器的加载。

如图1所示，上述虚拟机监控器的加载方法可以包括：

步骤102，操作系统的启动加载器(boot loader)加载虚拟机监控器(hypervisor)所在主机的操作系统内核(Host OS kernel)，对上述Host OS kernel的完整性进行度量，并将上述Host OS kernel的完整性度量值扩展到TPM的寄存器中。

具体实现时，TPM的寄存器可以为TPM的PCR。

步骤104，boot loader加载临时文件系统(initramfs)，对上述initramfs的完整性进行度量，并将上述initramfs的完整性度量值扩展到TPM的寄存器中。

其中，上述initramfs中包括上述hypervisor。

具体实现时，步骤102与步骤104可以先后执行，也可以并行执行，本实施例对步骤102与步骤104的执行顺序不作限定。

步骤106，上述Host OS kernel将上述initramfs安装(mount)到内存中的临时根目录(/)，将控制权转移给上述initramfs的临时根目录下的初始化程序(/init)。此时，操作系统进入早期用户空间开始执行。

步骤108，上述initramfs的初始化程序调用上述hypervisor在上述initramfs中注册的钩子函数(hook)。

具体地，上述initramfs的初始化程序调用上述hypervisor在上述initramfs中注册的钩子函数可以为：上述initramfs的初始化程序直接调用上述hypervisor在上述initramfs中注册的钩子函数；或者，上述initramfs的初始化程序创建子进程，由创建的子进程调用上述hypervisor在上述initramfs中注册的钩子函数。

步骤110，上述钩子函数启动上述hypervisor的加载过程，等待上述hypervisor在早期用户空间加载完成后返回执行上述initramfs的初始化程序。

具体地，上述钩子函数启动上述hypervisor的加载过程可以为：上述钩子函数直接启动上述hypervisor的加载过程；或者，上述钩子函数借助中间媒介启动上述hypervisor的加载过程。

其中，上述中间媒介可以为其他进程或其他模块(例如：kernel module)等，本实施例对上述中间媒介不作限定。

步骤112，在上述hypervisor加载完成之后，上述initramfs的初始化程序完成对磁盘上的真正根文件系统的安装(mount)，并将控制权移交给上述真正根文件系统下的初始化程序。

接下来，操作系统启动进入用户空间，开始执行用户空间的程序。

上述虚拟机监控器的加载方法中，操作系统的启动加载器(boot loader)加载Host OS kernel和initramfs之后，上述Host OS kernel将上述initramfs安装到内存中的临时根目录(/)，将控制权转移给上述initramfs的临时根目录下的初始化程序(/init)，进入早期用户空间开始执行。然后上述initramfs的初始化程序调用钩子函数进行hypervisor的加载，在上述hypervisor加载完成之后，上述initramfs的初始化程序完成对磁盘上的真正根文件系统的安装(mount)，并将控制权移交给上述真正根文件系统下的初始化程序，开始进入用户空间执行。从而可以实现在系统完成内核加载之后并且进入用户空间之前实现虚拟机监控器的可信加载，不依赖于专门的CPU硬件特性，具有良好的平台适应性；并且虚拟机监控器会在任意用户空间程序执行之前完成加载，用户空间程序无法攻击虚拟机监控器的加载过程，安全性强；另外，上述加载方法保持了Host OS kernel和虚拟机监控器各自的独立性。从initramfs中加载虚拟机监控器，不需要对Host OS kernel进行任何修改。当虚拟机监控器进行升级时，只需要制作新的initramfs，无需重新编译和升级内核。

进一步地，本说明书图1所述实施例中，步骤102之前，还可以将上述hypervisor放入上述initramfs的镜像。

下面以虚拟机监控器为类型1.5虚拟机监控器为例进行说明，上述类型1.5虚拟机监控器可以包括：类型1.5虚拟机监控器应用、类型1.5虚拟机监控器驱动、类型1.5虚拟机监控器的镜像和类型1.5虚拟机监控器的配置文件。

具体实现时，上述类型1.5虚拟机监控器可以为jailhouse，这样类型1.5虚拟机监控器应用可以为jailhouse应用，类型1.5虚拟机监控器驱动可以为jailhouse.ko，类型1.5虚拟机监控器的镜像可以为jailhouse.bin，类型1.5虚拟机监控器的配置文件可以为jailhouse的配置文件。

下面对jailhouse的加载过程进行说明。

类型1.5虚拟机监控器一般都有一个Host OS kernel module形式的驱动，作为类型1.5虚拟机监控器的加载器。Jailhouse是最具有代表性的类型1.5虚拟机监控器，其加载时依赖于Host OS kernel，但一旦运行起来可以摆脱对Host OS kernel的依赖并虚拟化Host OS。Jailhouse主要包括四个部件：jailhouse应用、jialhouse.ko、jialhouse.bin和配置文件。

其中，jailhouse.bin是jailhouse的镜像(image)文件；

jialhouse.ko是一个Host OS的kernel module，是负责加载jailhouse.bin的驱动；

配置文件包含了jailhouse.ko加载jailhouse.bin时所需要的硬件配置信息；

jailhouse应用是一个用户空间程序，负责读取配置文件中的信息，然后通过输入输出控制(input output control，IOCTL)将配置信息传递给jailhouse.ko，并指示jailhouse.ko启动jailhouse.bin的加载过程；

在jailhouse.bin加载完成后，IOCTL返回，Jailhouse应用执行结束。

具体地，将虚拟机监控器(jailhouse)放入上述initramfs的过程可以包括：

步骤1，将jailhouse应用静态编译，将静态编译得到的可执行文件放到上述initramfs的镜像目录(/bin)中。

步骤2，将jailhouse的配置文件放置到上述initramfs的配置文件目录(/etc)中。

步骤3，将上述jailhouse.ko放置到上述initramfs的驱动目录中。

具体地，上述initramfs的驱动目录可以为上述initramfs的/usr/lib/modules/’uname-r’/extra/driver，其中，’uname-r’代表主机的操作系统内核(Host OS kernel)的当前版本。

步骤4，将jailhouse.bin放置到initramfs的固件目录中。

具体地，上述initramfs的固件目录可以为上述initramfs的/usr/lib/firmware。

步骤5，在上述initramfs中注册用于启动jailhouse的加载过程的钩子函数。

具体地，可以在initramfs中注册一个模块(module)，或者使用现有的module，注册的module中包含用于启动jailhouse加载过程的hook函数。

步骤6，hook函数将jailhouse.ko加载到主机的操作系统(Host OS)。

具体地，可以在上述hook函数中使用modprobe jailhouse加载jailhouse.ko到Host OS。其中，modprobe是linux的一个命令，可载入指定的个别模块，或是载入一组相依的模块。

步骤7，hook函数指示上述jailhouse.ko去加载jailhouse.bin。

具体地，可以在上述hook函数中使用jailhouse enable/etc/config指示jailhouse.ko去加载jailhouse.bin。

步骤8，制作新的initramfs，并使用上述initramfs替换原有的initramfs。

具体地，可以使用dracut工具制作新的initramfs，并替换原有的initramfs。

本实施例在操作系统启动时，使用grub度量Host OS kernel和initramfs的镜像，并扩展各自的完整性度量值到TPM寄存器中。本实施例中，加载jailhouse的流程可以如图2所示，图2为本说明书虚拟机监控器的加载方法另一个实施例的流程图。

从图1和图2可以看出，图2所示的架构图与图1所示的架构图基本没有变化，只是对hypervisor进行了更细粒度的拆分。图2所示的虚拟机监控器的加载方法的流程，也与图1的技术流程相同。这里只对图1所示实施例中的步骤110进行进一步的细化和说明。

参见图2，本说明书图1所示实施例中，步骤110可以包括：

步骤1102，钩子函数加载jailhouse.ko到Host OS kernel。

具体地，钩子函数(hook)可以通过modprobe jailhouse加载jailhouse.ko到HostOS kernel。

步骤1104，钩子函数调用jailhouse应用，以启动上述jailhouse的加载过程。

具体地，钩子函数可以执行/bin/jailhouse enable/etc/config命令，调用jailhouse应用，以启动上述jailhouse的加载过程。

步骤1106，jailhouse应用向jailhouse.ko发送消息，以指示jailhouse.ko加载jailhouse.bin。

具体地，jailhouse应用可以通过IOCTL向jailhouse.ko发送消息，指示jailhouse.ko加载jailhouse.bin。

步骤1108，jailhouse.ko加载jailhouse.bin。

步骤11010，在jailhouse.bin加载完成后，钩子函数中对jailhouse应用的调用完成，返回执行上述initramfs的初始化程序。

具体地，在jailhouse.bin加载完成后，hook中对jailhouse应用的调用完成，回到initramfs的module中继续执行。

需要说明的是，这里钩子函数对jailhouse应用的调用，在jailhouse.bin完成加载后才会返回。

本说明书的再一个实施例中，虚拟机监控器可以为类型2虚拟机监控器，上述类型2虚拟机监控器可以为基于Linux内核的虚拟机(kernel-based virtual machine，KVM)。下面以KVM为例说明类型2虚拟机监控器的加载方法。

KVM以Linux内核模块(Kernel Module)的形式存在。如果在操作系统启动进入用户空间后通过modprobe加载KVM，由于用户程序执行的顺序不固定且root权限用户的存在，KVM加载过程可能遭受攻击，而难以保证安全性。通过在早期用户空间，从initramfs中加载KVM，可以显著增强KVM可信加载过程的安全性。本实施例的基本方案是：将KVM的内核模块(kernel module)，包括kvm.ko以及kvm-$vendor.ko，比如kvm-intel.ko放置到initramfs的/usr/lib/modules/’uname-r’/extra/driver目录下，并在操作系统启动进入早期用户空间后通过initramfs的钩子函数实现对kvm.ko的加载。本实施例在操作系统启动时，使用grub度量Host OS kernel和initramfs的镜像，并扩展各自的完整性度量值到TPM寄存器中。

图3为本说明书虚拟机监控器的加载方法再一个实施例的流程图，对比图1和图3，图3所示的架构图与图1所示的架构图基本没有变化，虚拟机监控器(kvm.ko)的加载流程与图1所示实施例的流程基本相同。这里对本说明书图1所示实施例中的步骤110进行进一步地说明。

如图3所示，本说明书图1所示实施例中，步骤110可以为：

步骤302，钩子函数将上述类型2虚拟机监控器内核模块加载到Host OS kernel中，等待上述类型2虚拟机监控器内核模块加载完成后返回执行initramfs的初始化程序。

具体地，钩子函数可以通过modprobe把kvm.ko和kvm-$vendor.ko如kvm-intel.ko加载Host OS Kernel中，在kvm.ko和kvm-$vendor.ko如kvm-intel.ko加载完成后，钩子函数返回执行initramfs的初始化程序。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图4为本说明书虚拟机监控器的加载装置一个实施例的结构示意图，如图4所示，上述虚拟机监控器的加载装置可以包括：操作系统的启动加载器(boot loader)41、主机的操作系统内核(Host OS kernel)42、临时文件系统(initramfs)的初始化程序(/int)模块43和钩子函数(hook)模块44。

其中，操作系统的启动加载器41，用于加载临时文件系统和虚拟机监控器所在主机的操作系统内核，对上述临时文件系统和上述主机的操作系统内核的完整性进行度量，并将上述临时文件系统和上述主机的操作系统内核的完整性度量值扩展到可信平台模块的寄存器中；其中，上述临时文件系统中包括虚拟机监控器。

主机的操作系统内核42，用于将上述临时文件系统安装到内存中的临时根目录，将控制权转移给上述临时文件系统的临时根目录下的初始化程序，进入早期用户空间开始执行。

临时文件系统的初始化程序模块43，用于调用上述虚拟机监控器在临时文件系统中注册的钩子函数；本实施例中，临时文件系统的初始化程序模块43，具体用于直接调用上述虚拟机监控器在临时文件系统中注册的钩子函数；或者，创建子进程，由创建的子进程调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数。

钩子函数模块44，用于启动上述虚拟机监控器的加载过程，等待虚拟机监控器在早期用户空间加载完成后返回执行上述临时文件系统的初始化程序。本实施例中，钩子函数模块，具体用于直接启动上述虚拟机监控器的加载过程；或者，借助中间媒介启动上述虚拟机监控器的加载过程。

进一步地，临时文件系统的初始化程序模块43，还用于在虚拟机监控器加载完成之后，完成对磁盘上的真正根文件系统的安装，并将控制权移交给上述真正根文件系统下的初始化程序，开始进入用户空间执行。

图4所示实施例提供的虚拟机监控器的加载装置可用于执行本说明书图1所示方法实施例的技术方案，其实现原理和技术效果可以进一步参考方法实施例中的相关描述。

图5为本说明书虚拟机监控器的加载装置另一个实施例的结构示意图，与图4所示的虚拟机监控器的加载装置相比，不同之处在于，上述虚拟机监控器的加载装置还可以包括：放入模块45；

放入模块45，用于在操作系统的启动加载器41加载临时文件系统和虚拟机监控器所在主机的操作系统内核之前，将上述虚拟机监控器放入上述临时文件系统的镜像。

一种实现方式中，上述虚拟机监控器可以为类型1.5虚拟机监控器，类型1.5虚拟机监控器包括：类型1.5虚拟机监控器应用、类型1.5虚拟机监控器驱动、类型1.5虚拟机监控器的镜像和类型1.5虚拟机监控器的配置文件；

放入模块45，具体用于将上述类型1.5虚拟机监控器应用静态编译，将静态编译得到的可执行文件放到临时文件系统的镜像目录中；将类型1.5虚拟机监控器的配置文件放置到上述临时文件系统的配置文件目录中；将类型1.5虚拟机监控器驱动放置到上述临时文件系统的驱动目录中；将类型1.5虚拟机监控器的镜像放置到上述临时文件系统的固件目录中；在上述临时文件系统中注册用于启动类型1.5虚拟机监控器的加载过程的钩子函数；以及通过上述钩子函数将类型1.5虚拟机监控器驱动加载到所述主机的操作系统，钩子函数指示类型1.5虚拟机监控器驱动去加载类型1.5虚拟机监控器的镜像；以及制作新的临时文件系统，并使用上述新的临时文件系统替换原有的临时文件系统。

本实现方式中，钩子函数模块44，具体用于加载类型1.5虚拟机监控器驱动到上述主机的操作系统内核；调用所述类型1.5虚拟机监控器应用，以启动类型1.5虚拟机监控器的加载过程；通过类型1.5虚拟机监控器应用向类型1.5虚拟机监控器驱动发送消息，以指示类型1.5虚拟机监控器驱动加载类型1.5虚拟机监控器的镜像；通过类型1.5虚拟机监控器驱动加载类型1.5虚拟机监控器的镜像；在类型1.5虚拟机监控器的镜像加载完成后，返回执行上述临时文件系统的初始化程序。

另一种实现方式中，上述虚拟机监控器可以为类型2虚拟机监控器；本实现方式中，钩子函数模块44，具体用于将类型2虚拟机监控器内核模块加载到上述主机的操作系统内核中。

图5所示实施例提供的虚拟机监控器的加载装置可用于执行本申请图1～图3所示方法实施例的技术方案，其实现原理和技术效果可以进一步参考方法实施例中的相关描述。

图6为本说明书电子设备一个实施例的结构示意图，如图6所示，上述电子设备可以包括至少一个处理器；以及与上述处理器通信连接的至少一个存储器，其中：存储器存储有可被处理器执行的程序指令，上述处理器调用上述程序指令能够执行本说明书图1～图3所示实施例提供的虚拟机监控器的加载方法。

其中，上述电子设备可以为云服务器。

图6示出了适于用来实现本说明书实施方式的示例性电子设备的框图。图6显示的电子设备仅仅是一个示例，不应对本说明书实施例的功能和使用范围带来任何限制。

如图6所示，电子设备以通用计算设备的形式表现。电子设备的组件可以包括但不限于：一个或者多个处理器410，通信接口420，存储器430，以及连接不同组件(包括存储器430、通信接口420和处理单元410)的通信总线440。

通信总线440表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，或者使用多种总线结构中的任意总线结构的局域总线。举例来说，通信总线440可以包括但不限于工业标准体系结构(industry standardarchitecture，ISA)总线，微通道体系结构(micro channel architecture，MAC)总线，增强型ISA总线、视频电子标准协会(video electronics standards association，VESA)局域总线以及外围组件互连(peripheral component interconnection，PCI)总线。

电子设备典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器430可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(random access memory，RAM)和/或高速缓存存储器。存储器430可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本说明书图1～图3所示实施例的功能。

具有一组(至少一个)程序模块的程序/实用工具，可以存储在存储器430中，这样的程序模块包括——但不限于——操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块通常执行本说明书图1～图3所描述的实施例中的功能和/或方法。

处理器410通过运行存储在存储器430中的程序，从而执行各种功能应用以及数据处理，例如实现本说明书图1～图3所示实施例提供的虚拟机监控器的加载方法。

本说明书实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行本说明书图1～图3所示实施例提供的虚拟机监控器的加载方法。

上述非暂态计算机可读存储介质可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(read only memory，ROM)、可擦式可编程只读存储器(erasable programmable read onlymemory，EPROM)或闪存、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、电线、光缆、射频(radio frequency，RF)等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本说明书操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(localarea network，LAN)或广域网(wide area network，WAN)连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本说明书的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本说明书的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本说明书的实施例所属技术领域的技术人员所理解。

取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

需要说明的是，本说明书实施例中所涉及的终端可以包括但不限于个人计算机(personal computer，PC)、个人数字助理(personal digital assistant，PDA)、无线手持设备、平板电脑(tablet computer)、手机、MP3播放器、MP4播放器等。

在本说明书所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本说明书各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本说明书各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM)、随机存取存储器(RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (10)

1.一种虚拟机监控器的加载方法，包括：

操作系统的启动加载器加载临时文件系统和虚拟机监控器所在主机的操作系统内核，对所述临时文件系统和所述主机的操作系统内核的完整性进行度量，并将所述临时文件系统和所述主机的操作系统内核的完整性度量值扩展到可信平台模块的寄存器中；其中，所述临时文件系统中包括所述虚拟机监控器；

所述主机的操作系统内核将所述临时文件系统安装到内存中的临时根目录，将控制权转移给所述临时文件系统的临时根目录下的初始化程序，进入早期用户空间开始执行；

所述临时文件系统的初始化程序调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；

所述钩子函数启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序；

在所述虚拟机监控器加载完成之后，所述临时文件系统的初始化程序完成对磁盘上的真正根文件系统的安装，并将控制权移交给所述真正根文件系统下的初始化程序，开始进入用户空间执行。

2.根据权利要求1所述的方法，其中，所述临时文件系统的初始化程序调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数包括：

所述临时文件系统的初始化程序直接调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；或者，

所述临时文件系统的初始化程序创建子进程，由创建的子进程调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数。

3.根据权利要求1所述的方法，其中，所述钩子函数启动所述虚拟机监控器的加载过程包括：

所述钩子函数直接启动所述虚拟机监控器的加载过程；或者，

所述钩子函数借助中间媒介启动所述虚拟机监控器的加载过程。

4.根据权利要求1-3任意一项所述的方法，其中，所述操作系统的启动加载器加载临时文件系统和虚拟机监控器所在主机的操作系统内核之前，还包括：

将所述虚拟机监控器放入所述临时文件系统的镜像。

5.根据权利要求4所述的方法，其中，所述虚拟机监控器包括类型1.5虚拟机监控器，所述类型1.5虚拟机监控器包括：所述类型1.5虚拟机监控器应用、所述类型1.5虚拟机监控器驱动、所述类型1.5虚拟机监控器的镜像和所述类型1.5虚拟机监控器的配置文件；

所述将所述虚拟机监控器放入所述临时文件系统包括：

将所述类型1.5虚拟机监控器应用静态编译，将静态编译得到的可执行文件放到所述临时文件系统的镜像目录中；

将所述类型1.5虚拟机监控器的配置文件放置到所述临时文件系统的配置文件目录中；

将所述类型1.5虚拟机监控器驱动放置到所述临时文件系统的驱动目录中；

将所述类型1.5虚拟机监控器的镜像放置到所述临时文件系统的固件目录中；

在所述临时文件系统中注册用于启动所述类型1.5虚拟机监控器的加载过程的钩子函数；

所述钩子函数将所述类型1.5虚拟机监控器驱动加载到所述主机的操作系统；

所述钩子函数指示所述类型1.5虚拟机监控器驱动去加载所述类型1.5虚拟机监控器的镜像；

制作新的临时文件系统，并使用所述新的临时文件系统替换原有的临时文件系统。

6.根据权利要求5所述的方法，其中，所述钩子函数启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序包括：

所述钩子函数加载所述类型1.5虚拟机监控器驱动到所述主机的操作系统内核；

所述钩子函数调用所述类型1.5虚拟机监控器应用，以启动所述类型1.5虚拟机监控器的加载过程；

所述类型1.5虚拟机监控器应用向所述类型1.5虚拟机监控器驱动发送消息，以指示所述类型1.5虚拟机监控器驱动加载所述类型1.5虚拟机监控器的镜像；

所述类型1.5虚拟机监控器驱动加载所述类型1.5虚拟机监控器的镜像；

在所述类型1.5虚拟机监控器的镜像加载完成后，所述钩子函数中对所述类型1.5虚拟机监控器应用的调用完成，返回执行所述临时文件系统的初始化程序。

7.根据权利要求1-3任意一项所述的方法，其中，所述虚拟机监控器包括类型2虚拟机监控器；

所述钩子函数启动所述虚拟机监控器的加载过程包括：

所述钩子函数将所述类型2虚拟机监控器内核模块加载到所述主机的操作系统内核中。

8.一种虚拟机监控器的加载装置，包括：

操作系统的启动加载器，用于加载临时文件系统和虚拟机监控器所在主机的操作系统内核，对所述临时文件系统和所述主机的操作系统内核的完整性进行度量，并将所述临时文件系统和所述主机的操作系统内核的完整性度量值扩展到可信平台模块的寄存器中；其中，所述临时文件系统中包括所述虚拟机监控器；

所述主机的操作系统内核，用于将所述临时文件系统安装到内存中的临时根目录，将控制权转移给所述临时文件系统的临时根目录下的初始化程序，进入早期用户空间开始执行；

临时文件系统的初始化程序模块，用于调用所述虚拟机监控器在所述临时文件系统中注册的钩子函数；

钩子函数模块，用于启动所述虚拟机监控器的加载过程，等待所述虚拟机监控器在早期用户空间加载完成后返回执行所述临时文件系统的初始化程序；

所述临时文件系统的初始化程序模块，还用于在所述虚拟机监控器加载完成之后，完成对磁盘上的真正根文件系统的安装，并将控制权移交给所述真正根文件系统下的初始化程序，开始进入用户空间执行。

9.一种电子设备，包括：

至少一个处理器；以及

与所述处理器通信连接的至少一个存储器，其中：

所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行如权利要求1至7任一所述的方法。

10.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求1至7任一所述的方法。