METHOD AND APPARATUS FOR SEQUENTIAL HYPERVISOR INVOCATION

• US 20090249053A1
• Filed: 03/31/2008
• Published: 10/01/2009
• Est. Priority Date: 03/31/2008
• Status: Active Grant

• Current Assignee: Intel Corporation
• Original Assignee: Intel Corporation
• Inventors: Yao, Jiewen, Zimmer, Vincent J.
• Granted Patent: US 8,321,931 B2
• Time in Patent Office: Days
• US Class Current: 713/2
• CPC Class Codes: G06F 2009/45583 Memory management, e.g. access or allocation
• CPC Class Codes: G06F 2009/45587 Isolation or security of virtual machine instances
• CPC Class Codes: G06F 21/575 Secure boot
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects

Abstract

In some embodiments, the invention involves a system and method for invoking a series of hypervisors on a platform. A hardware-based secure boot of a chained series of virtual machines throughout the life of the pre-operating system (OS) firmware/BIOS/loader/option ROM execution, with component-wise isolation of the pre-extensible firmware interface (PEI) and driver execution environment (DXE) cores is utilized. In an embodiment, a Cache-As-RAM (CAR) based hypervisor, executing directly from Flash memory manages sequential invocation of a next hypervisor. Other embodiments are described and claimed.

Claims

1. A system for protecting boot phases of a platform having virtualization technology capabilities, comprising:

a processor coupled to a non-volatile firmware storage device;

a trusted software module for controlling an initial boot phase of the platform, the software module stored in the non-volatile firmware storage device, wherein the trusted software module is to be executed as a privileged component in a virtual machine to control boot operations;

system cache memory coupled to the processor, wherein a portion of the cache memory is to be configured as cache-as-RAM (CAR), and wherein the trusted software module is to be initially executed as resident in the CAR, prior to discovery and initialization of system random access memory (RAM), and once system RAM is initialized, the trusted software module is to be migrated to run in system RAM; and

a second software module to be launched by the trusted software module running in system RAM to control a next boot phase of the platform, wherein the second software module is to execute as a privileged component in a virtual machine.

2. The system as recited in claim 1, wherein the trusted software module executes a pre-extensible firmware interface (PEI) phase of platform boot, and where the second software module executes a driver execution environment (DXE) phase of platform boot.

3. The system as recited in claim 2, further comprising:

a third software module comprising a virtual machine monitor (VMM) to be launched by the second software module once DXE phase initialization is completed.

4. The system as recited in claim 1, further comprising a launch control policy (LCP) unit to verify that a software module is authorized before allowing the software module to be launched, wherein the LCP unit is to retrieve launch policy configuration data from non-volatile storage coupled to a trusted platform module (TPM NV).

5. The system as recited in claim 4, wherein the trusted software module is to be verified by microcode in the platform and successive software modules launched in a chain from the trusted software module cause the LCP unit to automatically verify the successive software modules against the policy configuration data before launching.

6. The system as recited in claim 5, wherein the successive software modules are identified by a hash value and the LCP unit is to compare the identified hash value with hash values stored in the TPM NV.

7. The system as recited in claim 1, further comprising an entry point verification unit to verify that a firmware interface table (FIT) stored on the non-volatile firmware storage device points to authorized boot of a security (SEC) software-module code using an hardware-authenticated code module prior to launching of the trusted software module, wherein the FIT identifies the location of the trusted software module.

8. A method for protecting boot phases of a platform having virtualization technology capabilities, comprising:

entering protected mode in the platform, responsive to a platform reset or power-on;

enabling cache coupled to a boot processor in the platform to act as random access memory, referred to as cache-as-RAM (CAR);

launching a first trusted software module, as a currently executing trusted software module, to execute in CAR, the first trusted software module retrieved from secure firmware storage coupled to the platform;

initializing system random access memory (RAM);

migrating the trusted software module to run in a privileged virtual machine in system RAM; and

launching at least one successive trusted software module, as a new currently running trusted software module, in accordance with at least one launch control policy (LCP) accessible to the currently running trusted software module, wherein the at least one launch control policy determines whether the at least one successive trusted software module is valid, and if the successive trusted software module is not valid, then causing the platform boot to fail.

9. The method as recited in claim 8, wherein the currently running trusted software module controls page allocation and generates an exclusion list to block lesser privileged software modules from accessing protected memory areas.

10. The method as recited in claim 9, further comprising:

retrieving policy data from a trusted platform module (TMP) non-volatile memory store (TMPNV) by a launch control policy (LCP) check unit;

comparing the retrieved policy data with a measured value for a successive trusted software module; and

determining whether the successive trusted software module is valid, and if so, then launching the successive trusted software module in a virtual machine, but if not, then causing the platform boot to fail.

11. The method as recited in claim 9, further comprising:

launching the first trusted software module by a security phase (SEC) of initial boot phase, wherein the SEC is authenticated by microcode coupled to the platform, and wherein the first trusted software module comprises a simple virtual machine monitor.

12. The method as recited in claim 11, wherein a launch control policy (LCP) check unit comprises microcode coupled to the platform to authenticate each successive trusted software module before allowing the successive trusted software module to be launched.

13. The method as recited in claim 12, further comprising:

verifying BIOS code by the LCP check unit before allowing the BIOS code to execute.

14. A computer readable storage medium having instruction stored thereon for protecting boot phases of a platform having virtualization technology capabilities, the instructions when executed on the platform, cause the platform to:

enter protected mode in the platform, responsive to a platform reset or power-on;

enable cache coupled to a boot processor in the platform to act as random access memory, referred to as cache-as-RAM (CAR);

launch a first trusted software module, as a currently executing trusted software module, to execute in CAR, the first trusted software module retrieved from secure firmware storage coupled to the platform;

initialize system random access memory (RAM);

migrate the trusted software module to run in a privileged virtual machine in system RAM; and

launch at least one successive trusted software module, as a new currently running trusted software module, in accordance with at least one launch control policy (LCP) accessible to the currently running trusted software module, wherein the at least one launch control policy determines whether the at least one successive trusted software module is valid, and if the successive trusted software module is not valid, then causing the platform boot to fail.

15. The medium as recited in claim 14, wherein the currently running trusted software module controls page allocation and generates an exclusion list to block lesser privileged software modules from accessing protected memory areas.

16. The medium as recited in claim 15, further comprising instructions to:

retrieve policy data from a trusted platform module (TMP) non-volatile memory store (TMPNV) by a launch control policy (LCP) check unit;

compare the retrieved policy data with a measured value for a successive trusted software module; and

determine whether the successive trusted software module is valid, and if so, then launch the successive trusted software module in a virtual machine, but if not, then cause the platform boot to fail.

17. The method as recited in claim 15, further comprising instructions to:

launch the first trusted software module by a security phase (SEC) of initial boot phase, wherein the SEC is authenticated by microcode coupled to the platform, and wherein the first trusted software module comprises a simple virtual machine monitor.

18. The medium as recited in claim 17, wherein a launch control policy (LCP) check unit comprises microcode coupled to the platform to authenticate each successive trusted software module before allowing the successive trusted software module to be launched.

19. The medium as recited in claim 18, further comprising instructions to:

verify BIOS code by the LCP check unit before allowing the BIOS code to execute.