JP6304837B2 - Authenticated launch of virtual machines and nested virtual machine managers - Google Patents

Description

  A “launch control” or launch control policy (LCP) is part of a comprehensive endpoint protection solution. Conventional anti-virus scanning uses a “blacklisting” technique that aims to identify known “bad” software. When the scan engine searches for platform resources, the attack signature serves as a guide for the scan engine. Infected resources are flagged for repair. “Whitelisting” involves creating a list of known “good” software. This list is supplied to the scan engine, which flags resources that are not on the list for repair. Blacklisting and whitelisting work together to sort all the resources of the system. Launch Control integrates the whitelist scan engine into the system launch procedure to prevent malware from getting an opportunity to run on the system. For example, the whitelist may include reference measurements of code and data (eg, hashes) that are used to boot or launch an execution environment (eg, a dynamically launched environment). Thus, the launch control can be used to ensure that a “trusted boot” takes place.

  Trusted boot usage may affect all stages of the boot flow and may be based on trusted hardware, also known as “roots-of-trust”. Trusted Execution Technology (TXT) is an example of a launch control and route of trust technology that can be used to implement trusted boot usage for virtual environments. With the help of the hardware root of trust, trusted boot use eliminates or reduces the likelihood that malware will disguise legitimate hardware for the upper layers. TXT implements a root of trust for measurement (RTM) for dynamic measurements to ensure that only the trusted environment is launched using a launch control policy. In other words, TXT may be the starting point in a series of integrity checks performed for various execution environments within the platform. Thus, TXT may provide a secure starting point in microcode. For example, various launch controls, such as the TXT launch control, ensure that a virtual machine manager (VMM) launcher is trustworthy.

  The VMM may include a host program that allows the computer to support multiple execution environments. For example, a VMM provides a means through emulation that divides a single physical machine (eg, a server) and allows multiple operating systems to run securely on the same CPU and increase CPU utilization. Good. The VMM can manage the VM. A VM may include a software implementation of a machine (ie, a computer) that executes instructions like a physical machine.

With respect to TXT launch control again, such launch control may include a VMM infrastructure (eg, virtual machine (VM), nested VMM, nested VM) and operating system (OS) that is subsequently launched. : Operating system) environment) is not necessarily reliable. Thus, the launch control can actually be used to launch a single VMM. However, when the VMM is executed, the TXT model specific register (MSR) is set so that TXT is not invoked while the VMM using the VMX root (VMX-root) is active. Thus, when a nested VMM is launched, TXT is not available (eg, the GETSEC (SENTER) command is invalid) and the nested VMM is not securely launched. At this time, VMs and nested VMMs are loaded without applying the launch control policy, thereby creating a potential security breach opportunity.
Features and advantages of embodiments of the present invention will become apparent from the appended claims, the following detailed description of one or more exemplary embodiments, and the corresponding drawings.

1 includes a schematic flowchart of an embodiment of the present invention. 1 includes a block diagram illustrating the organization of various aspects of embodiments of the present invention. FIG. Includes systems used in embodiments of the present invention.

  In the following description, numerous specific details are set forth, but embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description. “Embodiments”, “various embodiments” and the like indicate that the embodiments so described may include particular features, structures or characteristics, but not all embodiments may include particular features, structures. Or it does not include characteristics. Some embodiments may have some, all, or none of the features described for other embodiments. “First”, “second”, “third”, etc. describe common objects and indicate that different instances of similar objects are referenced. Such an adjective does not mean that the object so described must be in a predetermined sequence in time, space, order, or any other manner. “Connected” may indicate that the elements are in direct physical or electrical contact with each other, and “coupled” means that the elements cooperate or interact with each other, but the elements are physically Or it may indicate that it may or may not be in direct electrical contact. Also, similar numerals or the same numerals may be used to indicate the same or similar parts in different figures, but doing so does not restrict all figures containing similar numerals or the same number to a single embodiment. It does not mean that the same embodiment is constituted.

  Embodiments of the present invention provide authenticated lunches of VMs and / or nested VMMs. Embodiments may do so using an interface that invokes a VMM protected launch control mechanism for VMs and nested VMMs. The interface may be generic as an architecture. Some embodiments may use a TXT launch control policy that has been extended to include VMs and VMMs.

  FIG. 1 includes a schematic flowchart of an embodiment of the present invention. FIG. 2 includes a block diagram illustrating the organization of various aspects of embodiments of the present invention. Although FIGS. 1 and 2 are discussed below in relation to each other, the embodiments of each figure are not necessarily limited to functioning together.

  FIG. 2 includes an organization chart 200. Briefly, the organization chart 200 includes a verification that includes an image 201, a launch control policy 211 having a representative whitelist corresponding to the image 201, and a code that authenticates the candidate code image 201 against the measurements in the whitelist 211. A collection of code modules (e.g., launch control module (LCPM) 221). The organization chart 200 is described more fully below. In an embodiment, LCPM is a dynamic modular code object that executes with root VMM privileges. A platform configuration register (PCR) 231 stores image measurements.

  First, the root VMM (VMM0) 155 is booted. This boot may be a secure boot implemented by any number of secure boot mechanisms. One such mechanism taken up above includes the TXT launch control. Information about TXT launch control can be found at http: // software-intel-com / en-us / articles / intel-trusted-execution-technology-a-primer /, http: // download-intel-com / technology / security / It is minimally available at downloads / 315168-pdf as well as other publicly available locations.

  Launching the root VMM (VMM0) securely may involve several actions. TXT 226 may operate as a launch control policy to ensure that a particular image, eg, SINIT ACM 206 is authentic. SINIT ACM relates to the authenticated code module used in the secure boot process. SINIT ACM 206 measurements are stored in PCR 17 (236). The PCR is a trusted platform module (TPM) register that contains a cryptographic hash of security-related information (for example, a code executed by a trusted execution environment such as a VMM and a loader code hash used to launch it). It is.

  During a secure launch of VMMO, LCP0 215 may be compared to the root VMMO 205 image using SINIT ACM at block 225. LCP0 215 and SINIT ACM 225 may also be used to authenticate LCPM1, LCPM2, and LCPM3 205 images. Some of these images may be used in later stages (eg, nested VMM boots) discussed below. These measurements are stored in PCR 18 for VMM0 and in PCRs 19, 20, and 21 for LCPM1, LCPM2, and LCPM3, respectively.

  With a slight diversion, the exact PCR used for storage can be configured and may vary in other embodiments. For example, the PCR allocation guidelines may be outlined in the specification. Such specifications include the Trusted Computing Group (TCG) PC client specification and the TPM specification. These specifications reserve PCRs 17, 18, 19, 20, and 21 for use by dynamic root of trust (eg, TXT). PCR 17 may be used to measure ACM by SENTER. ACM may use PCR 18 to measure the VMM launcher. The VMM launcher may use the PCR 18 to measure the VMM and optionally use the PCR 19. The VMM may virtualize the TPM and therefore use other PCRs to measure the VM (and its associated LCPM). The VMM may also be available for PCRs 20 and 21. Furthermore, multiple LCPM measurements may be included in the same PCR. Thus, the use of PCR is configurable and may change with changes in embodiments.

  Returning to FIG. 1, a bootstrapped loader, such as VM 0 105, is virtual booted by block 110. Block 115 begins the process of booting an entity, such as virtual machine VM1 104 (in element 204 of FIG. 2). (The “entity” may be a nested VMM, but in this example VM1 is used for illustration purposes.) When VM1 104 is launched, the bootstrap loader VM0 105 is instructed, eg, VM1 104. Call a VMFUNC interface instruction that specifies the leaf leading to LCPM1 124 (224 in FIG. 2). The VMFUNC interface may prevent interrupts or set the VM control bit, so LCPM1 224 is allowed to run without any interruption of the measurement process. This interface may also quiesce other processors on the system so that measurements can be made without interference from other processors. Further, VMFUNC may approve that the microcode is already considered a safe place to perform integrity checks and integrity checking controls, eg, based on the use of TXT. VMFUNC is discussed further below.

  Accordingly, execution management is passed by block 130 to LCPM1 124 (element 224 of FIG. 2). In the embodiment, LCPM1 operates as a VM executing on VM1. LCPM1 124 locates VM1 104 in memory, performs the integrity measurement intended for LCPM1 based on LCP1 114 (element 214 in FIG. 2), and the calculated measurement is the policy of LCP1. Verify that it is accepted by one. The LCP may include a whitelist, which describes the expected software image, possibly reserved on the trusted server. Specifically, in the embodiment, the LCPM 1 reads the LCP 1 into a memory, for example, a protection memory arranged in an extended page table (EPT). EPT is discussed in more detail below with respect to the VMFUNC interface.

  At block 140, the measurement of VM1 is extended to PCR (eg, PCR8) 234. PCR 234 is included in TPM 145 or other such hardware certification module. A TPM is a security coprocessor that implements various security functions associated with secure storage and secure reporting. For more information on cryptographic processors such as TPM, see “Trusted Platform on Notebook PCs-W ebook PCs -While PCs -Written Security Modules (TPMs) using the Trusted Platform Module (TPM) for Notebook PCs at least by Sundeep Bajikar. ")", Http: // www-intel-com / design / mobile / platform / downloads / Trusted_Platform_Module_White_Paper-pdf. At block 160, the PCR log is updated. Embodiments are not limited to operations using VMFUNC, TPM, etc., but such elements are only used for example purposes. Next, VM1 is scheduled for execution by root VMM 155 (included in element 205 of FIG. 2). In block 165, VMFUNC (exit) is executed.

  The above process embodiment (with respect to FIGS. 1 and 2) is applicable to nested VMMs instead of VM1 used for illustration purposes. In line with this, block 204 of FIG. 2 includes both a VM (eg, VM1) and a nested VMM. In other words, FIG. 1 describes a secure boot of VM1, but the same process could be used to securely boot a nested VMM.

  As shown in FIG. 2, an additional virtualization layer may be secured. For example, nested VM 203 may be measured by LCPM2 223 and compared to measurements included in LCP2 213. Measurements may be stored by PCR 233. In addition, drivers, libraries and executable code 202 may be measured by LCPM3 221 and compared to measurements included in LCP3 212. Measurements may be stored by PCR 232.

  As a more specific example for a nested VM, bootstrapped loader VM0 105 is virtually booted by block 110. Block 115 begins the process of booting the nested VM2 203. When VM2 203 is launched, the bootstrap loader VM0 105 calls an instruction, eg, a VMFUNC interface instruction that specifies a leaf leading to LCPM2 223 that launches VM2 203. Through block 130, execution management is passed to LCPM2 223. LCPM2 223 locates VM2 203 in memory, performs an integrity measurement based on LCP2 213 intended for LCPM2, and confirms that the calculated measurement is accepted by one of the policies in LCP2. Validate. In block 140, the measurement of VM2 is extended to PCR 233 included in the TPM. At block 160, the PCR log is updated. Next, at block 155, execution of VM2 is scheduled by the root VMM 155. In block 165, VMFUNC (exit) is executed.

  The process embodiments described immediately above (with respect to FIGS. 1 and 2) are also applicable to nested VMMs that are further nested within another entity.

  Thus, block 110 leads to a root VMM (105) that launches LCPM (225). LCPM is for evaluating LCP with images for VMs loaded into protected memory. Similarly, an LCPM for a nested VMM (which is not specifically shown in FIG. 1) may also be loaded. The root VMM LCP is used to verify the integrity of the LCPM. Further, the VM or nested VMM is launched more securely than when the VM or nested VMM is launched from the root VMM, even if it is a securely booted root VMM. Instead, the root VMM is not directly dependent (ie, bypassed), but instead depends on the TXT hardware usage sequence (or other hardware certification module usage method) to boot the VM or nested VMM. The In one embodiment, launch control mechanisms, tools and infrastructure that are normally limited to work with the root VMM are extended to work with VMs and VMMs. For example, launch control is then extended beyond TXT and similar security techniques. Embodiments continue the whitelist checking process kicked off by, for example, TXT launch control and / or BIOS trusted boot mechanism to nested VMM and VM environments. Based on the trusted system boot, the trusted root VMM boot, and the nested trusted VMM and / or VM boot, the embodiments provide a trusted broker service with an unbroken chain of trust that goes back to the root of trust. It's okay. This chain of trust may be constructed based on the contents of the PCR log, for example.

  With respect to the VMFUNC instruction, normally VMs and nested VMMs are loaded without applying the launch control policy. Furthermore, VMM vendors do not rely on the usual architectural interface for launch control. However, in various embodiments of the present invention, the root VMM may use a VMFUNC call (or its functional equivalent) that invokes the launch control policy module, as described above. LCPM understands how to parse and validate whitelists included in LCP policies. The LCP policy may be specific to the type of image being loaded (eg, VM or nested VMM). LCPM is performed with the root VMM properly protected. VMFUNC calls ensure that VMs and nested VMMs are invoked in a vendor-independent manner, so that LCP authors can cover different vendor implementations of VMM and VMs, or different vendor implementations LCPs that function reliably over time can be constructed. Thus, the VMM vendor does not have to maintain a significantly different product / device stock keeping unit (SKU) for a VMM that functions as either a root VMM or a nested VMM.

  Furthermore, with respect to VMFUNC, VMFUNC is an architectural interface that uses EPT memory protection. EPT is a virtualization technology for a memory management unit (MMU). When this feature is active, the normal IA-32 page table (referenced by control register CR3) is translated from a linear address to a guest physical address. A separate set of page tables (ie, EPT tables) are translated from guest physical addresses to host physical addresses that are used to access memory. As a result, it may be possible for guest software to modify its own IA-32 page table and handle page faults directly. This allows the VMM to avoid the VM exit associated with page table virtualization, which is the main source of virtualization overhead without using EPT. VMFUNC utilizes EPT by separating LCP1 (114) and LCPM1 (124) using, for example, EPT. In doing so, LCPM1 is protected from write operations originating from outside the VMFUNC entry point. The measurement can then be stored in a register included in the TPM. Furthermore, the EPT may be active only on a particular hardware thread, and therefore does not allow other software that can run on other hardware threads to tamper with or prevent LCP1 measurements. .

  In embodiments, EPT may be used to specify boundaries in memory for LCPM. It may be advantageous to recheck the LCPM code when the VM is loaded (without checking all VMM code). This is because, for example, LCPM code uniquely implements policy enforcement rules. This check does not reload the VMM code. Instead, the check is an in-memory check (eg, a memory page in the EPT is rehashed and compared to a whitelist corresponding to the in-memory image). PCR 19, 20, 21 can be used for these remeasurements. Because those PCRs do not include all measurements of VMM (which may be included in PCR 18).

  More particularly, in an embodiment, EPT is used to define groups of memory pages that have special properties and / or uses. This embodiment uses EPT to build a subset of VMM code and data pages that implement LCPM (eg, code) and LCP (eg, data) functions. When VMFUNC directs control to the VMM, the VMFUNC's new leaf can be used to validate the EPT containing the LCPM, and the LCP page has not changed since it was first launched. Embodiments may implement this in a manner similar to address ranges. LCPM pages may be checked / verified to ensure that they have not been moved, lengthened, and / or shortened. When VMFUNC is used to enforce the integrity policy, the predicted LCPM and LCP measurements can be passed to VMFUNC as parameters to the new leaf. The VMFUNC can then compare the EPT measurements before passing execution to the LCPM code. VMFUNC may indicate a fault if the comparison does not match.

  In an embodiment, the root VMM function may be distributed according to the CPU ring structure such that a VMFUNC call is made at Ring0 and an LCPM execution is made at Ring1. The rest of the VMM functionality can be implemented in Ring2 and Ring3. This implementation allows the hardware mechanism to protect / harden LCPM and VMFUNC calls. The VMFUNC leaf to support LCPM may force this particular leaf to be invoked only by the guest VMM at ring0. In an embodiment, the root VMM will use TXT. For example, TXT may be used to launch a VMM / VMM launcher. Once lunched, the LCPM in the VMM will be used to lunch the guest. Thus, the ring could be used to further isolate and isolate the launch function from the VMM and other non-security related functions within the VMM infrastructure.

  Embodiments are suitable for several environments including verified boot environments and measured boot environments.

  The verified boot receives a white list from the trusted server describing the expected software image. The trusted component of the client platform examines the software image before execution and compares it with the whitelist. If there is a match, the component is allowed to execute. If they do not match, a repair action is performed. A component that performs this operation is sometimes referred to as a verification route of trust. This may not require a hardware certification module (eg, TPM).

  However, the measured boot examines the software image before execution and saves it in a secure storage location. The measured boot may not have a whitelist that constrains or changes the boot. Instead, the whitelist is maintained on a server that hosts the resources that the client wishes to access. As a prerequisite for the server to grant access, a software integrity report is delivered to the server. Presentation of a report to the server is sometimes called attestation. The server compares the certification report with the whitelist to determine if the client poses a significant risk. If the client poses a risk, the network connection is closed. This may utilize a hardware certification module (eg, TPM).

  More particularly, in various embodiments, a verified boot directly enforces an integrity policy (ie, may prevent execution of code that does not meet the integrity policy). However, measured boot may allow execution of code that does not meet the integrity policy. For example, the integrity policy may actually reside on the remote server and may not be known to the client. Thus, the client may securely store the measurement (eg, in a TPM PCR) and the measurement is later “quoted” and delivered to the server as part of the “proof”. The server can compare the measurements found in the proof with the measurements on its local copy of the whitelist. Enforcement can be applied by the server by disconnecting the network connection or by placing the client in a remediation network where the update service attempts to reconfigure the client (eg, PC).

  Accordingly, embodiments launch the first VMM, authenticate the launch of the second VMM, and nest the second VMM within the first VMM. In place of or in addition to the authenticated boot of the nested VMM, in addition to the authenticated boot of the nested VMM, the embodiment authenticates the launch of the first VM and the first VMM (eg, root VMM) or nested VMMs may be used to manage the first VM. In either of the previous scenarios, the root VMM, or the VMM that hosts another VMM, or the VM, its root VMM or host VMM may be booted by a non-reentrant secure boot (eg, by a TXT launch).

  Embodiments bypass the root VMM while both (a) invoking the second LCPM and (b) using a hardware security certification module (e.g., but not limited to a TPM). To authenticate the second VMM lunch.

  With respect to the example for “bypassing” the root VMM, the root VMM may process the nested VMM as if it were a VM. Thus, both VM and VMM launch controls will be similar from the root VMM. Focus on the nested VMM. When a nested VMM is executed, it identifies the VM to load. The LCPM code for measuring the nested VMM is included in the nested VMM page range. Thus, VMFUNC may ensure that the EPT that describes the nested VMM is different from the EPT that describes the root VMM. Thus, if the root VMM accepts (opt-in), the root VMM can be circumvented to some extent for this operation. This may be based, for example, on the use of EPT and the use of bootstrapped VM0 (see FIG. 1) to boot VMFUNC and nested VMM.

  Embodiments may evaluate a second LCP associated with a nested second VMM with a second LCPM. Embodiments may perform an integrity measurement of the second VMM with the second LCPM and authenticate the measurement with the second LCP. Embodiments may extend the measurement to a PCR included in the TPM or other hardware certification module and update the log based on extending the measurement to the PCR.

  Embodiments may load the second LCPM into protected memory (eg, EPT) and execute the second LCPM, which has the root VMM privilege. Embodiments may allow the system to authenticate the white list contained in the second LCP with the second LCPM, which is specific to the VMM but not specific to the VM. Embodiments may also authenticate the second LCP while booting the first VMM based on the first LCP associated with the first VMM. Further, embodiments are not specifically configured for the second VMM (eg, architecturally or vendor-neutral), but are securely configured to interface with both the VMM and the nested VMM. The second VMM launch may be authenticated by a simple interface.

  Embodiments may be implemented in a number of different system types. Referring now to FIG. 3, a block diagram of a system according to an embodiment of the present invention is shown. Multiprocessor system 500 is a point-to-point interconnect system and includes a first processor 570 and a second processor 580 coupled by a point-to-point interconnect 550. Each of processors 570 and 580 may be a multi-core processor. The term “processor” refers to any device or device that processes electronic data from a register and / or memory and converts the electronic data into other electronic data that may be stored in the register and / or memory. May refer to part of the device. The first processor 570 may include a memory controller hub (MCH) and a point-to-point (PP) interface. Similarly, the second processor 580 may include MCH and PP interfaces. The MCH may couple the processor with respective memories, namely memory 532 and memory 534. Memory 532 and memory 534 may be part of main memory (eg, dynamic random access memory (DRAM)) that is locally attached to each processor. The first processor 570 and the second processor 580 may each be coupled to the chipset 590 by PP interconnection. Chipset 590 may include a TPM or cryptographic processor including, for example, an RSA accelerator, random number generator, key, certificate, PCR, static RAM, flash memory, monotonic counter, digital signature algorithm, and the like. Details regarding an example of such a chipset are available at least at http: // www-intel-com / design / mobile / platform / downloads / Trusted_Platform_Module_White_Paper-pdf. Embodiments are not limited to functioning with any one type of security engine or cryptographic processor, but instead various discrete and / or integrated security with various architectures from various vendors. May work with the engine. Chipset 590 may include a PP interface. Further, chipset 590 may be coupled to first bus 516 by an interface. Various input / output (I / O) devices 514 may be coupled to the first bus 516 along with a bus bridge 518 that couples the first bus 516 to the second bus 520. For example, in one embodiment, various devices including a keyboard / mouse 522, a communication device 526, and a data storage unit 528, such as a disk drive or other mass storage device that may include code 530, may be connected to the second bus 520. May be combined. Further, an audio I / O 524 may be coupled to the second bus 520.

  Embodiments may be implemented in code and stored in a non-transitory storage medium that stores instructions. The instructions can be used to program the system to execute the instructions. The storage medium includes a floppy (registered trademark) disk, an optical disk, a solid state drive (SSD), a read-only compact disk (CD-ROM), a compact writable compact disk (CD-RW). : Compact disk rewriteable), and any type of disk, including magneto-optical disks, semiconductor devices such as read-only memory (ROM), random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM: static r) and erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), and electrically erasable programmable read-only memory (EEPROM) Or may include, but is not limited to, an optical card, or any other type of medium suitable for storing electronic instructions. Embodiments of the present invention may be described herein with reference to data, such as instructions, functions, procedures, data structures, application programs, configuration settings, code, and the like. When data is accessed by a machine, the machine performs tasks, defines abstract data types, defines low-level hardware contexts, and / or other operations as described in more detail herein. You may respond by performing: Data may be stored in volatile and / or non-volatile data storage. The term “code” or “program” encompasses a wide range of components and constructs, including applications, drivers, processes, routines, methods, modules, and subprograms, and, when executed by a processing system, the desired one or more It may refer to any collection of instructions that perform an action. Further, alternative embodiments include processes that use fewer than all of the disclosed actions, processes that use additional actions, processes that use the same group of actions in a different order, and individual actions disclosed herein. May be combined, subdivided, or subjected to other changes. Components or modules may be combined or separated as desired and placed in one or more portions of the device.

Although the present invention has been described with respect to a limited number of embodiments, many variations and modifications from the embodiments will be apparent to those skilled in the art. The appended claims are intended to cover all such modifications and changes as fall within the true spirit and scope of the invention.
Examples of this embodiment are shown as the following items.
[Item 1]
When executed, the system
Launching the first virtual machine manager (VMM);
Authenticating the lunch of the second VMM; and
Nesting the second VMM within the first VMM;
A program that contains instructions that allow you to
[Item 2]
The system is
Authenticating a launch of a first virtual machine (VM) and managing the first VM using one of the first VMM and the second VMM; The program according to item 1, including.
[Item 3]
The program according to item 1 or 2, wherein the first VMM is a root VMM that is launched by a non-reentrant secure boot.
[Item 4]
Authenticating the launch of the second VMM includes both (a) invoking a second launch control policy module (LCPM) and (b) using a hardware security certification module, The program according to any one of items 1 to 3, including bypassing the first VMM.
[Item 5]
The program according to item 4, wherein the hardware security certification module includes a trusted platform module (TPM).
[Item 6]
Items 1-5 including instructions that allow the system to evaluate a second launch control policy (LCP) associated with the second VMM by a second launch control policy module (LCPM). The program according to any one of the above items.
[Item 7]
7. The program of item 6, comprising instructions that allow the system to perform an integrity measurement of the second VMM by the second LCPM and authenticate the measurement by the second LCP. .
[Item 8]
The system is
Including instructions to extend the measurement to a platform configuration register (PCR) included in a trusted platform module (TPM) and to update a log based on extending the measurement to the PCR; Item 8. The program according to item 7.
[Item 9]
The system includes instructions to load the second LCPM into protected memory and to execute the second LCPM, the second LCPM having root VMM privileges; Item 6. The program according to item 6.
[Item 10]
The system includes instructions that allow a whitelist contained in the second LCP to be authenticated by the second LCPM, the second LCP being specific to the VMM but not specific to the VM; Item 6. The program according to item 6.
[Item 11]
Item 6. includes instructions that allow the system to authenticate the second LCP while booting the first VMM based on a first LCP associated with the first VMM. The listed program.
[Item 12]
The system of the second VMM is configured with a secure interface that is not specifically configured for the second VMM and configured to interface with both a VMM and a nested VMM. 12. A program according to any one of items 1 to 11, comprising instructions for enabling a lunch to be authenticated.
[Item 13]
Launching the first virtual machine manager (VMM);
Authenticating the lunch of the second VMM; and
Nesting the second VMM within the first VMM.
[Item 14]
Authenticating a first virtual machine (VM) launch and managing the first VM using one of the first VMM and the second VMM;
14. The method according to item 13, comprising:
[Item 15]
Authenticating the launch of the second VMM includes both (a) invoking a second launch control policy module (LCPM) and (b) using a hardware security certification module, 15. A method according to item 13 or 14, comprising bypassing the first VMM.
[Item 16]
16. The method of any of items 13-15, comprising evaluating a second launch control policy (LCP) associated with the second VMM by a second launch control policy module (LCPM).
[Item 17]
17. The method of item 16, comprising performing an integrity measurement of the second VMM with the second LCPM and authenticating the measurement with the second LCP.
[Item 18]
Memory and
Coupled to the memory; (a) launching a first virtual machine manager (VMM); (b) authenticating a launch of a second VMM; and (c) inside the first VMM the second Processor to nest VMM,
Including system.
[Item 19]
The processor is
Authenticate the first virtual machine (VM) lunch,
Managing the first VM using one of the first VMM and the second VMM;
Item 19. The system according to Item 18.
[Item 20]
20. The system of item 18 or 19, wherein the processor evaluates the second launch control policy (LCP) associated with the second VMM by a second launch control policy module (LCPM).
[Item 21]
21. The system of item 20, wherein the processor performs an integrity measurement of the second VMM with the second LCPM and authenticates the measurement with the second LCP.

Claims (16)

A program executed in the system,
The processor of the system launches a first virtual machine manager (VMM);
The processor authenticates a launch of a second VMM, and the processor nests the second VMM within the first VMM;
Was executed,
Authenticating the launch of the second VMM is both when the processor calls (a) a second launch control policy module (LCPM) and (b) uses a hardware security certification module. A program including bypassing the first VMM while performing   The program of claim 1, wherein the first VMM is a root VMM that is launched by a non-reentrant secure boot. The program according to claim 1 or 2 , wherein the hardware security certification module includes a trusted platform module (TPM). Any of claims 1 to 3 for causing the processor to perform evaluation by a second launch control policy module (LCPM) of a second launch control policy (LCP) associated with the second VMM. The program according to item 1. 5. The program product of claim 4 , for causing the processor to perform an integrity measurement of the second VMM by the second LCPM and to authenticate the measurement by the second LCP. The processor is
For executing the updating the log based to extend the measurement platform configuration register (PCR) contained in the Trusted Platform Module (TPM), and the measurement to be extended to the PCR, claim 5 The program described in.   The program according to claim 4, for causing the processor to load the second LCPM having a root VMM privilege into a protected memory and to execute the second LCPM. The program according to claim 4 , for causing the processor to execute authentication by the second LCPM of a whitelist included in the second LCP that is unique to the VMM but not unique to the VM. The processor of claim 4 , for causing the processor to perform authentication of the second LCP while booting the first VMM based on a first LCP associated with the first VMM. program. The processor is configured for the second VMM with a secure interface that is not specifically configured for the second VMM and configured to interface with both the VMM and a nested VMM. The program according to any one of claims 1 to 9 , wherein execution of authenticating a lunch is executed. The processor launches a first virtual machine manager (VMM);
The processor authenticates a launch of a second VMM, and the processor nests the second VMM within the first VMM;
Only including,
Authenticating the launch of the second VMM is both when the processor calls (a) a second launch control policy module (LCPM) and (b) uses a hardware security certification module. Detouring the first VMM while performing
Method. The method of claim 11 , wherein the processor comprises evaluating a second launch control policy (LCP) associated with the second VMM by a second launch control policy module (LCPM). The method of claim 12 , wherein the processor includes performing an integrity measurement of the second VMM with the second LCPM and authenticating the measurement with the second LCP. Memory and
Coupled to the memory; (a) launching a first virtual machine manager (VMM); (b) authenticating a launch of a second VMM; and (c) inside the first VMM the second processor to nest VMM,
Only including,
Authenticating the launch of the second VMM means that the processor performs both calling the second launch control policy module (LCPM) and using a hardware security certification module. Including bypassing one VMM,
system. The system of claim 14 , wherein the processor evaluates a second launch control policy (LCP) associated with the second VMM by a second launch control policy module (LCPM). The system of claim 15 , wherein the processor performs an integrity measurement of the second VMM with the second LCPM and authenticates the measurement with the second LCP.

Images