CN113448682A

CN113448682A - Virtual machine monitor loading method and device and electronic equipment

Info

Publication number: CN113448682A
Application number: CN202010231214.5A
Authority: CN
Inventors: 刘双; 闫守孟; 翟征德; 秦凯伦; 龙勤
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-03-27
Filing date: 2020-03-27
Publication date: 2021-09-28
Anticipated expiration: 2040-03-27
Also published as: CN113448682B

Abstract

The embodiment of the specification discloses a method, a device and an electronic device for loading a virtual machine monitor, wherein an operating system, a dynamic trusted module, a virtual machine and a virtual machine monitor for managing the virtual machine are configured on a host machine, and the method comprises the following steps: the method comprises the steps of calling a dynamic trusted module according to an operating system of a host, determining an integrity measurement value corresponding to a virtual machine monitor based on the dynamic trusted module, expanding the integrity measurement value in a PCR register of a TPM, loading the virtual machine monitor according to the integrity measurement value, degrading the operating system to a client mode based on the virtual machine monitor, and safely loading the virtual machine monitor.

Description

Virtual machine monitor loading method and device and electronic equipment

Technical Field

The embodiment of the specification relates to the technical field of computers, in particular to a virtual machine monitor loading method and device and electronic equipment.

Background

Currently, one or more virtual machines are typically created on a physical machine (or host machine) to achieve reasonable utilization of physical machine resources. Here, a virtual machine refers to a complete physical machine system having complete hardware system functions, which is simulated by software and runs in a completely isolated environment, and can be used to run a specific business application (e.g., a confidential application).

In addition, the virtual machine established on the host machine can be created, destroyed, started, restarted, closed, viewed, modified, suspended and the like through the virtual machine monitor. However, if the virtual machine monitor is subject to a security attack (e.g., is illegally trapped), the security operations of the virtual machine may also be affected.

Disclosure of Invention

In view of this, embodiments of the present specification provide a method and an apparatus for loading a virtual machine monitor, and an electronic device, so as to at least solve the problem in the prior art that security of a service application and service sensitive data cannot be guaranteed due to a security attack on the virtual machine monitor.

The embodiment of the specification adopts the following technical scheme:

an embodiment of the present specification provides a virtual machine monitor loading method, where an operating system, a dynamic trusted module, a virtual machine, and a virtual machine monitor used for managing the virtual machine are configured on a host, where the virtual machine monitor loading method includes: calling the dynamic trusted module based on the operating system of the host; determining an integrity measurement value corresponding to the virtual machine monitor based on the dynamic trusted module, and extending the integrity measurement value in a PCR register of a TPM; loading the virtual machine monitor based on the integrity metric value; based on the virtual machine monitor, degrading the operating system to a guest mode.

An embodiment of the present specification provides a virtual machine monitor loading device, where an operating system, a dynamic trusted module, a virtual machine, and a virtual machine monitor for managing the virtual machine are configured on a host, where the virtual machine monitor loading device includes: the dynamic trusted root calling unit is used for calling the dynamic trusted module based on the operating system of the host machine; the dynamic trusted root execution unit determines an integrity measurement value corresponding to the virtual machine monitor based on the dynamic trusted module and expands the integrity measurement value in a PCR register of the TPM; a virtual machine monitor loading unit which loads the virtual machine monitor based on the integrity metric value; and the system mode reduction unit is used for reducing the operating system into a client mode based on the virtual machine monitor.

An embodiment of the present specification further provides an electronic device, including: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method as described above.

The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects:

the virtual machine monitor is loaded after the operating system is started, so that the virtual machine monitor does not need to process various hardware initialization operations, and lower deployment and maintenance cost can be realized. In addition, whether the virtual machine monitor is trusted or not is verified by adopting the dynamic trusted module, so that the virtual machine monitor can be loaded in a trusted mode under an untrusted operating system environment. In addition, after the virtual machine monitor is loaded, the operating system is degraded to a client mode, the operating authority of the operating system is reduced, and the safety of the virtual machine monitor can be effectively protected.

Drawings

The accompanying drawings, which are included to provide a further understanding of the specification and are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description serve to explain the specification and not to limit the specification in a non-limiting sense. In the drawings:

FIG. 1 is a system architecture diagram illustrating an example of a virtual machine monitor loading method suitable for use with embodiments of the present specification;

FIG. 2 is a flow diagram illustrating an example of a virtual machine monitor loading method in accordance with an embodiment of the present specification;

FIG. 3 illustrates a signal interaction diagram of an example of a virtual machine service process in accordance with an embodiment of the present description;

fig. 4 illustrates a flow diagram of an example of a process of determining an integrity metric value in accordance with an embodiment of the present description;

FIG. 5 illustrates a flow diagram of an example of determining an integrity metric value for a virtual machine monitor in accordance with an embodiment of the present description;

FIG. 6 is a signal interaction diagram illustrating an example of a virtual machine monitor loading method in accordance with an embodiment of the present description; and

fig. 7 is a block diagram illustrating an example of a virtual machine monitor loading apparatus according to an embodiment of the present specification.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the embodiments of the present disclosure will be described in detail and completely with reference to the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments. All other embodiments, which can be derived by one of ordinary skill in the art from the embodiments given herein without making any creative effort, shall fall within the scope of the implementation of the present specification.

As used herein, the term "include" and its variants mean open-ended terms in the sense of "including, but not limited to. The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first," "second," and the like may refer to different or the same object. Other definitions, whether explicit or implicit, may be included below. The definition of a term is consistent throughout the specification unless the context clearly dictates otherwise.

In this document, the term "Virtual Machine Monitor" (VMM), also known as hypervisor, may refer to a software system running on a physical host Machine to create and manage Virtual machines and to manage Virtual environment operations.

It should be noted that virtualization is a basic supporting technology of cloud computing, and a virtual machine monitor is a core functional component in a virtualization architecture. Currently, in one example of a virtual machine monitor, the virtual machine monitor runs directly on the hardware of the host machine to control the hardware and manage the virtual machine, typically represented as Xen. Such virtual machine monitors have the advantage of operating efficiently, but are costly to deploy and maintain due to the need to be responsible for a large amount of hardware initialization and management work. In another example of a virtual machine monitor, the virtual machine monitor operates in a traditional operating system environment, has better hardware adaptability without directly depending on hardware characteristics, but generally has lower operating efficiency.

The term "trusted execution Environment" (TEE) may refer to an Environment that is protected by hardware mechanisms. The term "Trusted computing base" (TCB) refers to the set of all security mechanisms, which may be present in hardware, firmware and software, for implementing security protection of a computer system. Once a program error or a potential safety hazard occurs to a certain component of the trusted computer base, the safety of the whole system is damaged.

The term "TPM" (Trusted Platform Module) may refer to a chip that is planted inside a computer to provide a root of trust for the computer. The term "PCR" (platform status register) is a register used to record the running status of the system, and is a core device inside the TPM, and in order to prevent the PCR value from being arbitrarily tampered or forged by malicious code, the TPM restricts the operation of the platform status register.

Furthermore, the term "Dynamic trusted module" (or Dynamic Root of Trust) (DRTM, Dynamic Root of Trust for measures) may refer to a functional module that provides Dynamic trusted boot on a CPU. The dynamic root of trust is a dynamic Trusted boot technique standardized by the international TCG (Trusted Computing Group), which allows a running system, which may be in an unsecure state, to complete the measurement of a TCB chain, and then Trusted boot and measurement of other components are achieved by partially resetting computer resources to bring the system into an initial secure state through the dynamic chain. And, the term "integrity metric value" may represent a value determined by the root of trust to measure against the component to ensure that the integrity of the code to which the component corresponds has not been compromised.

The term "Static Root of Trust" (SRTM) may refer to a trusted module that is started at the boot-up phase of an operating system based on a Core Root of Trust (CRTM) and establishes a Static chain of Trust.

In addition, the term "Boot Processor" (BSP) and the term "Application Processor" (AP) may respectively denote two types of processors defined by MP (multi Processor) system initialization protocols, and after the MP system is powered on or reset, the system hardware dynamically selects one of the processors on the system bus as the Boot Processor and designates the remaining processors as the Application processors.

In the related art, there are some TPM-based trusted boot schemes, such as a static root of trust boot scheme, which implement trusted loading of a virtual machine monitor. Specifically, the BIOS (Basic Input Output System) measures the integrity of the Boot Loader when the Boot Loader is loaded, and extends the measurement value into the PCR. When the Boot Loader loads an Operating System (OS), the Boot Loader measures the integrity of the OS and extends the measured values into the PCR. When the OS needs to load the virtual machine monitor, it first measures the integrity of the virtual machine monitor, extends the measurement values into the PCR registers of the TPM, then loads the virtual machine monitor and hands over control to it. This leaves the integrity metrics of the platform boot chain in the PCR registers of the TPM, recording the integrity of each platform component in the boot chain as it is loaded.

Furthermore, when the virtual machine needs to request services (e.g., secure computing applications or user sensitive data) from a remote server or software, and the remote server or software needs to prove platform integrity, the software or server may obtain an integrity report (Quote) from the virtual machine, the Quote being signed (or signed) with the TPM's AK private key, and any person with knowledge of the AK public key can verify the Quote. In addition, the Quote generally contains a set of TPM register values and a challenge number (challenge) from a remote verifier, which can be used to prove the integrity of the boot process of the virtual machine monitor to the remote verifier.

However, the above-mentioned solutions in the related art at present have at least the following drawbacks:

in one aspect, the integrity measurement of the startup process of the virtual machine monitor presents a window of security attacks. Because the loading times of the OS and the virtual machine monitor are not consistent (e.g., in the case of loading the operating system first and then the virtual machine monitor), the trusted boot technique can only measure the integrity of the OS at the time the OS itself is loaded, and cannot provide integrity information of the OS at the time the virtual machine monitor is loaded. Thus, after the OS itself is loaded and before the virtual machine monitor is loaded, the OS may be controlled by an attacker because of the vulnerability, and at this time, the intruded OS may start a malicious or leaky virtual machine monitor and extend a complete and well-conditioned metric value of the virtual machine monitor into the PCR of the TPM to implement spoofing of a verifier (e.g., a remote server or software), which may result in data theft in the user's secure computing application. Therefore, the static trusted root can ensure the credibility of the operating system in the starting-up stage, the probability of being attacked and hijacked by hackers is higher and higher along with the increase of the service time of the operating system, and the operating system can only be recovered by restarting the operating system after the trust chain is broken.

On the other hand, the TCB in TPM-based trusted boot technologies is too large. In particular, trusted TPM-based boot techniques require that bulky OS's be included in the TCB as well. Since the security of the virtual machine is directly dependent on the integrity of the virtual machine monitor, the integrity of the virtual machine monitor boot process is in turn dependent on the integrity of the OS. The OS is typically bulky, containing millions or even tens of millions of lines of code, and such code typically contains many security holes, while security holes contained in the TCB can lead to the vulnerability of the TEE.

Fig. 1 is a system architecture diagram illustrating an example of a virtual machine monitor loading method suitable for applying the embodiments of the present specification.

As shown in fig. 1, host 110 may be configured with one or more virtual machines (e.g., virtual machines 121, 123.. 12n), and also configured with a virtual machine monitor 130 for managing the virtual machines. In addition, an operating system 140, such as a Windows, Android, IOS operating system, etc., is also configured on the host 110, which may not be limited herein. A dynamic trusted module 150 is also configured on host 110 to provide for trusted loading of software modules at any time (e.g., non-operating system initialization phase).

It should be understood that hardware modules, such as processor 160, memory (not shown), and disk (not shown), may also be provided on host 110 for supporting the normal operation of one or more of the software or configurations described above. In some examples of embodiments of the present specification, the structure of processor 160 may conform to an MP system configuration and may include a boot processor and an application processor.

In some application scenarios, after the virtual machine is started, when the virtual machine interacts with the remote server 190 to request a service (e.g., running a user application or accessing confidential data), the virtual machine needs to send an integrity report (e.g., the integrity report may contain relevant metric information for the virtual machine monitor) to the remote server 190 for verification, and provide the service if the verification passes, and not provide the service if the verification fails.

It should be understood that the architecture as described in fig. 1 is for example only, and is not intended to limit the scope of implementations of the present description, e.g., some of the architecture in remote server 190 or host 110 may not be retained in some cases.

Fig. 2 is a flowchart illustrating an example of a virtual machine monitor loading method according to an embodiment of the present specification.

As shown in FIG. 2, in step 210, a dynamic trusted module is called based on the operating system of the host.

It should be noted that, the virtual machine monitor in this embodiment is loaded by the operating system, rather than directly managing the virtual machine on the hardware of the host (such as some types of virtual machine monitors described above), and it is not necessary to handle various hardware initialization operations, and thus lower deployment and maintenance costs can be achieved.

In step 220, an integrity measurement value corresponding to the virtual machine monitor is determined based on the dynamic trusted module and the integrity measurement value is extended in a PCR register of the TPM.

In the embodiment of the present specification, by measuring the virtual machine monitor through the dynamic trusted module, compared with the static trusted boot module, it is achieved that the trusted measurement can be performed at any time (for example, at system boot or when there is a business requirement) without being limited to the system boot phase, and can be directly invoked when there is a business requirement without performing a reboot process of the operating system.

In step 230, the virtual machine monitor is loaded based on the integrity metric value. Illustratively, a load operation for the virtual machine monitor is automatically triggered when a metric operation for the virtual machine monitor is completed (or when an integrity metric value is generated).

In step 240, the operating system is reduced to a guest mode based on the virtual machine monitor. Therefore, the operating system is degraded into a client mode, the operating authority of the operating system is reduced, and the safety of the virtual machine monitor can be effectively protected.

It should be noted that, at present, the process of starting the virtual machine based on the dynamic root of trust is performed independently of the operating system (e.g., AWS product), for example, the virtual machine is started by the dynamic root of trust, and the operating system is restarted by using the virtual machine. Therefore, the virtual machine needs to handle various initialization operations of the hardware platform, resulting in high deployment and maintenance costs. In contrast, in the embodiment of the present specification, hardware initialization work at the time of system startup is handed to the operating system, and the virtual machine monitor is loaded by the operating system, so that the embodiments also have the advantages of relatively small code size, convenience in deployment, and low maintenance cost.

In addition, the dynamic trusted module excludes the OS from the TCB of the TEE, and trusted loading of the virtual machine monitor can be still achieved even if the operating system is controlled by an attacker to be in an untrusted state. Furthermore, the dynamic trusted module can maintain a small size of the TCB, greatly improving TEE security and robustness.

In addition, the integrity metric value obtained by the dynamic trusted module can reliably reflect the integrity of the virtual machine monitor in the starting process, and can provide reliable proof for remote verification.

There may be a plurality of trigger conditions for the step 210 described above, and in one example of an embodiment of the present specification, the method further comprises: and starting the operating system to initialize the hardware of the host machine. And then, triggering the operation system based on the host machine to call the dynamic trusted module based on the starting of the operation system. Therefore, the virtual machine monitor can be automatically triggered to be loaded when the operating system is started.

In another example of an embodiment of the present specification, the method further comprises: and acquiring a virtual machine operation request. And then, judging that the obtained virtual machine operation request meets the preset virtual machine operation condition, and triggering the operation system based on the host machine to call the dynamic trusted module when the obtained virtual machine operation request meets the condition. Illustratively, when there is an operation request to create a new virtual machine or an operation request to start a virtual machine involving a sensitive application, the virtual machine monitor needs to be loaded, and the dynamic trusted module can be called to directly perform the operation without performing a restart operation. It should be understood that the preset virtual machine operating conditions may be established according to different service needs, and may meet personalized requirements of the service.

As a further disclosed and optimized implementation of the embodiments of the present specification, after degrading the operating system to the guest mode, a trusted execution environment may also be built based on the virtual machine monitor, so that the virtual machine can run in the built trusted execution environment.

Fig. 3 shows a signal interaction diagram of an example of a virtual machine service process according to an embodiment of the present specification.

As shown in FIG. 3, operating system 310 passes the call instruction to the dynamic trusted module in step 311.

In step 313, the running dynamic trusted module 320 determines an integrity metric value corresponding to the virtual machine monitor. Here, a latent or existing dynamic trusted module, such as Intel TXT or AMD Secure Execution Mode, etc., may be used.

In step 315, the dynamic trusted module 320 extends the integrity measurement in the PCR register of the TPM. As described above, the PCR registers of the TPM have high security and can be protected from malicious tampering or forgery, and the integrity measurement values corresponding to the virtual machine monitor can be extended from the PCR registers to the values of the corresponding PCR registers.

In some embodiments, the TPM may sign the values of the PCR registers using the AK, vouching for the authenticity of the PCR register contents, and then generate an integrity report for remote verification. It should be understood that other information not described herein may also be included in the integrity report and are within the scope of implementations of the present description.

In step 317, dynamic trusted module 320 passes the load instruction to virtual machine monitor 330, for example, the load instruction may be automatically passed after dynamic trusted module 320 completes the measurement.

In step 319, virtual machine monitor 330 performs the load operation and obtains an integrity report. As described above, the integrity report may be obtained from the TPM.

In step 3211, virtual machine monitor 330 passes the load instruction to virtual machine 340. Here, an integrity report may also be included in the load instruction.

In step 3213, the virtual machine monitor 330 passes the virtualization operation instructions to the operating system 310. Here, based on the virtualization operation instruction, the operating system enters a guest mode and continues to run to secure the security of the virtual machine monitor itself.

In step 323, virtual machine 340 may perform a load operation and receive an integrity report.

In step 325, virtual machine 340 sends a service request containing an integrity report to remote server 350. Here, the integrity report is used as a security credential for authentication when the virtual machine requests service from a remote server.

In step 327, remote server 350 verifies whether the virtual machine monitor is trusted based on the integrity report. Illustratively, information about integrity metric information, PCR value, and the like of the virtual machine monitor is registered in advance on the remote server 350, and it is possible to verify whether the virtual machine monitor is trusted through an information comparison operation.

If the determination in step 327 indicates authenticity, the process jumps to step 331. If the determination in step 327 indicates untrusted, a jump is made to step 329.

In step 331, remote server 350 provides services to virtual machine 340.

Additionally, in step 329, remote server 350 denies the service. Therefore, services can be prevented from being provided for the untrusted virtual machine, and the security of confidential applications and user sensitive data can be guaranteed.

In the embodiment of the specification, the dynamic trusted root is enabled under the operating system, the virtual machine monitor is loaded, the deployment is convenient, the maintenance cost is reduced, and the reliability of the measurement result can be ensured by enabling the dynamic trusted root under the operating system, and loading the virtual machine monitor after recovering the trusted execution environment from the untrusted environment. In addition, after the virtual machine monitor is loaded, the virtual machine monitor dynamically takes over the hardware, and the operating system is reduced to a client mode, so that malicious operation of the operating system on the virtual machine monitor can be prevented, and the safety of the virtual machine monitor is guaranteed.

Fig. 4 shows a flowchart of an example of a process of determining an integrity metric value according to an embodiment of the present description.

As shown in FIG. 4, in step 410, images of the virtual machine monitor and the dynamic trusted module are loaded into the secure memory area based on the operating system. Here, the secure Memory area prohibits a read/write operation in a DMA (Direct Memory Access) manner, thereby preventing a physical device from being accessed by the DMA manner.

In step 420, the image of the dynamic trusted module is executed to measure the memory image of the virtual machine monitor to determine a corresponding integrity metric value.

In embodiments of the present description, a dynamic trusted module and a virtual machine monitor are loaded into a secure memory area, and a root-of-trust metric is executed in the secure memory area. And the virtual machine monitor and the dynamic trusted module are directly read or measured from the disk, so that malicious tampering in the process of loading the disk into the memory can be avoided, and the safety of the measurement process is further ensured.

It should be noted that, when the dynamic trusted module measures the virtual machine monitor, all the physical memory of the virtual machine needs to be accessed. Since the size of the virtual machine monitor is typically large and may not be continuously distributed in physical memory, the measurement process may be slow or even impossible. In view of this, the embodiments of the present specification may also perform the following operations: and constructing a page table corresponding to the memory image of the virtual machine monitor. Furthermore, when performing an integrity measurement operation, an image of the dynamic trusted module may be executed, and a memory image of the virtual machine monitor is accessed and measured through the page table to determine a corresponding integrity measurement value.

Therefore, the memory mirror image of the virtual machine monitor is continuously measured through the page table, so that the measurement operation can be reliably and continuously carried out, and the efficiency of integrity measurement and the reliability of a measurement result are guaranteed.

Fig. 5 illustrates a flow diagram of an example of determining an integrity metric value of a virtual machine monitor in accordance with an embodiment of the present description. Here, the processor has an MP system configuration, that is, a boot processor and at least one application processor are configured in the host.

In step 510, the boot processor is restarted based on the dynamic trusted module and stops running the respective application processor.

In step 520, a dynamic trusted module is invoked based on the boot processor to determine an integrity metric value corresponding to the virtual machine monitor. In some examples of embodiments of the present specification, a dynamic root of trust may be a piece of code provided by a CPU vendor with a signature on which the CPU checks to ensure that it is the correct and authentic dynamic root of trust when it is loaded.

In this embodiment of the present specification, the dynamic trusted root, by controlling the CPU running state, stops other non-main CPUs (i.e., application processors) except the main CPU (i.e., boot processor), restarts the running state of the main CPU, and reestablishes a clean (clean) hardware execution environment, may get rid of interference from the current OS untrusted execution environment, and ensure the security of the environment that measures the virtual machine monitor. Therefore, after the dynamic trusted root is loaded, the integrity of the virtual machine monitor can be measured in a clean CPU state and is extended to the PCR register, and the authenticity of the integrity measurement value of the virtual machine monitor is ensured.

In some application scenarios, some external business applications are already running on the operating system of the cloud server when the operating system is running normally. However, when a clean CPU state is built by the above operation, the business application is temporarily disabled. Thereafter, after the os is degraded to client mode (e.g., virtualization mode is enabled on each CPU in turn), if the os is reloaded using a normal virtual machine boot method, the whole boot process may last longer (even up to the order of minutes), which is not acceptable in the cloud server.

In view of this, the virtual machine monitor loading method in this embodiment may further include the following operations: the operating state of each processor in the host is saved based on the operating system before the dynamic trusted module is called by the host-based operating system. And after the operating system is degraded to the client mode, restoring each application processor to the saved corresponding running state based on the virtual machine monitor. In this way, by directly restoring the saved running state of the CPU, the operating system can be efficiently restored to the previous running state of the service, and the loading process of the virtual machine monitor is fast (for example, millisecond level), so that the interruption process of the cloud server is not obviously perceived by the user, and the normal service of the host (for example, the cloud server) is not affected while the virtual machine monitor is loaded.

The virtual machine monitor used in some examples of embodiments herein may be referred to as a Type1.5hypervisor (also referred to as a Type 3hypervisor or a Type1.5 hypervisor), which is responsible for loading by the OS, but once running can take over system hardware and fully virtualize the OS. In addition, the type1.5hypervisor has the advantages that hardware initialization work is handed to an operating system when the system is started, so the code size is small, the deployment is convenient, and the maintenance cost is low. Furthermore, type1.5hypervisor may be used to build trusted computing environments (TEE) that may ensure that an application or a portion of an application runs in a secure computing environment to avoid threats from OS security breaches or other security-compromised applications on top of the OS.

When building a TEE based on type1.5hypervisor, the integrity of the hypervisor startup process is critical, since the security of both user applications and data in the TEE depends on the hypervisor.

When a TEE is built based on type1.5hypervisor, the OS loads the hypervisor image from disk to a specified memory when needed, and then jumps to the hypervisor entry function. After the hypervisor starts to execute, the hardware is managed, the hardware runs in the highest-authority hardware mode, and the operating system is degraded to be the virtual machine operating system.

However, the process of loading hypervisors may face a variety of attacks. In one form of attack, an OS that is malicious or otherwise controlled by an attacker because it contains a vulnerability injects malicious code by modifying the type1.5hypervisor memory image, thereby controlling the hypervisor. Under another attack form, a malicious OS can intentionally load the hypervisor of the old version, and then further control the hypervisor by utilizing software bugs on the old version, thereby achieving the purpose of attack. In these attacks, the attacker may be a hacker from the network, or an internal employee with malicious mind.

In view of this, in some examples of the embodiments of the present specification, the Type1.5Hypervisor (or Type1.5 Hypervisor) is securely loaded in the untrusted OS environment through the dynamic root of trust, and the Hypervisor memory image is measured to generate the measurement value, so as to provide a trusted basis for remote verification. It should be noted that the dynamic root of trust can implement trusted loading of software modules (such as hypervisor, OS, and the like) at any time, and another significant advantage is that the trusted computing base is small, and an OS that is bulky and has many potential vulnerabilities can be excluded from the TCB, and the like. Also, a dynamic root of trust may require special hardware support, such as Intel's Trusted Execution Technology (TXT), and corresponding hardware may be present in some Intel architecture based chipsets.

Fig. 6 is a signal interaction diagram illustrating an example of a virtual machine monitor loading method according to an embodiment of the present specification. Here, the operating system 610 may manage hardware and system resources, be responsible for completing hardware initialization, and load the virtual machine monitor when needed. Dynamic trusted module 620 (or dynamic root of trust) is a functional module on the CPU that provides dynamic trusted boot. After being started, the virtual machine monitor 630 is responsible for constructing a trusted computing environment, running security-sensitive user applications, processing sensitive user data, and the like.

As shown in FIG. 6, in step 601, the operating system 610 is started to initialize the platform hardware.

In step 603, when a service requirement for creating a virtual machine occurs, the operating system 610 loads the virtual machine monitor image and the dynamic root of trust image into the protected memory area. Here, the protected memory area specifically refers to a protected memory area that prevents a physical device from reading and writing in a DMA manner.

Operating system 610 then launches dynamic root of trust 620.

In step 605, the dynamic trusted module 620 restarts the operating status of the main CPU, stops other non-main CPUs except the main CPU, and reestablishes a clean execution environment by controlling the operating status of the CPUs.

In step 607, the dynamic trusted module 620 measures the virtual machine monitor image and extends the measurement values to the PCR registers of the TPM. Here, the metric value may be pre-registered with a remote authentication server, and during the remote authentication process, the PCR register value and the metric value for the virtual machine monitor therein may be included in a remote authentication report to prove the trustworthiness of the virtual machine monitor.

When the dynamic trusted module measures Type1.5hypervisor, all physical memories where the hypervisor is located need to be accessed. Since Type1.5hypervisor is typically more than one 4KB physical page frame (page frame) in size and is not necessarily contiguously distributed in physical memory. Therefore, a page table (page table) containing all physical memory areas of the Hypervisor needs to be provided for the dynamic trusted module.

In particular, the dynamic trusted module may be invoked based on the page table by: the format of the page table may be selected as PAE x86_32 bit, the page table is compiled into a Type1.5hypervisor mirror header by a chaining script, and specifies the virtual address of the Type1.5hypervisor load. Here, the page table contains only the mapping of code and read-only segments, and does not contain data and read-write segments. Furthermore, it is also possible to limit the code and read-only segment size to no more than 2MB, with the last level page table entries all grouped in one 4KB physical page frame, and the entire page table requiring only 3 consecutive physical pages. Furthermore, the starting physical address of the page table is informed to the dynamic trusted module by a shared memory method.

Dynamic trusted module 620 may then launch virtual machine monitor 630.

In step 609, the virtual machine monitor 630 begins running and may take over the system hardware.

In step 611, virtual machine monitor 630 recovers the other non-host CPUs that were halted by dynamic trusted module 620.

In step 613, the virtual machine monitor 630 downgrades the operating system to guest mode.

It should be noted that before loading the virtual machine monitor, the operating system runs in a high-privilege mode of the CPU (e.g., vmx root mode), and after degrading to the client mode, the operating system runs in a low-privilege mode (e.g., CPU vmx non-root mode), which can ensure that the virtual machine monitor fully takes over the control of the whole system.

Here, if the os virtual machine starts up from the BIOS and then reloads the os, the entire boot process lasts on the order of seconds or even minutes. In the application scenario incorporated in the present solution, the operating system may be running an application providing an external service before the Type1.5hypervisor is started. However, the normal way of starting the virtual machine may result in the services being unavailable for a long time, which is not acceptable in the cloud server.

In some examples of this specification embodiment, before starting the dynamic trusted module, the operating system may save all the running states of the CPU at this time to a shared memory with the Type1.5hypervisor, and when the Type1.5hypervisor starts the virtual machine, restore the CPU state of the virtual machine through the saved states in the shared memory.

Specifically, this can be achieved by: the BIOS reserves a shared memory in advance, saves the initial physical address of the memory in a register (BASE), and saves the SIZE of the memory in a register (SIZE). Then, the operating system reads the BIOS BASE and SIZE registers to get the shared memory starting physical address and SIZE, maps to the operating system address space, and initializes. Then, the operating system saves the running state of each CPU at this time (including stack pointer (stack pointer), current Instruction (IP), various segment registers (GDTR, CS, DS, ES, FS, GS), interrupt vector table (IDTR), state registers (CR0, CR3, CR4), and other registers (TSS, EFER, LSTAR)) to the shared memory. Thereafter, type1.5Hypervisor reads BIOS BASE and SIZE registers to get the shared memory starting physical address and SIZE. Therefore, the CPU state stored in the shared memory is read before the Virtual machine of the operating system is started, and the Virtual machine control structure (Virtual machine control structure) of the client machine is filled, so that the Virtual machine of the operating system directly returns to the state before the dynamic trusted module is loaded.

In step 615, the operating system 610 continues with subsequent operations in the client mode.

In some examples of this specification embodiment, in an untrusted execution environment of an operating system, the type1.5hypervisor may be loaded using a dynamic root of trust, an integrity measurement value of the type1.5hypervisor may be extended to a PCR register of a TPM, and after the virtual machine monitor completes loading, the operating system may be reduced to a client mode, thereby ensuring security of the virtual machine monitor itself in a subsequent running process of the host.

Fig. 7 is a block diagram illustrating an example of a virtual machine monitor loading apparatus according to an embodiment of the present specification. In connection with the above example as in fig. 1, an operating system, a dynamic trusted module, a virtual machine, and a virtual machine monitor for managing the virtual machine may be configured on the host machine.

As shown in fig. 7, the virtual machine monitor loading apparatus 700 includes a dynamic root of trust calling unit 710, a dynamic root of trust executing unit 720, a virtual machine monitor loading unit 730, a system mode reduction unit 740, a CPU state saving unit 750, a CPU state restoring unit 760, a page table building unit 770, a system booting unit 780, and a virtual machine request obtaining unit 790.

The dynamic root of trust invocation unit 710 is configured to invoke the dynamic trusted module based on the operating system of the host.

The dynamic root of trust execution unit 720 is configured to determine an integrity measurement value corresponding to the virtual machine monitor based on the dynamic trusted module and extend the integrity measurement value in a PCR register of the TPM.

In some embodiments, dynamic root of trust execution unit 720 includes a processor configuration module (not shown) and a dynamic root of trust invocation module (not shown). Here, the processor configuration module is configured to restart the boot processor based on the dynamic trusted module and stop running each of the application processors. A dynamic root of trust invocation module is configured to invoke the dynamic trusted module based on the boot processor to determine an integrity metric value corresponding to the virtual machine monitor.

The virtual machine monitor loading unit 730 is configured to load the virtual machine monitor based on the integrity metric value.

The system mode reduction unit 740 is configured to reduce the operating system to a client mode based on the virtual machine monitor.

CPU state preservation unit 750 is configured to preserve the running state of the various processors in the host based on the operating system before calling the dynamic trusted module based on the operating system of the host.

The CPU state restoration unit 760 is configured to restore the respective application processors to the saved respective running states based on the virtual machine monitor after the operating system is degraded to the client mode.

In some embodiments, the CPU state saving unit 750 is configured to save the running state of each processor in the host to a shared memory for the virtual machine monitor based on the operating system, and the CPU state restoring unit 760 is configured to restore each application processor to the corresponding running state saved in the shared memory based on the virtual machine monitor.

In some examples of embodiments of the present description, dynamic root of trust call unit 710 includes a protected memory load module (not shown) and a memory mirror metric module (not shown). Here, the protected memory loading module is configured to load the images of the virtual machine monitor and the dynamic trusted module into a secure memory area based on the operating system, where the secure memory area prohibits DMA-based read and write operations. And the memory mirror image measurement module is configured to execute the mirror image of the dynamic trusted module and measure the memory mirror image of the virtual machine monitor to determine the corresponding integrity measurement value.

The page table building unit 770 is configured to build a page table corresponding to a memory image of the virtual machine monitor. Correspondingly, the memory image measurement module executes the image of the dynamic trusted module, and accesses and measures the memory image of the virtual machine monitor through the page table to determine the corresponding integrity measurement value.

The system booting unit 780 is configured to boot the operating system to perform an initialization operation on the hardware of the host. Accordingly, the dynamic root of trust invocation unit 710 includes: a first call triggering module (not shown) that triggers the operating system based on the host to call the dynamic trusted module based on the startup of the operating system.

The virtual machine request obtaining unit 790 is configured to obtain a virtual machine operation request. Accordingly, the dynamic root of trust invocation unit 710 includes: and a second call triggering module (not shown) for triggering the operating system based on the host machine to call the dynamic trusted module when the obtained virtual machine operation request meets a preset virtual machine operation condition.

It should be noted that some of the units in the apparatus 700 described above are not necessary or optional in some application scenarios. Illustratively, in some embodiments, the CPU state preservation unit 750, the CPU state restoration unit 760, the page table building unit 770, the system boot unit 780, and the virtual machine request fetch unit 790 may not be retained. It should be understood that when CPU state restoration unit 760 is provided in apparatus 700, apparatus 700 should also include CPU state preservation unit 750.

Embodiments of a virtual machine monitor loading method and apparatus according to embodiments of the present specification are described above with reference to fig. 1 to 7. The details mentioned in the above description of the method embodiments also apply to the embodiments of the apparatus of the present description. The above virtual machine monitor loading device may be implemented by hardware, or may also be implemented by software, or a combination of hardware and software.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functions of the various elements may be implemented in the same one or more software and/or hardware implementations of the present description.

As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.

Embodiments of the present description are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The embodiments of this specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The described embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present specification, and is not intended to limit the present specification. Various modifications and alterations to this description will become apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A virtual machine monitor loading method, wherein an operating system, a dynamic trusted module, a virtual machine and a virtual machine monitor for managing the virtual machine are configured on a host machine, and the virtual machine monitor loading method comprises the following steps:

calling the dynamic trusted module based on the operating system of the host;

determining an integrity measurement value corresponding to the virtual machine monitor based on the dynamic trusted module, and extending the integrity measurement value in a PCR register of a TPM;

loading the virtual machine monitor based on the integrity metric value;

based on the virtual machine monitor, degrading the operating system to a guest mode.

2. A virtual machine monitor loading method according to claim 1, a boot processor and at least one application processor being configured in the host,

determining an integrity metric value corresponding to the virtual machine monitor based on the dynamic trusted module specifically includes:

restarting the boot processor based on the dynamic trusted module and stopping running each application processor; and

invoking the dynamic trusted module based on the boot processor to determine an integrity metric value corresponding to the virtual machine monitor.

3. A virtual machine monitor loading method according to claim 2, wherein prior to invoking the dynamic trusted module based on the operating system of the host, the method further comprises:

based on the operating system, saving the running state of each processor in the host machine;

wherein after the operating system is degraded to client mode, the method further comprises:

and respectively restoring the application processors to the saved corresponding running states based on the virtual machine monitor.

4. The virtual machine monitor loading method according to claim 3, wherein, based on the operating system, saving the running state of each processor in the host specifically includes:

based on the operating system, saving the running state of each processor in the host machine to a shared memory aiming at the virtual machine monitor;

based on the virtual machine monitor, restoring each application processor to the corresponding stored running state respectively, specifically including:

and respectively restoring the application processors to the corresponding running states stored in the shared memory based on the virtual machine monitor.

5. The virtual machine monitor loading method according to claim 1, wherein the invoking the dynamic trusted module based on the operating system of the host specifically includes:

loading the mirror images of the virtual machine monitor and the dynamic trusted module into a secure memory area based on the operating system, wherein the secure memory area prohibits the read-write operation in a DMA mode;

and executing the mirror image of the dynamic trusted module, and measuring the memory mirror image of the virtual machine monitor to determine the corresponding integrity measurement value.

6. The virtual machine monitor loading method of claim 5, further comprising:

constructing a page table corresponding to the memory image of the virtual machine monitor;

executing the mirror image of the dynamic trusted module, and measuring the memory mirror image of the virtual machine monitor to determine the corresponding integrity measurement value, which specifically includes:

and executing the image of the dynamic trusted module, and accessing and measuring the memory image of the virtual machine monitor through the page table to determine the corresponding integrity measurement value.

7. The virtual machine monitor loading method of claim 1, further comprising:

starting the operating system to perform initialization operation on the hardware of the host machine;

the calling of the dynamic trusted module by the operating system based on the host specifically includes:

and triggering the operating system based on the host machine to call the dynamic trusted module based on the starting of the operating system.

8. The virtual machine monitor loading method of claim 1, further comprising:

acquiring a virtual machine operation request;

and when the obtained virtual machine operation request meets the preset virtual machine operation condition, triggering the operating system based on the host machine to call the dynamic trusted module.

9. A virtual machine monitor loading method as recited in claim 1, after degrading the operating system to a guest mode, the method further comprising:

building a trusted execution environment based on the virtual machine monitor such that the virtual machine is capable of running in the built trusted execution environment.

10. A virtual machine monitor loading device configured with an operating system, a dynamic trusted module, a virtual machine, and a virtual machine monitor for managing the virtual machine on a host, wherein the virtual machine monitor loading device comprises:

the dynamic trusted root calling unit is used for calling the dynamic trusted module based on the operating system of the host machine;

the dynamic trusted root execution unit determines an integrity measurement value corresponding to the virtual machine monitor based on the dynamic trusted module and expands the integrity measurement value in a PCR register of the TPM;

a virtual machine monitor loading unit which loads the virtual machine monitor based on the integrity metric value;

and the system mode reduction unit is used for reducing the operating system into a client mode based on the virtual machine monitor.

11. The virtual machine monitor loading device of claim 10, configured with a boot processor and at least one application processor in the host, wherein the dynamic root of trust execution unit comprises:

a processor configuration module, which restarts the boot processor based on the dynamic trusted module and stops running each application processor; and

a dynamic root of trust invocation module that invokes the dynamic trusted module based on the boot processor to determine an integrity metric value corresponding to the virtual machine monitor.

12. The virtual machine monitor loading device of claim 11, further comprising:

a CPU state saving unit for saving the running state of each processor in the host machine based on the operating system before the operating system based on the host machine calls the dynamic trusted module;

and the CPU state recovery unit is used for recovering the application processors to the saved corresponding running states respectively based on the virtual machine monitor after the operating system is degraded to a client mode.

13. The virtual machine monitor loading device according to claim 12, wherein the CPU state saving unit saves the running state of each processor in the host to a shared memory for the virtual machine monitor based on the operating system; and

and the CPU state recovery unit is used for recovering the application processors to the corresponding running states stored in the shared memory respectively based on the virtual machine monitor.

14. The virtual machine monitor loading device of claim 10, wherein the dynamic root of trust invocation unit comprises:

the protected memory loading module loads the mirror images of the virtual machine monitor and the dynamic trusted module into a secure memory area based on the operating system, wherein the secure memory area prohibits the read-write operation in a DMA mode;

wherein the dynamic root of trust execution unit includes:

and the memory mirror image measurement module executes the mirror image of the dynamic trusted module and measures the memory mirror image of the virtual machine monitor to determine the corresponding integrity measurement value.

15. The virtual machine monitor loading device of claim 14, further comprising:

the page table building unit is used for building a page table corresponding to the memory image of the virtual machine monitor;

the memory image measurement module executes the image of the dynamic trusted module, and accesses and measures the memory image of the virtual machine monitor through the page table to determine the corresponding integrity measurement value.

16. The virtual machine monitor loading device of claim 10, further comprising:

the system starting unit is used for starting the operating system so as to carry out initialization operation on the hardware of the host machine;

wherein the dynamic root of trust calling unit includes:

and the first calling triggering module is used for triggering the operating system based on the host machine to call the dynamic trusted module based on the starting of the operating system.

17. The virtual machine monitor loading device of claim 10, further comprising:

the virtual machine request acquisition unit is used for acquiring a virtual machine operation request;

wherein the dynamic root of trust calling unit includes:

and the second calling triggering module is used for triggering the operating system based on the host machine to call the dynamic trusted module when the obtained virtual machine operation request meets the preset virtual machine operation condition.

18. An electronic device, comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any of claims 1 to 9.