Virtual machine secure loading method, device, equipment and storage medium

Abstract

Embodiments of the present application disclose a virtual machine security loading method, device and equipment and a storage medium, belonging to the technical field of virtual machines. The method comprises the following steps: when a root guest machine is started, reading a core data structure body by using a configuration file to obtain the number of non-root guest machines configured for security detection; when a currently verified non-root guest machine is started, obtaining a corresponding first index by using the core data structure body; finding a first verification value index and a second verification value index of the non-root guest machine in the configuration file of the root guest machine by using the first index and a Jailhouse virtualization trusted structure; reading a first verification value and a second verification value from a TPM NVRAM according to the first verification value index and the second verification value index; verifying the image and the configuration file of the non-root guest machine by using the first verification value and the second verification value; and normally running the non-root guest machine when the verification is passed.

Description

Technical Field

[0001] This invention relates to the field of virtual machine technology, and in particular to a method, apparatus, device, and storage medium for securely loading a virtual machine. Background Technology

[0002] With the development of integrated circuit manufacturing processes, more and more computing units are being integrated onto a single chip. How to more effectively utilize the resources on this single chip to achieve good system scalability has become a crucial issue for system software designers. Currently, deploying a hypervisor on multi-core systems is an effective solution to this problem. The virtualization and isolation capabilities of a hypervisor allow multiple guest operating systems to run on the same hardware platform. Different hardware resources can be configured for different guest applications based on their specific needs, leading to more efficient utilization of hardware resources.

[0003] In the process of developing this invention, the inventors discovered the following technical problem: Currently, the partition virtualization tool Jailhouse uses images and configuration files to create virtual machines when starting non-root guests. However, non-root guest images or configuration files are easily tampered with. If a virtual machine is created using a tampered image and configuration file, the virtual machine may run malicious programs, posing a security risk to multi-core systems. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for securely loading virtual machines, in order to solve the technical problem of high security risks to non-root clients due to image or configuration file tampering in the prior art.

[0005] In a first aspect, embodiments of the present invention provide a method for securely loading a virtual machine, comprising:

[0006] When the root client starts, it uses the root client's configuration file to read the core data structure of the root client's resource layout and obtain the number of non-root clients configured for security checks.

[0007] When the currently verified non-root client starts up, it uses the core data structure of its own non-root client resource layout to obtain the corresponding first-level index. The first-level index is used to locate the verification address in the Jailhouse virtualization trusted structure in the root client's configuration file for the non-root client.

[0008] Using the first-level index and the Jailhouse virtualization trusted structure, the first and second authentication value indices of the non-root client are searched in the configuration file of the root client;

[0009] The first verification value and the second verification value are read from the TPM NVRAM according to the first verification value index and the second verification value index;

[0010] The image and configuration file of the currently verified non-root client are verified using the first verification value and the second verification value;

[0011] If the verification passes, the non-root client being verified will run normally.

[0012] Secondly, embodiments of the present invention also provide a virtual machine secure loading device, comprising:

[0013] The read module is used to read the core data structure of the root client's resource layout using the root client's configuration file when the root client starts up, and to obtain the number of non-root clients configured for security checks.

[0014] The acquisition module is used to obtain the corresponding first-level index by utilizing the core data structure of its own non-root client resource layout when the currently verified non-root client starts up. The first-level index is used to locate the verification address for the non-root client in the Jailhouse virtualization trusted structure in the root client's configuration file.

[0015] The lookup module is used to look up the first and second authentication value indices of the non-root client in the configuration file of the root client using the first-level index and the Jailhouse virtualization trusted structure.

[0016] The verification value reading module is used to read the first verification value and the second verification value from the TPM NVRAM according to the first verification value index and the second verification value index;

[0017] The verification module is used to verify the image and configuration file of the currently verified non-root client using the first verification value and the second verification value.

[0018] The runtime module is used to run the currently validated non-root client normally when the validation passes.

[0019] Thirdly, embodiments of the present invention also provide an apparatus, comprising:

[0020] One or more processors;

[0021] Storage device for storing one or more programs.

[0022] When the one or more programs are executed by the one or more processors, the one or more processors implement the virtual machine secure loading method provided in the above embodiments.

[0023] Fourthly, embodiments of the present invention also provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the virtual machine secure loading method provided in the above embodiments.

[0024] The virtual machine secure loading method, apparatus, device, and storage medium provided in this invention, by reading the core data structure of the root client's resource layout using the root client's configuration file when the root client starts, obtains the number of non-root clients configured for security detection; when a currently verified non-root client starts, it uses its own core data structure of non-root client resource layout to obtain the corresponding first-level index, which is used to locate the verification address for the non-root client in the Jailhouse virtualization trusted structure in the root client's configuration file; using the first-level index and the Jailhouse virtualization trusted structure, it searches for the first and second verification value indices of the non-root client in the root client's configuration file; it reads the first and second verification values ​​from TPMNVRAM according to the first and second verification value indices; it verifies the image and configuration file of the currently verified non-root client using the first and second verification values; and when the verification passes, it runs the currently verified non-root client normally. By writing the hash values ​​of the non-root client image and configuration file into TPM NVRAM, and verifying them by reading TPM NVRAM when loading the non-root client, the integrity and security of the non-root client image and configuration file data are verified. Prevents non-root client images from being replaced or tampered with, and from running malicious programs. Improves the security of Jailhouse multi-core systems. Attached Figure Description

[0025] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0026] Figure 1 This is a flowchart illustrating the secure loading method for virtual machines provided in Embodiment 1 of the present invention;

[0027] Figure 2 This is a flowchart illustrating the secure loading method for virtual machines provided in Embodiment 2 of the present invention;

[0028] Figure 3 This is a flowchart illustrating the secure loading method for virtual machines provided in Embodiment 3 of the present invention;

[0029] Figure 4 This is a schematic diagram of the structure of the virtual machine secure loading device provided in Embodiment 4 of the present invention;

[0030] Figure 5This is a schematic diagram of the device provided in Embodiment 5 of the present invention. Detailed Implementation

[0031] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0032] Example 1

[0033] Figure 1 This is a flowchart illustrating the secure loading method for virtual machines provided in Embodiment 1 of the present invention. This embodiment is applicable to the secure loading of non-root virtual machines in a Jailhouse multi-core system. The method can be executed by a secure virtual machine loading device and specifically includes the following steps:

[0034] Step 110: When the root client starts, use the root client's configuration file to read the core data structure of the root client's resource layout and obtain the number of non-root clients configured for security checks.

[0035] The root cell is a privileged partition created in-situ by the running kernel when Jailhouse is enabled. It exists first after the system powers on, owns all physical resources, and is responsible for subsequent resource reallocation. It possesses the highest privileges.

[0036] Non-root cells are explicitly created by the user after the root cell starts up, and can be created using the Jailhouse command. Their resources are transferred to the root cell after it goes offline; non-root cells have exclusive access to the allocated resources.

[0037] Both root clients and non-root clients require their own configuration files to start. These configuration files describe information such as their reserved memory areas, CPU bitmaps, and interrupt settings.

[0038] The root client's configuration file contains a core data structure for the root client resource layout, which defines the core data structure for the resource layout of a client (including root clients and non-root clients). It is equivalent to the header of a "partition configuration file," describing the configuration of key resources such as the client's CPU, memory, interrupts, and PCI devices. In this embodiment, an additional parameter is added to the core data structure for the root client resource layout to describe the number of non-root clients configured for security checks. The core data structure for the root client resource layout in the root client's configuration file is read to obtain the number of non-root clients configured for security checks. Using this method, it is easier to determine later whether a non-root client to be started needs security checks. For example, the method can also add the following step: obtaining the number of the current non-root client, and determining whether the currently verified non-root client belongs to the non-root client configured for security checks based on the number and the number of non-root clients configured for security checks. Typically, the non-root clients that need to be verified start from the first non-root client and are consecutive. Therefore, the number of non-root clients that need to be verified determined in the above steps, combined with the number of the currently verified non-root client, can be used to determine whether it is a non-root client that needs verification.

[0039] Step 120: When the currently verified non-root client starts up, it uses the core data structure of its own non-root client resource layout to obtain the corresponding first-level index. The first-level index is used to locate the verification address in the Jailhouse virtualization trusted structure in the root client's configuration file for the non-root client.

[0040] The currently verified non-root client can be any non-root client that requires verification. Upon startup, it utilizes the core data structure of its non-root client resource layout to find newly added parameters and a first-level index. This first-level index can be set in the Jailhouse virtualization trusted structure within the configuration file of the root client, specifically targeting the verification address within the non-root client. In this embodiment, an additional Jailhouse virtualization trusted structure can be added to the root client. This structure records the security configuration of the non-root client, i.e., the security configuration related to the image and configuration file. The first-level index can directly locate the verification address of the currently verified non-root client within the Jailhouse virtualization trusted structure.

[0041] Step 130: Using the first-level index and the Jailhouse virtualization trusted structure, look up the first and second authentication value indices of the non-root client in the configuration file of the root client.

[0042] The newly added Jailhouse virtualization trusted structure can be used to configure the root client by passing the first and second authentication value indices as parameters and writing them into the root client's configuration file. Using the first-level index, the first and second authentication value indices of the currently authenticated non-root client can be directly obtained.

[0043] Step 140: Read the first verification value and the second verification value from the TPM NVRAM according to the first verification value index and the second verification value index.

[0044] The Trusted Platform Module (TPM) is a dedicated security processor integrated onto the motherboard. It contains hardware resources such as a random number generator, cryptographic operation unit, non-volatile RAM (NVRAM), and platform configuration registers. It can perform cryptographic operations and securely store passwords, keys, and other information.

[0045] NVRAM is a non-volatile memory within the TPM (Tencent Mobile Platform). It allows for writing information, and this information is retained even during power outages. NVRAM is used to store data defined by the TPM specification, such as passwords and keys, and can also store user-defined data. Information stored in NVRAM can have its read / write attributes individually configured to prevent accidental or malicious damage. An NVRAM index is the address used to access the non-volatile memory space within the TPM. Users can configure these non-volatile memory spaces for storing relevant data. Once configured, each space has an index and a set of attributes, which users can set. NVRAM indexes have both an authorization value and an authorization policy. The owner of an NVRAM index can change the authorization value but cannot change the authorization policy; once created, the authorization policy cannot be modified.

[0046] In this embodiment, the first and second verification values ​​are crucial for verifying the integrity of the non-root client image and configuration files, ensuring they have not been tampered with or corrupted. Therefore, the first and second verification values ​​need to be stored in a secure and unmodifiable area. Thus, they can be stored in the TPM NVRAM.

[0047] The first verification value index and the second verification value index can point to the addresses of the first verification value and the second verification value, respectively. The first verification value and the second verification value can be read from the addresses.

[0048] Step 150: Verify the image and configuration file of the currently verified non-root client using the first verification value and the second verification value. If the verification is successful, run the currently verified non-root client normally.

[0049] For example, it may include: calculating the image verification value of the image of the currently verified non-root client; calculating the configuration file verification value of the configuration file of the currently verified non-root client; determining whether the first verification value is consistent with the image verification value, and determining whether the second verification value is consistent with the configuration file verification value.

[0050] A verification value is generated using the image file of the currently verified non-root client, and a verification value is generated using the configuration file of the currently verified non-root client. The image verification value is matched with a first verification value, and the configuration file verification value is matched with a second verification value. If both match, it can be determined that the non-root client image and configuration file have not been tampered with or replaced, and the currently verified non-root client can run normally. Otherwise, the startup process exits.

[0051] This embodiment adds attributes to the structures of the configuration files for both the root client and non-root clients, and adds a structure for the verification value index to the root client configuration file. When a non-root client starts up, it can use its own configuration file to determine a first-level index, then look up the structure for the verification value index in the root client configuration file based on that first-level index, and then look up the index of the verification value based on that structure. Finally, it determines the verification value stored in the TPM NVRAM based on the verification value index. This allows the verification value stored in the TPM NVRAM to be retrieved by constructing an access policy that conforms to accessing specific locations in the TPM NVRAM through the configuration file, even before the non-root client has started up. This satisfies the data security requirements of the TPM NVRAM, thereby effectively verifying the security of non-root clients. It prevents the non-root client image from being replaced or tampered with, and from running malicious programs. This improves the security of the Jailhouse multi-core system.

[0052] In a preferred embodiment of this example, before reading the first verification value and the second verification value from the TPM NVRAM according to the first verification value index and the second verification value index, the method may further include the following step: initializing TPM access and obtaining the TPM access authorization policy. Accordingly, the reading of the first verification value and the second verification value from the TPM NVRAM according to the first verification value index and the second verification value index is specifically optimized as follows: when the TPM access authorization policy is satisfied, the first verification value and the second verification value are read from the TPM NVRAM according to the first verification value index and the second verification value index.

[0053] The access authorization policy can be based on necessary conditions for a specific storage location of the TPM NVRAM. For example, obtaining the TPM access authorization policy may include: obtaining data from a pre-defined register of the TPM access authorization policy, whereby the data is calculated based on environmental parameters that meet the access requirements. These environmental parameters may include parameters representing the normal state of the memory, CPU, and other units of the configuration file. Using this method, it can be determined that the current state is secure and access to the TPM NVRAM is possible.

[0054] Example 2

[0055] Figure 2 This is a flowchart illustrating the secure loading method for virtual machines provided in Embodiment 2 of the present invention. Based on the above embodiments, this embodiment further describes the present invention for specific application scenarios.

[0056] See Figure 2 The virtual machine secure loading method includes:

[0057] Step 210: When the root client starts, the jailhouse_cell_desc data structure is read using the root client's configuration file, and the newly added num_tpms parameter variable is read from the jailhouse_cell_desc data structure.

[0058] In this embodiment, an armv8 hardware platform is used, the motherboard has a security chip supporting the TPM2.0 standard, and the Linux kernel version is 4.19. Jailhouse is used to implement partition virtualization, isolating the host into two partitions: a root client and a non-root client. The root client runs Linux, and the non-root client runs FreeRTOS. The above partition virtualization is just an example. In actual use, the `__u32 num_tpms` parameter can be set in the `jailhouse_cell_desc` data structure. Since there is only one non-root client requiring authentication, it can be set to 1.

[0059] Step 220: When the currently verified non-root client starts up, use its own jailhouse_cell_desc data structure to obtain the newly added tpm_idx variable.

[0060] The FreeRTOS guest configuration can be placed in the first jailhouse_tpm configuration within the root guest configuration, so the tpm_idx in the non-root guest configuration file should be configured to 0. The tpm_idx can be obtained using the jailhouse_cell_desc data structure. The corresponding tpm_idx variable can be retrieved when the verified non-root guest starts up, facilitating the lookup.

[0061] Step 230: Using tpm_idx, the struct jailhouse_tpm structure is used to search for the tpm_nv and tpmcell_nv of the non-root client in the configuration file of the root client.

[0062] The `struct jailhouse_tpm` structure records the TPM NVRAM indexes corresponding to non-root clients. The `tpm_idx` method is used to find the two parameter variables `tpm_nv` and `tpmcell_nv` corresponding to the non-root client. Here, `tpm_nv` and `tpmcell_nv` represent the TPM NVRAM indexes corresponding to the non-root client's image hash value and the non-root client's configuration file hash value, respectively.

[0063] Step 240: Read the first verification value and the second verification value from the TPM NVRAM based on tpm_nv and tpmcell_nv.

[0064] The corresponding addresses in the TPM NVRAM are determined using tpm_nv and tpmcell_nv, respectively. From these addresses, the hash values ​​of the non-root client image and configuration file, which are functional and pose no security risks, are read. Optionally, values ​​calculated using other similar fingerprinting algorithms can also be used as verification values.

[0065] Step 250: Use the first verification value and the second verification value to verify the image and configuration file of the currently verified non-root client. If the verification is successful, run the currently verified non-root client normally.

[0066] The system can calculate the hash values ​​of the image and configuration file of the currently verified non-root client, and compare these hash values ​​with a first verification value and a second verification value, respectively. If they match, the currently verified non-root client runs normally; otherwise, it stops running. This method allows the system to obtain the image and configuration file currently used by the non-root client to be verified, preventing them from being modified to normal images and configuration files during the verification process. Furthermore, it allows for effective verification even before the non-root client has completed its normal startup. Compared to existing technologies that use application-based verification, this method allows verification before the non-root client can cause harm during normal startup, effectively avoiding security risks to multi-core systems.

[0067] This embodiment illustrates specific structures and related parameters through examples, providing corresponding structures for root and non-root hosts based on Jailhouse. This facilitates the writing of specific index content during configuration, providing a secure and trusted access environment for secure access to specific addresses in TPM NVRAM. Verification can be performed before harm occurs during the normal startup of non-root clients, effectively avoiding potential security risks to multi-core systems.

[0068] Example 3

[0069] Figure 3 This is a flowchart illustrating the secure virtual machine loading method provided in Embodiment 3 of the present invention. This embodiment is based on the above embodiment and optimized. The method may further include the following steps: A new Jailhouse virtualization trusted structure definition is added to the root client configuration file. The Jailhouse virtualization trusted structure definition includes: a first verification value index and a second verification value index corresponding to the non-root client; the image verification value of the non-root client is calculated as the first verification value, and the configuration file verification value of the non-root client is calculated as the second verification value; the first verification value and the second verification value are written to specified locations in TPMNVRAM respectively; the first verification value index and the second verification value index are associated with the specified locations in TPMNVRAM. The Jailhouse virtualization trusted structure is added to the root client configuration file, and a member variable representing the number of non-root clients is added to the Jailhouse virtualization trusted structure. A first parameter is added to the core data structure of the root client resource layout to record the number of non-root clients that are indexed; a first-level index is added to the core data structure of the non-root client resource layout to record the corresponding first-level index of the non-root client in the Jailhouse virtualization trusted structure in the root client configuration file. When the root client starts up and configures, the first and second verification value indices are passed to the root client configuration file using the root client Jailhouse virtualization trusted structure, and the number of non-root clients configured for security checks is passed to the root client configuration file as a parameter; when a non-root client starts up and configures, the core data structure of the first-level index, which is laid out using its own non-root client resources, is passed to the non-root client configuration file.

[0070] See Figure 3 The virtual machine secure loading method includes:

[0071] Step 310: Add a Jailhouse virtualization trusted structure definition to the root client configuration file. The Jailhouse virtualization trusted structure definition includes a first verification value index and a second verification value index corresponding to the non-root clients. Add the Jailhouse virtualization trusted structure to the root client configuration file and add a member variable for the number of non-root clients to the Jailhouse virtualization trusted structure.

[0072] For example, the Jailhouse virtualization trusted architecture can be exemplified as follows:

[0073] struct jailhouse_tpm {

[0074] __u32 tpm_nv;

[0075] __u32 tpmcell_nv;

[0076] };

[0077] tpm_nv: Represents the TPM NVRAM index corresponding to the image hash value of the none root client;

[0078] tpmcell_nv: Represents the TPM NVRAM index corresponding to the hash value of the none root client configuration file.

[0079] The jailhouse_tpm data structure is added to the root client configuration file to store the TPM NVRAM index corresponding to the none root client. The configuration file is as follows:

[0080] struct {

[0081] struct jailhouse_system header; ...

[0082] struct jailhouse_tpm tpms[n]; ...

[0083] };

[0084] The struct jailhouse_tpm tpms[n] indicates that a maximum of n none root clients can be configured to associate with tpm.

[0085] Using the above method, the corresponding values ​​can be passed into the structure and written to the root client's configuration file in a manner similar to initialization. Alternatively, a manual writing method can be used, where the first and second verification value indices are written to the root client's configuration file based on the root client's Jailhouse virtualization trusted structure, and the number of non-root clients configured for security checks is also written to the root client's configuration file. When generating non-root client configurations, the core data structure of the first-level index, which utilizes its own non-root client resources, is written to the non-root client's configuration file.

[0086] Step 320: In the core data structure of the root client resource layout, add a first parameter to record the number of non-root clients that are indexed; in the core data structure of the non-root client resource layout, add a first-level index to record the corresponding Jailhouse virtualization trusted structure of the non-root clients in the root client configuration file.

[0087] For example, the core data structure of the modified resource layout can be:

[0088] struct jailhouse_cell_desc {

[0089] char signature[6]; ...

[0090] __u32 tpm_idx;

[0091] __u32 num_tpms; ...

[0092] }

[0093] The `num_tpms` variable is used in the root client configuration file to record the number of `jailhouse_tpm` configurations in the root client configuration file. The `tpm_idx` variable is used in the non-root client configuration files to record the index of the non-root client TPM-related configurations stored in the `jailhouse_tpm` of the root client configuration file. By modifying the core data structure of the resource layout, it is possible to achieve configuration file integrity and the possibility of modification without modifying the configuration files.

[0094] Step 330: Calculate the image verification value of the non-root client as the first verification value, and calculate the configuration file verification value of the non-root client as the second verification value; write the first verification value and the second verification value into the specified locations in the TPM NVRAM respectively; associate the index of the first verification value and the index of the second verification value with the specified locations in the TPM NVRAM.

[0095] The image and configuration file to be loaded by the non-root client, which have already passed security checks, need to be calculated. In this embodiment, the hash values ​​of the non-root client image and configuration file can be calculated first using the SHA256 hash algorithm, and the first and second verification values ​​can be written to the specified locations in the TPM NVRAM. Optionally, before writing to the TPM NVRAM, TPM access is initialized and a TPM access authorization policy is created. It is determined that the current environment meets the security conditions for writing to the TPM NVRAM. Under the premise of satisfying the access policy, the first and second verification values ​​are written to the specified locations in the TPM NVRAM, respectively.

[0096] For example, the first free NVRAM index can be found in the TPM, with the index value represented by nv_idx1, and the NVRAM index can be defined according to the authorization policy. This defines the environmental conditions for accessing the NVRAM index, thereby improving the security of accessing the TPM NVRAM and preventing tampering.

[0097] Write the NVRAM index value nv_idx1 to the tpm_idx of the root guest configuration file, for example: the tpm_nv of jailhouse_tpm corresponding to tpm_idx of tpm_idx in the FreeRTOS guest configuration file;

[0098] Find the second free NVRAM index, denoted by nv_idx2, and define the NVRAM index according to the authorization policy; write the hash value of the non-root client configuration file to nv_idx2 in the NVRAM.

[0099] Write the NVRAM index value nv_idx2 to the tpm_idx of the root guest configuration file, for example, to the tpmcell_nv of jailhouse_tpm corresponding to tpm_idx being 0 in the FreeRTOS guest configuration file.

[0100] Step 340: When the root client starts up and configures, the first verification value index and the second verification value index are passed into the root client configuration file using the root client Jailhouse virtualization trusted structure, and the number of non-root clients configured for security detection is passed into the root client configuration file as a parameter; when the non-root client starts up and configures, the core data structure of the first-level index using its own non-root client resource layout is passed into the non-root client configuration file.

[0101] Step 350: Use the root client's configuration file to read the core data structure of the root client's resource layout and obtain the number of non-root clients configured for security checks.

[0102] Step 360: When the currently verified non-root client starts up, it uses the core data structure of its own non-root client resource layout to obtain the corresponding first-level index. The first-level index is used to locate the verification address for the non-root client in the Jailhouse virtualization trusted structure in the root client's configuration file.

[0103] Step 370: Using the first-level index and the Jailhouse virtualization trusted structure, look up the first and second authentication value indices of the non-root client in the configuration file of the root client.

[0104] Step 380: Use the first verification value and the second verification value to verify the image and configuration file of the currently verified non-root client. If the verification is successful, run the currently verified non-root client normally.

[0105] This embodiment adds the following steps: A new Jailhouse virtualization trusted structure definition is added to the root client configuration file. This Jailhouse virtualization trusted structure definition includes a first verification value index and a second verification value index corresponding to non-root clients. The image verification value of the non-root client is calculated as the first verification value, and the configuration file verification value of the non-root client is calculated as the second verification value. The first verification value and the second verification value are written to specified locations in the TPMNVRAM, respectively. The first verification value index and the second verification value index are associated with the specified locations in the TPMNVRAM. The Jailhouse virtualization trusted structure is added to the root client configuration file, and a member variable representing the number of non-root clients is added to the Jailhouse virtualization trusted structure. A first parameter is added to the core data structure of the root client resource layout to record the number of non-root clients that have been indexed. A first-level index is added to the core data structure of the non-root client resource layout to record the corresponding first-level index of the non-root client in the Jailhouse virtualization trusted structure of the root client configuration file. During root client startup configuration, the first and second authentication value indices are passed to the root client configuration file using the root client's Jailhouse virtualization trusted structure, along with the number of non-root clients configured for security checks. During non-root client startup configuration, the core data structure of the first-level index, based on its own non-root client resource layout, is passed to the non-root client configuration file. Using this method, the foundation for non-root client images and configuration files can be established without modifying the non-root client configuration files, thus improving the security of the Jailhouse multi-core system.

[0106] Example 4

[0107] Figure 4This is a schematic diagram of the structure of the virtual machine secure loading device provided in Embodiment 4 of the present invention. See also... Figure 4 The virtual machine secure loading device includes:

[0108] The reading module 410 is used to read the core data structure of the root client resource layout using the root client's configuration file when the root client starts up, and to obtain the number of non-root clients configured for security detection.

[0109] The acquisition module 420 is used to obtain the corresponding first-level index by utilizing the core data structure of its own non-root client resource layout when the currently verified non-root client starts up. The first-level index is used to locate the verification address in the Jailhouse virtualization trusted structure in the configuration file of the root client for the non-root client.

[0110] The lookup module 430 is used to look up the first and second authentication value indices of the non-root client in the configuration file of the root client using the first-level index and the Jailhouse virtualization trusted structure.

[0111] The verification value reading module 440 is used to read the first verification value and the second verification value from the TPMNVRAM according to the first verification value index and the second verification value index;

[0112] The verification module 450 is used to verify the image and configuration file of the currently verified non-root client using the first verification value and the second verification value.

[0113] The running module 460 is used to run the currently verified non-root client normally when the verification is successful.

[0114] The virtual machine security loading device provided in this embodiment obtains the number of non-root clients configured for security detection by reading the core data structure of the root client's resource layout from the root client's configuration file when the root client starts. When a currently verified non-root client starts, it obtains the corresponding first-level index using its own non-root client resource layout core data structure. This first-level index is used to locate the verification address for the non-root client in the Jailhouse virtualization trusted structure within the root client's configuration file. The device then uses the first-level index and the Jailhouse virtualization trusted structure to search for the first and second verification value indices of the non-root client in the root client's configuration file. Based on these indices, it reads the first and second verification values ​​from the TPM NVRAM. The device then uses these values ​​to verify the image and configuration file of the currently verified non-root client. If the verification passes, the device runs normally. By writing the hash values ​​of the non-root client image and configuration file into the TPM NVRAM and verifying them by reading the TPM NVRAM during non-root client loading, the device achieves data integrity and security verification for the non-root client image and configuration file. Prevents non-root client images from being replaced or tampered with, and from running malicious programs. Improves the security of Jailhouse multi-core systems.

[0115] Based on the above embodiments, the verification module includes:

[0116] The first calculation unit is used to calculate the image verification value of the image of the currently verified non-root client.

[0117] The second calculation unit is used to calculate the configuration file verification value of the configuration file of the currently verified non-root client;

[0118] The judgment unit is used to determine whether the first verification value is consistent with the image verification value, and to determine whether the second verification value is consistent with the configuration file verification value.

[0119] Based on the above embodiments, the device further includes:

[0120] The security detection and judgment module is used to obtain the number of the current non-root client, and determine whether the currently verified non-root client belongs to the non-root client configured for security detection based on the number and the number of non-root clients configured for security detection.

[0121] Based on the above embodiments, the device further includes:

[0122] A new module is added to add a Jailhouse virtualization trusted structure definition in the root client configuration file. The Jailhouse virtualization trusted structure definition includes a first verification value index and a second verification value index corresponding to the non-root client.

[0123] Based on the above embodiments, the device further includes:

[0124] The first addition unit is used to add a first parameter to the core data structure of the root client resource layout to record the number of non-root clients for indexing.

[0125] The second addition unit is used to add a first-level index to the core data structure of the non-root client resource layout to record the corresponding Jailhouse virtualization trusted structure of the non-root client in the root client configuration file.

[0126] Based on the above embodiments, the device further includes:

[0127] The `add` module is used to add the Jailhouse virtualization trusted structure to the root client configuration file and add a member variable to the Jailhouse virtualization trusted structure to indicate the number of non-root clients.

[0128] Based on the above embodiments, the device further includes:

[0129] The first input module is used to input the first verification value index and the second verification value index into the root client configuration file using the root client Jailhouse virtualization trusted structure when the root client starts configuration, and input the number of non-root clients configured for security detection as a parameter into the root client configuration file.

[0130] The second input module is used to input the core data structure of the first-level index, which utilizes its own non-root client resources, into the non-root client configuration file when the non-root client starts up and configures.

[0131] The virtual machine secure loading device provided in this embodiment of the invention can execute the virtual machine secure loading method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0132] Example 5

[0133] Figure 5 This is a schematic diagram of the structure of a device provided in Embodiment 5 of the present invention. Figure 5 A block diagram of an exemplary device 12 suitable for implementing embodiments of the present invention is shown. Figure 5 The device 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0134] like Figure 5 As shown, device 12 is represented as a general-purpose computing device. The components of device 12 may include, but are not limited to: one or more processors or processing units 16, memory 28, and bus 18 connecting different system components (including memory 28 and processing unit 16).

[0135] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0136] Device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by device 12, including volatile and non-volatile media, removable and non-removable media.

[0137] Memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0138] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0139] Device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with device 12, and / or with any device that enables device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of device 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0140] Processing unit 16 executes various functional applications and data processing by running programs stored in memory 28, such as implementing the virtual machine secure loading method provided in this embodiment of the invention.

[0141] Example 6

[0142] Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the virtual machine secure loading methods provided in the above embodiments.

[0143] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0144] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0145] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0146] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0147] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for securely loading a virtual machine, characterized in that, include: When the root client starts, it uses the root client's configuration file to read the core data structure of the root client's resource layout and obtain the number of non-root clients configured for security checks. When the currently verified non-root client starts up, it uses the core data structure of its own non-root client resource layout to obtain the corresponding first-level index. The first-level index is used to locate the verification address in the Jailhouse virtualization trusted structure in the root client's configuration file for the non-root client. Using the first-level index and the Jailhouse virtualization trusted structure, the first and second authentication value indices of the non-root client are searched in the configuration file of the root client; The first verification value and the second verification value are read from the TPM NVRAM according to the first verification value index and the second verification value index; The image and configuration file of the currently verified non-root client are verified using the first verification value and the second verification value; If the verification passes, the non-root client being verified will run normally.

2. The method according to claim 1, characterized in that, The step of verifying the image and configuration file of the currently verified non-root client using the first verification value and the second verification value includes: Calculate the image verification value of the currently verified non-root client's image; Calculate the configuration file verification value for the currently verified non-root client; Determine whether the first verification value is consistent with the image verification value, and determine whether the second verification value is consistent with the configuration file verification value.

3. The method according to claim 1, characterized in that, After obtaining the number of non-root clients configured for security detection, the method further includes: Obtain the ID of the current non-root client, and determine whether the currently verified non-root client belongs to the non-root client configured for security detection based on the ID and the number of non-root clients configured for security detection.

4. The method according to claim 1, characterized in that, The method further includes: Add a Jailhouse virtualization trusted structure definition to the root client configuration file. The Jailhouse virtualization trusted structure definition includes: the first verification value index and the second verification value index corresponding to the non-root client.

5. The method according to claim 4, characterized in that, The method further includes: Calculate the image verification value of the non-root client as the first verification value, and calculate the configuration file verification value of the non-root client as the second verification value; Write the first verification value and the second verification value into the specified locations in TPMNVRAM respectively; Associate the first verification value index and the second verification value index with the specified positions in the TPMNVRAM.

6. The method according to claim 4, characterized in that, The method further includes: In the core data structure of the root client resource layout, add a first parameter to record the number of non-root clients that are indexed. In the core data structure of the non-root client resource layout, a first-level index is added to record the corresponding Jailhouse virtualization trusted structure of the non-root client in the root client configuration file.

7. The method according to claim 6, characterized in that, The method further includes: Add the Jailhouse virtualization trusted structure to the root client configuration file, and add a member variable to the Jailhouse virtualization trusted structure to indicate the number of non-root clients.

8. The method according to claim 7, characterized in that, The method further includes: When the root client starts configuring, the first and second verification value indices are passed to the root client configuration file using the root client Jailhouse virtualization trusted structure, and the number of non-root clients configured for security detection is passed to the root client configuration file as a parameter. When configuring a non-root client, the core data structure of the first-level index, which utilizes the resources of the non-root client itself, is passed into the non-root client configuration file.

9. A virtual machine secure loading device, characterized in that, include: The read module is used to read the core data structure of the root client's resource layout using the root client's configuration file when the root client starts up, and to obtain the number of non-root clients configured for security checks. The acquisition module is used to obtain the corresponding first-level index by utilizing the core data structure of its own non-root client resource layout when the currently verified non-root client starts up. The first-level index is used to locate the verification address for the non-root client in the Jailhouse virtualization trusted structure in the root client's configuration file. The lookup module is used to look up the first and second authentication value indices of the non-root client in the configuration file of the root client using the first-level index and the Jailhouse virtualization trusted structure. The verification value reading module is used to read the first verification value and the second verification value from the TPM NVRAM according to the first verification value index and the second verification value index; The verification module is used to verify the image and configuration file of the currently verified non-root client using the first verification value and the second verification value. The runtime module is used to run the currently validated non-root client normally when the validation passes.

10. A device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the virtual machine secure loading method as described in any one of claims 1-8.

11. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to perform the virtual machine secure loading method as described in any one of claims 1-8.

Images