At a high level, the two stable states of the platform, when using P-MAPS, are shown in Figure 1. The platform starts with a commodity OS (currently the host) running on hardware, as shown in state A in Figure 1. P-MAPS is instantiated via user launch of an application that requires P-MAPS services. The resulting state of the platform is as shown in state B in Figure 1: only the P-MAPS core, the CPU, the verified chipset, and BIOS are in the TCB. Note that the OS is running in guest mode.
In the rest of this section we describe how the architecture of P-MAPS achieves the smaller TCB, shown in state B, as well as how the application is added to this TCB at runtime. The primary contribution of our research is on-demand reduction of the TCB to one or more independently protected applications that execute without interrupting the operation of other unprotected applications or services executing on a commodity OS.
Intel TXT is a set of CPU and platform extensions that provide a measured and controlled launch of system software that can then establish a protected environment for the system software and any additional software that it may execute. The Intel TXT use of the term "trusted" denotes a successful measurement of the provided software module to a reference measurement that is protected by a hardware trusted platform module (TPM) and is pre-provisioned on the platform. The software environment that is measured and launched is called the measured launch environment (MLE). MLEs may be system software, such as an OS kernel or a virtual machine monitor (VMM). MLEs can use different launch mechanisms and therefore use different types of measurement schemes. One measurement is made when the platform boots, by using a root of trust for measurement (RTM) that executes on each platform reset; the RTM creates a chain of trust that extends from platform reset to the measured environment. As the measurement always executes at platform reset, this type of RTM is called a static RTM (SRTM). Maintaining a chain of trust for a length of time may be challenging for an MLE that operates in an environment that is, under normal operation, exposed to unknown software entities, such as device drivers. P-MAPS relies on a small, static code base and runs the OS in a de-privileged mode. Running an MLE, an extra layer of code on power-sensitive platforms, incurs extra overhead and therefore is not a desirable means of addressing this issue. Intel TXT provides another RTM called a dynamic root of trust for measurement (D-RTM), also called a "late launch". Using D-RTM, the launch of the measured environment can occur at any time without a platform reset. An Intel-signed, chipset-verified code module (known as an authenticated code module or ACM) is used to verify the state of the CPU and chipset, to ensure a secure state of the platform when an attempt is made to launch the MLE. It is therefore possible to launch an MLE, execute it for some time, terminate the MLE, and then launch the same or a different MLE again. An Intel TXT chipset and a Trusted Computing Group standards-based TPM (available from various vendors) are required to ensure correct operation of the D-RTM model. The chipset, enabled with Intel TXT, implements TXT Heap memory, which is a region of physically contiguous memory set aside by BIOS for the use of Intel TXT hardware and software. The software that launches the MLE passes data to the SINIT ACM and to the MLE by using the Intel TXT Heap memory. This heap region allows for secure handoffs to occur between the BIOS and the OS, between the OS and the SINIT ACM, between the SINIT ACM and the MLE, and finally between the OS and the MLE. The structure of the data passed between the OS and the MLE is system software specific. We shall describe the format used for P-MAPS later in this article. The other protection aspect of the Intel TXT chipset comes from DMA devices via Intel Virtualization Technology (Intel VT) for Directed I/O (Intel VT-d). The key aspects of the TPM used by Intel TXT are also described later on in this article.
The trusted platform module (TPM)  provides the hardware root of trust for storage (RTS) and the D-RTM. The TPM contains the following capabilities that allow secure MLE measurement and recording of the MLE measurement:
Locality of access. TPM localities are essentially access levels that can be mapped to the privilege level of the software or hardware entity by using the TPM. Localities can also be used in access control lists for objects managed by the TPM. For example, trusted software, such as the MLE, is assigned a higher locality than untrusted software, whereas hardware is assigned a higher locality than the MLE (which is measured by the hardware). P-MAPS uses TPM Locality 2 to associate operations with the P-MAPS core. This binding is used for remote attestation of the applications protected by the P-MAPS. This operation is described in detail later in this article.
Platform configuration registers (PCR). PCRs are registers maintained in the TPM hardware that capture the software state of the system. The TPM exposes an extend operation on PCRs, which is an order-sensitive, one-way cryptographic hash operation. Additionally PCR state can be quoted via the TPM (that is, signed by the TPM with a key that is only known to the TPM) such that the PCR quotes can be verified by a remote verifier that can then attest to the software state of the system. Intel TXT uses PCR 17 and PCR 18, where PCR 17 holds the hash of the ACM (along with other static fields, explained in the MLE Writers Guide , section 1.9.1), and PCR 18 holds the hash of the MLE.
Endorsement key. The endorsement key is the root key pair provisioned in the TPM. It can be used to identify the TPM as a hardware TPM and also to derive additional key-pairs that can be used for attestation operations.
Storage root key. The TPM has a separate storage root key to protect its local non-volatile memory. This key can be used to seal (and subsequently unseal) data to the platform and the platform's software state (via TPM PCRs). P-MAPS uses the root key to bind data to the integrity of the application it is protecting.
Launch control policy (LCP). LCP is a local verification mechanism that is used to ensure that the MLE to be launched meets specific measurement criteria. The measurement criteria, or policy, may be defined by the platform owner, or as a default set by the platform supplier. LCP is enforced by the chipset ACM and the policies are stored in the TPM. A simple policy is a list of valid MLEs. When the ACM is executed (via the GETSEC[SENTER] CPU instruction), the LCP engine in the ACM reads the LCP from the TPM and compares the measurement of the MLE whose launch is being requested against the platform policy. If the policy matches, the measured environment is then launched.
Intel VT-x provides hardware support to virtualize the CPU and it allows a VMM to configure the events that transfer control to the VMM, via a VMexit control field. This capability is used by the P-MAPS core to virtualize the CPU translation look-aside buffer (TLB), which caches the virtual-to-physical address mappings. The VMM can use the Intel VT-x hardware capability to selectively transfer control to the VMM, when the OS performs memory management operations such as loading control registers, flushing the TLB (invlpg/invd), as well as page fault exceptions. Please refer to Intel software developers' manuals  for more information on Intel VT and Intel TXT.
The P-MAPS module consists of the OS-specific P-MAPS loader and an OS-independent P-MAPS core (Figure 2). The P-MAPS loader uses the Intel TXT dynamic launch capability to authenticate and bootstrap the P-MAPS core (the MLE). The P-MAPS core then uses Intel VT to extend the protected environment that the P-MAPS MLE executes within. Thus, the P-MAPS core executes in the highest privilege mode (VMX root mode), which ensures hardware separation between the protected (target) applications and itself. The P-MAPS core provides three local properties for the application it protects. The P-MAPS core:
- Isolates the program's memory from other software executing on the platform, even software with a higher privilege level, such as the OS;
- Ensures encapsulation of application data memory such that only code in measured application pages can access application data; and
- Prevents circumvention of any function entry points exposed by an application (such as a shared library).
The runtime protection for the application is important not just for the three local properties just listed, but also because it must be able to attest to the protection state of the application to a remote verifier. Intel TXT uses the TPM that provides us with the necessary storage and reporting mechanisms to ensure that the P-MAPS core that is loaded, is the one that was provisioned by the platform owner into the TPM LCP (that is, the whitelist of MLEs). Additionally, the hardware platform must ensure that virtualization is turned on only when virtualization is used after a successful measured launch. Moreover, the hardware platform ensures that the P-MAPS core is measured and verified before it can enable Intel VT. By building the P-MAPS core to be run on-demand for protection of applications, we can leverage this approach on power-sensitive devices. The additional power used to run P-MAPS is not consumed until the application protection is needed.