func-112 The Intel Safer Computing Initiative
tionality claims of the VMM. Fewer claims and services provide develop-ers of the VMM with an opportunity to make fewer mistakes in design and implementation.
VMM with Kernel Features
The guest must have knowledge of the VMM when the VMM provides kernel features. The VMM determines the mechanism that exposes the service to the guest. Of the many types of communication mechanisms available, the VMM may use one or more to expose VMM services.
With the VMM providing services, the ability to create special pur-pose guests is possible. Using the services of the VMM, the guest can concentrate on a single purpose. The LT architecture does not require a single-purpose guest; it merely allows one. The VMM service of providing communication between guests now becomes a much more important service. Since a single-purpose guest only does one job, other guests are going to require the service that the single-purpose guest provides. While some services might have a low bandwidth, the assumption is that many guests have high bandwidth requirements. Hence, the communication between the guests and the VMM are critical.
The VMM is free to provide any service that the VMM developer wishes to expose. The VMM may provide services to only one guest and no other guest; the mix, content, and availability of services is a design decision for the VMM designer and implementer.
Chapter 7: Protected Execution 113
■ The VMM wishes to masquerade as some other entity.
■ Some attack corrupted the VMM and the attacker wants to hide.
In a world with VMMs that do and do not lie how does one tell them apart? The answer is the identity of the VMM. The VMM is just normal software with a special job to do. Creating an identity of the VMM is as simple as computing a cryptographic hash of the code. Cryptographic hashes—and from now on hash means cryptographic hash—have very interesting properties.
The interesting property that is most important to the VMM identity is: a change in a single bit of the VMM code causes a major change in the resulting hash value. One cannot change a single instruction without changing the hash value, which is an excellent property for identifying a VMM. The bottom line is that any change to the code means that the VMM has a new identity.
Hashes are very accurate in reporting the identity of the information presented to the hash. The issue is what entity sends the information to the hash algorithm. Asking an entity to measure itself does not work since that entity can present false information to the hash algorithm if it wants to lie. Some other mechanism, one not under control of the entity to identify, must present the information to the hash algorithm.
In the LT case, the entity to identify is the VMM, but the VMM has complete control of the CPU. Some hardware that is not under control of the VMM must measure the VMM. Measurement of the VMM occurs prior to giving the VMM control of the CPU. LT provides a hardware mecha-nism, in use during the invocation of the VMM, which properly runs the VMM image, or binary, through a hash algorithm.
With the measurement made, and the VMM identity in storage, the VMM is now a Measured VMM (MVMM).
Measuring the VMM
To have an assurance of the proper calculation of the VMM identity, or the measurement process, the measurement and launch of the VMM must meet the following requirements:
■ All measurement and storage of the measurement must occur prior to passing control to the VMM.
■ The measurement process must occur in a manner that defends against spoofing of the measurement.
114 The Intel Safer Computing Initiative
■ The launch process must ensure that all processors run the same VMM.
■ The launch process must ensure that all processors start at a known entry point.
■ The VMM must complete VMM initialization prior to allowing any other entity to execute.
■ No other bus masters, processors, devices, or cache snooping can subvert the VMM measurement and or VMM launch.
■ No misconfiguration or misrepresentation of processor, chipset, or platform state must be able to subvert the launch.
Launching the VMM
When booting the platform, the BIOS performs the job of configuring the platform. The BIOS runs once and then allows the OS to manage the plat-form. With a MVMM, a user might want to run one MVMM for one task and then another MVMM for another task. If the process of measuring and launching the MVMM only occurs at once per boot, then to change MVMM, the user would have to reboot the platform, an undesirable user experience. To avoid this situation LT provides for a “late launch” of the MVMM. Late launch means that the measurement and launch of the MVMM can occur at any time after platform reboot. In addition, LT con-tains a provision to exit from the MVMM and allow another MVMM to launch. A launch of a MVMM can occur at any time, during BIOS process-ing, or during OS execution. The number of MVMMs that can launch and exit is no unlimited. The time between invocations of an MVMM is unlim-ited, too. The interesting fact is that events occurring prior to the MVMM launch do not affect the launch. For instance, the launch could be the first time since boot that a MVMM launches or it could be the hundredth launch of a MVMM; it does not matter.
Prior to the launch, the launching entity locates and loads into mem-ory two code modules. One module is the VMM that the launch process measures. The other module verifies certain system configurations to en-sure that the hardware operates in a manner that allows the VMM to pro-tect system resources. The chipset’s specific Authenticated Code (AC) module has a digital signature from the chipset manufacturer, and it exe-cutes only if the launch process can verify the digital signature.
The GETSEC [SENTER] instruction starts the measurement–and–
launch sequence. The instruction broadcasts a message to the chipset
Chapter 7: Protected Execution 115
and all processors. In response to this message, the other processors per-form basic clean-up, signal their readiness to proceed, then wait for a signal to join the VMM.
Once all other processors have signaled ready, the initiating proces-sor continues the process by loading, authenticating and executing the chipset-specific authenticated code module. This module is tests for an acceptable system configuration, enables chipset protections, and builds the initial NoDMA table that covers the MVMM. This module then meas-ures, registers, and launches the MVMM, starting at an initialization entry point.
The MVMM initialization routine completes the system configuration changes, including redirecting INITs, SMIs, interrupts, and others, then issues GETSEC[WAKEUP] messages to the other processors to bring them under control of the MVMM. At this point, all processors and the chipset are correctly configured.