Patent Description:
It is with respect to these and other general considerations that examples have been described. Also, although relatively specific problems have been discussed, it should be understood that the examples should not be limited to solving the specific problems identified in the background.

<CIT> describes a Secure Code Launcher that establishes platform trustworthiness and uses hardware or firmware-based components to securely launch one or more software components such as hypervisors on arbitrary computing platforms. A boot process of the computing device may load code from untrusted firmware to load an OS loader. The Secure Code Launcher intercepts calls from the OS loader to perform secure program launch of OS kernel components or hypervisors.

<CIT> describes methods for performing a secure boot of a computer system involving receiving and initialization routine having a sub-routine, measuring the initialization routine to compute a hash value, and comparing the computed hash value with a core root of trusted hash values to verify the initialization routine.

<CIT> describes 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, with component-wise isolation of the pre-extensible firmware interface and driver execution environment, is utilized. A Cache-As-RAM based hypervisor, executing directly from Flash memory may manage sequential invocation of a next hypervisor.

<CIT> describes a system and method for securing a hypervisor and operating system on a computing device. The method comprises uploading an encrypted hypervisor to a hardware chip, decrypting the hypervisor using a secure security processor prior to executing the hypervisor and, while the hypervisor is being executed, continuously authenticating the hypervisor by at least one on-chip component.

The object of the present invention is to improve information security of hypervisors.

This object is solved by the subject-matter of the independent claims.

Embodiments of the present invention are defined by the dependent claims.

This disclosure generally relates to hypervisors that are used to create one or more virtual machines or guest machines. In order to ensure that the hypervisor, and its associated information, is not compromised thereby compromising the virtual machines created by the hypervisor, the hypervisor may undergo a secure launch process. For example, the hypervisor, or a secure hypervisor loader, may be authenticated and be configured to execute before any other non-secure code is executed. The secure launch described herein may also act to protect the hypervisor itself as well as the operating system of the host machine on which the hypervisor executes.

In addition, or as an alternative to the above, any hardware on which the hypervisor is executing or is otherwise associated with may be configured to support and/or establish a hardware-based root of trust for the hypervisor. In some cases, the root of trust may be established even after any non-secure code has been executed by the hardware.

Additionally, the hypervisor may be configured to securely retrieve platform details as it is being securely launched. These platform details may include, among others, how to start or reset a logical processor; how to interact with input-output memory management units (IOMMUs), memory management units (MMUs), timers, interrupt controllers and interrupt remapping hardware associated with the hardware; how to shutdown, restart or reboot the system; what the memory map looks like; how to cause a zeroing of some or all memory on a shutdown or reboot of the system; how to enter processor and system-wide low level power states and the like.

Accordingly, described herein is a method for validating that a hypervisor was securely launched. In some instances, the method includes initializing a hypervisor. Once the hypervisor has been initialized, a verification operation is performed. The verification operation may be used to ensure that the hypervisor was initialized securely. When it is determined that the hypervisor was initialized securely, one or more platform details are obtained. Those platform details may then be stored in a memory device.

The present disclosure also describes a method for securely launching a hypervisor. The method includes accessing binary code associated with the hypervisor and validating at least one security credential associated with the binary code. In some instances, the security credential is specified may a manufacturer of the binary code. Once the securing credential has been validated, the binary code may be executed.

The present application also discloses a system that includes at least one processor and a memory coupled to the at least one processor and storing instructions that, when executed by the at least one processor, perform a method for validating that a hypervisor has been securely launched. In some instances, the system stores a decryption key in a secure memory location. Verification is then provided to the system that indicates that one or more expected measurements have been met during a hypervisor launch process. When it is determined that the one or more expected measurements have been met, access to the decryption key is enabled.

Non-limiting and non-exhaustive examples are described with reference to the following Figures.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the present disclosure. Examples may be practiced as methods, systems or devices. Accordingly, examples may take the form of a hardware implementation, an entirely software implementation, or an implementation combining software and hardware aspects. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.

The present disclosure describes a secure launch process for a hypervisor that creates and runs one or more virtual machines. The process described herein may also be used to guarantee the integrity of the hypervisor and ensure that the hypervisor hasn't been replaced with a malicious hypervisor.

In previous solutions, a Unified Extensible Firmware Interface (UEFI) (that defines a software interface between an operating system and firmware of the platform) was typically used and trusted to securely launch a hypervisor. However, the solution described herein does not rely solely on the UEFI code base and as such, provides a more secure way to launch a hypervisor.

For example and as will be described in more detail below, the secure launch process described herein enables a platform on which the hypervisor is launched to verify the integrity of the hypervisor. Further, the process described herein enables the hypervisor, or other software on the platform, to ensure that control that is transferred to the hypervisor is done in a secure manner. That is, the system may execute one or more instructions that will put the system into a known "good" state when control is passed to the hypervisor.

These and other examples will be described in more detail below with respect to <FIG>.

<FIG> illustrates an example host machine <NUM> on which a hypervisor <NUM> may be securely launched according to an example. In some implementations, the host machine <NUM> may be any computing device capable of launching one or more virtual machines, such as, for example, virtual machine <NUM>. The host machine <NUM> may be a desktop computer, a laptop computer, a mobile computing device, a tablet computing device, a wearable computing device, a gaming device and so on.

As shown in <FIG>, the host machine <NUM> may include hardware <NUM>. The hardware <NUM> may include one or more processors, one or more storage devices, one or more memory devices and so on.

In the example shown in <FIG>, the host machine <NUM> also includes a hypervisor <NUM>. In some cases, the hypervisor <NUM> may be software, hardware, firmware or a combination thereof. As will be explained in more detail below, the hypervisor <NUM> is configured to create, run and/or manage one or more virtual machines <NUM>.

Because the hypervisor <NUM> is configured to create, run and/or manage one or more virtual machines, the host machine <NUM> may want to ensure that the hypervisor <NUM> will be launched securely. The host machine <NUM> may also want a way to ensure that the integrity of the hypervisor <NUM> remains intact and that the secure launch process was executed correctly.

The process of securely launching a hypervisor may begin when the host machine <NUM> boots up. During the boot process, one or more boot components of the host machine <NUM> may load the hypervisor <NUM> from a storage location of a storage device associated with the host machine <NUM>. In some instances, the UEFI code base may be used to initiate the process but it may not be the only component relied on to securely load code that launches the hypervisor <NUM>. In other instances, the hypervisor <NUM> may be launched without using the UEFI code base.

Although the hypervisor <NUM> has been loaded, the hypervisor <NUM> may still be in an untrusted or unverified state. As such, the host machine <NUM> (via the hardware <NUM> or other software and/or firmware associated with the host machine <NUM>) may issue one or more commands that initiate the secure launch process. The secure launch process validates the components that eventually launch the hypervisor <NUM> such that the host system <NUM> knows that these components are operating in a good state.

For example, the host system <NUM> may have access to code (e.g., binary code) or other such secure instructions that is used to securely launch or otherwise verify the integrity of the hypervisor <NUM>. In some instances, this code may be securely stored or otherwise be a part of the hardware <NUM>. In other implementations, this code may be securely stored in a storage device associated with the host machine <NUM>. Regardless of where the code is stored, the host system <NUM> may be required to validate the integrity of the code before it is executed. In some cases, the verification process includes verifying or validating security credentials associated with the code. In some instances, the security credentials may be a signature, a certificate or other such security credential. Although specific verification processes are described, other verification processes may be used.

Verification of the code helps the host system <NUM> ensure that a boot processor associated with the hardware <NUM> is active and is the only processor that will be used to launch the hypervisor <NUM>. As such, the host machine <NUM> may be able to determine that other processors aren't active and executing malicious code when the hypervisor <NUM> is being launched. Additionally, verification of the code may be used to ensure that other components of the host machine <NUM> weren't able to access the storage location of the code and overwrite it with malicious code or otherwise tamper with the code.

Once the host system <NUM> verifies the integrity of the code (e.g., the code has been signed), the hardware <NUM> may execute the code and start the hypervisor <NUM>. In some instances, the code may be required to execute in a defined sequence. The defined sequence may only be known to the hardware and/or the hypervisor. As such, when the hypervisor and/or hardware subsequently determines whether the hypervisor was securely launched, the verification process may include verification that the sequence of steps were followed.

Additionally, the code may be configured to pull additional code (e.g., binary code) from other secure storage locations within the host machine. In such instances, the additional code may be verified in a similar manner as was described above and may also be required to execute in a defined sequence. As such, a determination of whether the additional code was executed in the defined sequence may also be used to verify the integrity of the hypervisor and whether it was securely launched.

In some instances, the storage locations may be protected or otherwise secured such that only certain trusted components of the host machine <NUM> know where this code is stored and have access to it. For example, in some implementations, the locations of the additional code may only be determined once the original code has been verified and the hardware <NUM> has begun executing the original code.

Once the process above has been completed and the hypervisor <NUM> has been securely launched, the host machine <NUM> may want to verify that the hypervisor <NUM> was securely launched and/or verify that the hypervisor <NUM> is still operating in a good and known state. In some cases, this verification process may enable the hypervisor <NUM> to unlock various secrets stored by the host machine <NUM> and/or perform other actions on behalf of the host machine <NUM>.

In some instances, the verification process includes the use of a trusted platform module. The trusted platform module may be part of the hardware <NUM>. In some cases, the trusted platform module may be used to store a decryption key (or secret information) that may be used by the hypervisor <NUM> to access additional secrets or stored information on the host machine <NUM>. However, the trusted platform module may be configured to only release this information when certain measurements have been met. For example, the trusted platform module may need verification that the secure launch process described above has been successfully executed. In some instances, the verification that the secure launch process has occurred may come from a component other than the hypervisor <NUM>. For example, the hardware <NUM> (or a software component) may be configured to provide verification to the trusted platform module that the secure launch process has been successfully completed. If the secure launch process has not occurred, the trusted platform module may prohibit any component from accessing the decryption key. Although the secure launch process is specifically mentioned as an expected measurement, other measurements may also be required.

In some instances, the measurements that the trusted platform module is expecting may be provisioned at the time the trusted platform module was manufactured. In other instances, the measurements may be programmatically provided to the trusted platform module.

Once the hypervisor <NUM> has been securely launched, the hypervisor <NUM> may be configured to communicate directly with the hardware <NUM> of the host machine <NUM>. In such cases, the hypervisor <NUM> may be viewed as having the highest privilege level among the various other software, firmware and/or other hardware components of the host machine <NUM>. Thus, for example, when the host machine <NUM> boots up, the hypervisor <NUM> may be the first item or component that is created, instantiated or otherwise executed on the host machine <NUM> as a result of the secure launch process.

The hypervisor <NUM> may create one or more virtual machines <NUM>. Each virtual machine <NUM> may emulate a computer system and, as such, may provide the functionality of a physical computing device. In some examples, the virtual machine <NUM> may include a privileged kernel <NUM> and a normal kernel <NUM>.

The privileged kernel <NUM> may be configured to execute a secure operating system. As such, the privileged kernel <NUM> can run one or more secure programs that contain various secretes utilized by the virtual machine <NUM>, the hypervisor <NUM>, and/or the normal kernel <NUM>. For example, the privileged kernel <NUM> may store various credentials, encryption keys and the like.

The normal kernel <NUM> may be configured to execute various "normal" programs and applications, such as, for example, word processing applications, browser applications, spreadsheet applications and so on. However, due to the less secure security configuration (e.g., when compared to the security configuration of the privileged kernel <NUM>) of the normal kernel <NUM>, the normal kernel <NUM> may not store any credentials, encryption keys, or other secrets that may be utilized by the virtual machine <NUM> and/or the hypervisor <NUM>. As such, when various secrets are needed by the various applications running on the normal kernel <NUM>, the normal kernel <NUM> may request those secrets from the privileged kernel <NUM>. In another implementation, the normal kernel <NUM> may request that the privileged kernel <NUM> perform one or more actions, using one or more of the stored secrets, on behalf of the normal kernel <NUM> and/or one or more applications executing on the normal kernel.

In some instances and due to the hypervisor <NUM> allowing the virtual machine to execute both the privileged kernel <NUM> and the normal kernel <NUM>, the hypervisor <NUM> may execute, or may cause the virtual machine <NUM> to execute, in a privileged context. The privileged context enables the hypervisor <NUM> to switch between the privileged kernel <NUM> and the normal kernel <NUM> and/or various user modes.

As the hypervisor <NUM> is responsible for various virtual machines <NUM> and each virtual machine's respective kernels, it is important that the hypervisor <NUM> be one of the most, if not the most secure component on the host machine <NUM>. For example, if the hypervisor <NUM> is software, the hypervisor <NUM> may have the highest privilege level when compared to other software that may be executing on the host machine <NUM>. In some cases, the hardware <NUM> provides the hypervisor <NUM> with privilege level architecture that enables the hypervisor <NUM> to run and to exert authority over every virtual machine <NUM> the hypervisor <NUM> creates.

As will be explained in more detail below with respect to <FIG>, the host machine <NUM> may include nested hypervisors. In such cases, the primary hypervisor may have authority over the secondary hypervisor. Additionally, each hypervisor may be required to undergo a secure launch process such as described above. Additionally, each hypervisor may be required to verify to the other hypervisors (or provide verification to the hardware <NUM> or other component of the host machine <NUM>) that it was securely launched. For example, a "parent" hypervisor may be required to verify that it has been securely launched to a "child" hypervisor or vice versa. In other example, the hypervisor <NUM> may be required to provide verification to the hardware <NUM> that is was securely launched prior to the hypervisor <NUM> creating any children hypervisors.

<FIG> illustrates another example host machine <NUM> on which a software layer <NUM> exists between the hypervisor <NUM> and the hardware <NUM> of the host machine <NUM> according to an example. In this example, the hardware <NUM>, the hypervisor <NUM> and virtual machine <NUM>, the normal kernel <NUM> and the privileged kernel <NUM> may function in a similar manner such as was described above with respect to <FIG>. However, in this example, the host machine <NUM> includes a software layer <NUM> positioned between the hypervisor <NUM> and the hardware <NUM>.

In some cases, the software layer <NUM> may be responsible for certain aspects of the hardware <NUM>. For example, the software layer <NUM> may be responsible for putting the host machine <NUM> in a sleep state, resuming programs or applications when the host machine <NUM> awakens from a sleep state and so on. In other example, the software layer <NUM> may include code (e.g., binary code) that is used to execute the secure launch process such as described above.

It is also possible that the software layer <NUM> has a higher privilege level than the hypervisor <NUM>. In such cases, the hypervisor <NUM> should be configured to communicate directly with the software layer <NUM>. That is, any communication between the software layer <NUM> and any of the other components (e.g., the privileged kernel <NUM>, the normal kernel <NUM> etc.) of the host machine <NUM> should be routed through or otherwise mediated by the hypervisor <NUM>. For example, any communication that occurs between the normal kernel <NUM> and the software layer <NUM> should be handled by the hypervisor <NUM>. However, it is also possible that certain communication channels could be allowed directly between lower privilege software and the software layer <NUM> without each individual message having to go through the hypervisor <NUM>.

In some cases when the software layer <NUM> is present, it may be desirable for the hypervisor <NUM> to be able to turn off or deactivate the software layer <NUM>. For example, once the hypervisor <NUM> has been initialized, the hypervisor <NUM> may be configured to turn off the software layer <NUM>, suspend operations performed by the software layer <NUM>, intercept commands provided by or sent to the software layer <NUM> and so on. In this way, the hypervisor <NUM> may have the highest privilege level within the host machine <NUM>. As such, security features of the host machine <NUM> may be improved as the hypervisor <NUM> controls communications between the various components of the host machine <NUM>. As will also be described below, the host machine <NUM> may be able to determine that the hypervisor <NUM> was securely launched thereby preventing any attacks that may be brought to the host machine <NUM>.

<FIG> illustrates an example host machine <NUM> having nested hypervisors that support nested virtualization according to an example. As shown in <FIG>, the host machine <NUM> may include hardware <NUM> and a hypervisor <NUM>. In some cases, the hardware <NUM> and the hypervisor <NUM> may function in a similar manner such as described above. For example, the hypervisor <NUM> may communicate with the hardware <NUM> as well as with a normal kernel <NUM> and a privileged kernel <NUM> of a virtual machine <NUM>.

Additionally, the hypervisor <NUM>, and/or the hardware <NUM>, may be able to create, run, and/or command another hypervisor (shown in <FIG> as hypervisor <NUM><NUM>) and another virtual machine (shown in <FIG> as virtual machine <NUM><NUM>). As with the virtual machine <NUM>, the virtual machine <NUM><NUM> may include a privileged kernel (shown in <FIG> as privileged kernel <NUM><NUM>) and a normal kernel (shown in <FIG> as normal kernel <NUM><NUM>). Each of these kernels may function in a similar manner to the normal kernel <NUM> and the privileged kernel <NUM> described above.

The hypervisor <NUM><NUM> may communicate with and run the privileged kernel <NUM><NUM> and the normal kernel <NUM><NUM> in a similar manner as described above. For example, the hypervisor <NUM><NUM> of the virtual machine <NUM><NUM> may run in a privileged context, which enables the hypervisor <NUM><NUM> to switch between the privileged kernel <NUM><NUM> and the normal kernel <NUM><NUM>.

The hypervisor <NUM><NUM> may believe that it is the only hypervisor in the host machine <NUM>. However, the hypervisor <NUM><NUM> may be subject to and commanded by the hypervisor <NUM>. That is, any communications between the hypervisor <NUM><NUM> and the hardware <NUM> may be passed through the hypervisor <NUM>. In some instances, hypervisor <NUM><NUM> may be launched using the secure launch process described above. Once launched, the hypervisor <NUM><NUM> and/or the hardware <NUM> may be required to verify that the hypervisor <NUM><NUM> was securely launched. In some implementations, the hypervisor <NUM> may also be required to verify that it was securely launched before it is allowed to create the virtual machine <NUM><NUM> and/or the hypervisor <NUM><NUM>.

Although not shown in <FIG>, the host machine <NUM> may also include a software layer, such as, for example, software layer <NUM> (<FIG>). When the software layer is present, the hypervisor <NUM><NUM> should only be configured to communicate the hypervisor <NUM>. As was described above, the hypervisor <NUM><NUM> will not be launched until a verification is received that the hypervisor <NUM> has been launched securely.

Regardless of the configuration of the host machine, it is imperative that the hypervisor be launched securely. The options to securely launch the hypervisor may differ depending on the configuration of the host machine. In some implementations, the options described below may be performed separately. In other implementations, the options described below are mutually exclusive. In yet other implementations, the options described below may be performed sequentially, simultaneously or substantially simultaneously.

The first option to ensure that the hypervisor is securely launched is to ensure that that the hardware (e.g., hardware <NUM>) launches the hypervisor <NUM> once the host machine <NUM> boots. For example, the hardware <NUM> may have knowledge of where the hypervisor <NUM> binary is located and may be configured to immediately cause the hypervisor <NUM> to execute or establish a privilege level for the hypervisor upon booting up. Stated another way, the hypervisor <NUM>, or a secure hypervisor loader associated with the hardware <NUM>, can be authenticated and start executing before any non-secure code is executed. In some cases, the non-secure code may be part of the software layer <NUM> (<FIG>).

A second option may be to include or otherwise provide access to a special boot loader. In some cases, the special boot loader may be able to leverage a specialized secure launch mechanism (e.g., an instruction or command) that causes the hardware <NUM> to launch the hypervisor <NUM> and ensure the hypervisor <NUM> is securely executed. In some cases, the second option may be used when the software layer <NUM> is present in the host machine and/or when a unified extensible firmware interface (UEFI) (or a basic input/output system (BIOS)) is executed prior to the hypervisor being launched.

In some cases, and regardless of which option above is used to launch the hypervisor <NUM>, the hardware <NUM> may validate that the hypervisor <NUM> is in a secure state. If not, the hardware <NUM> may be configured to place the hypervisor <NUM> in the secure state. Once the hypervisor <NUM> is in the secure state, the hypervisor <NUM> may begin creating one or more virtual machines <NUM>.

As discussed above, the hypervisor <NUM> may be configured to provide (via software and hardware architectural mechanisms) various different privilege levels. For example, the hypervisor <NUM> may allow the virtual machine <NUM> to execute in a "privileged" level and a "normal" level or "less privileged" level. Although two specific levels are mentioned, the hypervisor <NUM> may allow one or more virtual machines to execute in various different privilege levels. Because of this configuration, the hypervisor <NUM> may be able to switch between the privileged kernel <NUM> and the normal kernel <NUM>.

When the hypervisor <NUM> is in the privileged level, various platform details associated with the host machine <NUM> may be obtained by the hypervisor <NUM>. In some cases, the platform details may be conveyed to the hypervisor <NUM> using one or more Advanced Configuration and Power Interface (ACPI) tables. In other cases, the hypervisor <NUM> may be instructed to search or otherwise obtain these platform details from various other software or hardware components associated with the host machine <NUM>.

For example, in some cases, platform details may be hard-coded or discovered via a non-architectural interface. In this example, a highly privileged software module executing on host machine may be responsible for boot-strapping the system and providing these details.

In some cases, the details may include a location of one or more IOMMU that the hypervisor <NUM> may use to protect itself from direct memory access (DMA) attacks, how to zero some or all of the memory (e.g., on shutdown or reboot), how to power the host machine <NUM> down, how to reset the host machine <NUM>, what the memory maps look like (e.g., what ranges include the MMIO, RAM, persistent memory, etc.), how to start additional processors, and so on.

<FIG> illustrates a method <NUM> for securely launching a hypervisor according to an example. In some cases, the method <NUM> may be used by a host system, such as, for example, host system <NUM> (<FIG>), host system <NUM> (<FIG>), and/or host system <NUM> (<FIG>).

Method <NUM> begins at operation <NUM> in which binary code associated with the hypervisor is accessed. In some examples, the binary code may be stored by the host system that launches a hypervisor, such as, for example, hypervisor <NUM> (<FIG>). For example, the binary code may be stored in hardware that is used to securely launch the hypervisors. In other example, the binary code may be stored in a storage device, such as, for example, a trusted zone or other storage area of a host machine.

Once the binary code is accessed, flow proceeds to operation <NUM> and host system validates the components that are configured to execute the binary code associated with the hypervisor. For example, in some cases, a boot processor of the hardware may be the only component that is configured to initially access and execute the binary.

Flow then proceeds to operation <NUM> and the binary is validated. In some instances, the hardware may be configured to check or validate one or more security credentials (e.g., signatures or certificates) associated with the binary. For example, in some cases, the binary may be created by the manufacturer of the hardware and/or software that is executing on the host system. In such cases, the manufacturer may associate one or more security credentials with the binary that is created at the time of manufacture. These security credentials may need to be validated in order to ensure that the hypervisor is securely launched.

Once the binary has been validated, flow proceeds to operation <NUM> and the binary is executed and the hypervisor is launched. In some instances, the binary may be configured to pull additional code from other storage locations within the host machine. In such instances, the additional code may be verified in a similar manner as was described above.

In some instances, the storage locations may be protected such that only certain trusted components of the host machine know where the additional code is stored. For example, in some implementations, the locations of the additional code may only be determined once the binary associated with the hypervisor has been verified and the hardware has begun executing the binary.

In some instances, the hardware of the host system may be configured such that the hypervisor is the first component that is launched when the host system boots. In other cases, the host system may include a software layer that is executed once the system boots. In some instances, the binary may be stored in this software layer. Once the software layer executes, the hypervisor may be created and/or execute.

In cases in which a host system has nested hypervisors, each hypervisor may be launched using similar processes. However, in some cases, the root or parent hypervisor may be required to validate or verify that is has been securely launched prior to launching or otherwise causing the host system to execute code that will be used to securely launch a child hypervisor. Once the child hypervisor has been launched, it may also be required to verify that the secure launch process has been successfully executed.

<FIG> illustrates a method <NUM> for validating that a hypervisor was securely launched according to an example. In some instances, the method <NUM> may be executed by a host system and/or hardware associated with host system once the method <NUM> shown and described with respect to <FIG> has been executed. For example, the hardware of a host machine may utilize the method described below to ensure the hypervisor has been securely launched.

Method <NUM> begins at operation <NUM> in which a hypervisor is securely launched such as described above with respect to <FIG>. Flow then proceeds to operation <NUM> in which the hypervisor verifies that it was securely launched. In some cases, the hypervisor may be configured to determine if it was securely launched regardless of whether it was launched when the host system booted up or if it was launched after any software layer that is present in the host machine.

In some instances, the hardware may also be configured to verify that the hypervisor is secure and/or was securely launched. For example, the hardware may provide an attestation to the hypervisor that the hypervisor was securely launched and/or is executing securely. In other cases, the hardware may be configured to determine whether one or more measurements or processes that it expected to be executed were indeed executed. For example, the hardware may be configured to determine whether the secure launch process described above was successfully executed.

In some cases, the hypervisor may be configured to query the hardware (e.g., a chip or a trusted platform module) for a secret (or secrets) that is stored by the hardware. In some cases, the secret may be released when the hypervisor provides proof that an instruction was used to securely launch the hypervisor. If the hypervisor has no knowledge of the instruction and/or cannot otherwise prove that this instruction was used to securely launch the hypervisor, the secret will not be released. If the secret is not released, the hypervisor may be deactivated and instantiated again.

Once the hypervisor has been securely launched and it has been verified, flow proceeds to operation <NUM> and various platform details are obtained. The platform details may be obtained from an ACPI table. Although an ACPI table is specifically mentioned, the hypervisor may obtain these details in other ways. In some cases, the hypervisor may be required to obtain or validate/verify these details directly from the hardware that is in charge of or otherwise executes these details rather than from other software components as the software components may be less secure. In this way, the hypervisor may know that the information it receives is correct.

Flow then proceeds to operation <NUM> and the platform details are written into memory and/or into a set of registers. For example, because the hardware and/or the hypervisor knows that the hypervisor has been securely launched, the hypervisor may be permitted to execute various instructions it receives on behalf of the host system.

In some cases, and referring back to <FIG>, the hardware <NUM> may include or otherwise be associated with one or more logical processors. Further, each logical processor may be associated with one or more virtual processors. Each logical processor and/or each virtual processor may also be associated with a system register.

The hypervisor <NUM> may be configured to intercept all system register modifications at per-register granularity. That is, the hypervisor <NUM> may be able to intercept a single read and/or a single write that is sent to and/or provided from a particular system register. In another implementation, the hypervisor <NUM> may be configured to intercept a specified number of commands from a specified number of system registers.

In some cases, the hypervisor <NUM> may have access to or otherwise be associated with a hypervisor system register. In some cases, the hypervisor system register is only available to the hypervisor <NUM> due to the privilege level of the hypervisor <NUM>. The hypervisor system register may be associated with a bitmap or other structure that is used to store or otherwise identify the location of each system register that is used or accessed by less privileged software (e.g., software that executes in the normal kernel <NUM>).

For example, the bitmap may include entries the each represent a system register. That is, entry <NUM> in the bitmap may correspond to system register A while entry <NUM> in the bitmap may correspond to system register B. When a command is issued the hypervisor <NUM> may choose whether or not to intercept the command.

In another example, the hypervisor <NUM> may be able to intercept reads and writes separately and choose which commands it wants to intercept. For example, the hypervisor system register may be associated with two different bitmaps or structures with one structure being associated with reads and another structure being associated with writes. Thus, entry <NUM> in bitmap <NUM> may correspond to a write intended for system register A, entry <NUM> in bitmap <NUM> may correspond to a read intended for system register A, entry <NUM> in bitmap <NUM> may correspond to a write intended for system register B, entry <NUM> in bitmap <NUM> may correspond to a read intended for system register B and so on.

When a command is issued by the normal kernel <NUM>, the hypervisor <NUM> may intercept the command, and identify, using the bitmap, the system register the command is intended for. Once the command is intercepted, the hypervisor <NUM> may be able to determine what additional steps, if any, it should perform.

For example, if a hibernate command is issued by the normal kernel <NUM>, the hypervisor <NUM> may intercept the command and determine that the host machine <NUM> is going to enter a hibernation state. In response, the hypervisor <NUM> may encrypt its memory and/or the memory utilized by the privileged kernel <NUM>. Upon a system resume, the encrypted data may still be secure.

As discussed above, the hypervisor <NUM> may intercept any number of commands that target any number of system registers. However, the hypervisor <NUM> is configured to intercept only those commands from only those registers. For example, the hypervisor <NUM> may intercept three commands intended for three system registers. In another implementation, the hypervisor may intercept two commands intended for two system registers.

In some instances, the hypervisor <NUM> may be configured to intercept all system power state transitions. This is unlike current intercepts in which a hypervisor intercepts a block of commands for a block of system registers even when the hypervisor is only interested in a single command or system register.

<FIG> and their associated descriptions provide a discussion of a variety of operating environments in which aspects of the disclosure may be practiced. However, the devices and systems illustrated and discussed with respect to <FIG> are for purposes of example and illustration and are not limiting of a vast number of electronic device configurations that may be utilized for practicing aspects of the disclosure, as described herein.

<FIG> is a block diagram illustrating physical components (e.g., hardware) of a computing device <NUM> with which aspects of the disclosure may be practiced. The computing device <NUM> may be similar to the host machine <NUM> described above with respect to <FIG>.

In a basic configuration, the computing device <NUM> may include at least one processing unit <NUM> and a system memory <NUM>. Depending on the configuration and type of computing device <NUM>, the system memory <NUM> may comprise, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories. The system memory <NUM> may include an operating system <NUM> and one or more program modules <NUM> or components suitable for identifying various objects contained within captured images such as described herein.

The operating system <NUM>, for example, may be suitable for controlling the operation of the computing device <NUM>. Furthermore, examples of the disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in <FIG> by those components within a dashed line <NUM>.

The computing device <NUM> may have additional features or functionality. For example, the computing device <NUM> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by a removable storage device <NUM> and a non-removable storage device <NUM>.

As stated above, a number of program modules and data files may be stored in the system memory <NUM>. While executing on the processing unit <NUM>, the program modules <NUM> (e.g., a hypervisor <NUM>) may perform processes including, but not limited to, the aspects, as described herein.

Furthermore, examples of the disclosure may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. For example, examples of the disclosure may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in <FIG> may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units and various application functionality all of which are integrated (or "burned") onto the chip substrate as a single integrated circuit.

When operating via an SOC, the functionality, described herein, with respect to the capability of client to switch protocols may be operated via application-specific logic integrated with other components of the computing device <NUM> on the single integrated circuit (chip). Examples of the disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, examples of the disclosure may be practiced within a general purpose computer or in any other circuits or systems.

The computing device <NUM> may also have one or more input device(s) <NUM> such as a keyboard, a trackpad, a mouse, a pen, a sound or voice input device, a touch, force and/or swipe input device, etc. The output device(s) <NUM> such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The electronic device <NUM> may include one or more communication connections <NUM> allowing communications with other computing devices <NUM>. Examples of suitable communication connections <NUM> include, but are not limited to, radio frequency (RF) transmitter, receiver, and/or transceiver circuitry; universal serial bus (USB), parallel, and/or serial ports.

The term computer-readable media as used herein may include computer storage media.

<FIG> and <FIG> illustrate a mobile computing device <NUM>, for example, a mobile telephone, a smart phone, wearable computer (such as a smart watch), a tablet computer, a laptop computer, and the like, with which examples of the disclosure may be practiced. With reference to <FIG>, one aspect of a mobile computing device <NUM> for implementing the aspects is illustrated.

In a basic configuration, the mobile computing device <NUM> is a handheld computer having both input elements and output elements. The mobile computing device <NUM> typically includes a display <NUM> and one or more input buttons <NUM> that allow an individual to enter information into the mobile computing device <NUM>. The display <NUM> of the mobile computing device <NUM> may also function as an input device (e.g., a display that accepts touch and/or force input).

If included, an optional side input element <NUM> allows further input. The side input element <NUM> may be a rotary switch, a button, or any other type of manual input element. In alternative aspects, mobile electronic device <NUM> may incorporate more or less input elements. For example, the display <NUM> may not be a touch screen in some examples. In yet another alternative embodiment, the mobile computing device <NUM> is a portable phone system, such as a cellular phone. The mobile computing device <NUM> may also include an optional keypad <NUM>. Optional keypad <NUM> may be a physical keypad or a "soft" keypad generated on the touch screen display.

In various examples, the output elements include the display <NUM> for showing a graphical user interface (GUI) (such as the one described above that provides visual representation of a determined pronunciation and may receive feedback or other such input, a visual indicator <NUM> (e.g., a light emitting diode), and/or an audio transducer <NUM> (e.g., a speaker). In some aspects, the mobile computing device <NUM> incorporates a vibration transducer for providing an individual with tactile feedback. In yet another aspect, the mobile computing device <NUM> incorporates input and/or output ports, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., a HDMI port) for sending signals to or receiving signals from an external device.

<FIG> is a block diagram illustrating the architecture of one aspect of a mobile computing device <NUM>. That is, the mobile computing device <NUM> can incorporate a system (e.g., an architecture) <NUM> to implement some aspects. In one embodiment, the system <NUM> is implemented as a "smart phone" capable of running one or more applications (e.g., browser, e-mail, calendaring, contact managers, messaging clients, games, media clients/players, content selection and sharing applications and so on). In some aspects, the system <NUM> is integrated as an electronic device, such as an integrated personal digital assistant (PDA) and wireless phone.

One or more application programs <NUM> may be loaded into the memory <NUM> and run on or in association with the operating system <NUM>. Examples of the application programs include phone dialer programs, e-mail programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, messaging programs, and so forth.

The system <NUM> also includes a non-volatile storage area <NUM> within the memory <NUM>. The non-volatile storage area <NUM> may be used to store persistent information that should not be lost if the system <NUM> is powered down.

The application programs <NUM> may use and store information in the non-volatile storage area <NUM>, such as email or other messages used by an email application, and the like. A synchronization application (not shown) also resides on the system <NUM> and is programmed to interact with a corresponding synchronization application resident on a host computer to keep the information stored in the non-volatile storage area <NUM> synchronized with corresponding information stored at the host computer.

The power supply <NUM> may further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.

The visual indicator <NUM> may be used to provide visual notifications, and/or an audio interface <NUM> may be used for producing audible notifications via an audio transducer (e.g., audio transducer <NUM> illustrated in <FIG>). In the illustrated embodiment, the visual indicator <NUM> is a light emitting diode (LED) and the audio transducer <NUM> may be a speaker. These devices may be directly coupled to the power supply <NUM> so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor <NUM> and other components might shut down for conserving battery power. The LED may be programmed to remain on indefinitely until the individual takes action to indicate the powered-on status of the device.

The audio interface <NUM> is used to provide audible signals to and receive audible signals from the individual (e.g., voice input such as described above). For example, in addition to being coupled to the audio transducer <NUM>, the audio interface <NUM> may also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. In accordance with examples of the present disclosure, the microphone may also serve as an audio sensor to facilitate control of notifications, as will be described below.

The system <NUM> may further include a video interface <NUM> that enables an operation of peripheral device <NUM> (e.g., on-board camera) to record still images, video stream, and the like.

Data/information generated or captured by the mobile computing device <NUM> and stored via the system <NUM> may be stored locally on the mobile computing device <NUM>, as described above, or the data may be stored on any number of storage media that may be accessed by the device via the radio interface layer <NUM> or via a wired connection between the mobile electronic device <NUM> and a separate electronic device associated with the mobile computing device <NUM>, for example, a server computer in a distributed computing network, such as the Internet. Similarly, such data/information may be readily transferred between electronic devices for storage and use according to well-known data/information transfer and storage means, including electronic mail and collaborative data/information sharing systems.

As should be appreciated, <FIG> and <FIG> are described for purposes of illustrating the present methods and systems and is not intended to limit the disclosure to a particular sequence of steps or a particular combination of hardware or software components.

<FIG> illustrates one aspect of the architecture of a system <NUM> for providing virtualization using a plurality of computing devices. The system <NUM> may include a general computing device <NUM> (e.g., personal computer), tablet computing device <NUM>, or mobile computing device <NUM>, as described above. Each of these devices may include a hypervisor <NUM> such as described herein.

In some aspects, each of the general computing device <NUM> (e.g., personal computer), tablet computing device <NUM>, or mobile computing device <NUM> may receive various other types of information or content that is stored by or transmitted from a directory service <NUM>, a web portal <NUM>, mailbox services <NUM>, instant messaging stores <NUM>, or social networking services <NUM>.

In aspects, and as described above, each computing device may have access to a virtual machine data store <NUM> that is provided on a server <NUM>, the cloud or some other remote computing device.

By way of example, the aspects described above may be embodied in a general computing device <NUM>, a tablet computing device <NUM> and/or a mobile computing device <NUM>. Any of these examples of the electronic devices may obtain content from or provide data to the store <NUM>.

As should be appreciated, <FIG> is described for purposes of illustrating the present methods and systems and is not intended to limit the disclosure to a particular sequence of steps or a particular combination of hardware or software components.

<FIG> illustrates an example tablet computing device <NUM> that may execute one or more aspects disclosed herein. In addition, the aspects and functionalities described herein may operate over distributed systems (e.g., cloud-based computing systems), where application functionality, memory, data storage and retrieval and various processing functions may be operated remotely from each other over a distributed computing network, such as the Internet or an intranet. User interfaces and information of various types may be displayed via on-board electronic device displays or via remote display units associated with one or more electronic devices. For example, user interfaces and information of various types may be displayed and interacted with on a wall surface onto which user interfaces and information of various types are projected. Interaction with the multitude of computing systems with which examples of the invention may be practiced include, keystroke entry, touch screen entry, voice or other audio entry, gesture entry where an associated electronic device is equipped with detection (e.g., camera) functionality for capturing and interpreting gestures for controlling the functionality of the electronic device, and the like.

As should be appreciated, the figures herein <FIG> is described for purposes of illustrating the present methods and systems and is not intended to limit the disclosure to a particular sequence of steps or a particular combination of hardware or software components.

The present application describes a method, comprising: initializing a hypervisor; performing a verification operation to ensure the hypervisor was initialized securely; when it is determined that the hypervisor was initialized securely, obtaining one or more platform details; and storing the platform details in a memory device. In some examples, the hypervisor provides two or more execution environments for a virtual machine. In some examples, the verification operation includes providing access to a secret that is stored on a hardware device, wherein the access is provided only when the hypervisor is aware of and is able to prove to hardware that secure instructions were used to launch the hypervisor. In some examples, the secure instructions are stored on a hardware device and are to be executed in a defined sequence. In some examples, the secure instructions are stored in a memory device. In some examples, the hypervisor is initialized before one or more other software components. In some examples, the method also includes providing the verification to a nested hypervisor.

Also described is a method for securely launching a hypervisor, comprising: accessing binary code associated with a hypervisor; validating at least one security credential associated with the binary code, wherein the security credential is specified may a manufacturer of the binary code; and when the binary code has been validated, executing the binary code to launch the hypervisor. In some examples, the binary code does not include a Unified Extensible Firmware Interface code base. In some examples, the method also includes validating one or more hardware components that will execute the binary code. In some examples, the one or more hardware components is a boot processor. In some examples, the method also includes providing access to additional code that is used to launch the hypervisor. In some examples, the additional code is stored in a separate storage location from the binary code. In some examples, the security credential is a signature. In some examples, the method also includes validating that the hypervisor was securely launched.

Also described is a system, comprising: at least one processor; and a memory coupled to the at least one processor and storing instructions that, when executed by the at least one processor, perform a method for validating that a hypervisor has been securely launched, comprising: storing a decryption key in a secure memory location; providing verification that one or more expected measurements have been met during a hypervisor launch process; and when it is determined that the one or more expected measurements have been met, enabling access to the decryption key. In some examples, the measurements are specified by a manufacturer of one or more components of the system. In some examples, the memory also stores instructions for generating a nested hypervisor when it is determined that the one or more expected measurements have been met. In some examples, the secure memory location is a trusted platform module. In some examples, the memory also stores instructions for reinitializing the hypervisor when it is determined that at least one of the one or more measurements have not been met.

Claim 1:
A method for securely launching a hypervisor in a host system, comprising:
accessing (<NUM>) securely stored instructions used for securely launching a hypervisor;
validating (<NUM>) the securely stored instructions based on at least one security credential associated with the securely stored instructions, wherein the security credential is specified by a manufacturer of the securely stored instructions, wherein the security credential is a signature or a certificate;
when the securely stored instructions have been validated, executing (<NUM>) the securely stored instructions to launch the hypervisor;
determining (<NUM>), based on the securely stored instructions, that the hypervisor was securely launched; and
when it is determined that the hypervisor was securely launched, obtaining (<NUM>), by the hypervisor, one or more platform details, and
writing (<NUM>), by the hypervisor, the one or more platform details into memory and/or into a set of registers, so that the hypervisor is permitted to execute various instructions it receives on behalf of the host system.