P-MAPS Memory Services
The P-MAPS core provides memory services for measurement, protection, and eventing. The capabilities of each of these submodules are as follows:
Memory measurement. The P-MAPS core applies memory measurement to identify applications, based on an application integrity manifest. In essence, the application integrity manifest provides a signed list of integrity check values over the contents of the application's code and data. If there are relocation symbols in the application (for example, a dynamically loadable library) then those are captured in the manifest to aid in runtime measurement. The integrity manifest can be created for both executable and linkable format (ELF) and Windows Portable Executable (PE) format applications. The software measurement schemes are described in detail in .
Memory protection. P-MAPS applies Intel VT hardware to virtualize OS page table management. We have implemented OS-independent memory protection by forcing VMexit control events in order to be able to access control registers, invalidate page instruction usage, and page fault exception occurrences. We have designed a shadow page-table partitioning algorithm to gain access control to the application's memory in order to prevent it from being tampered with. Our shadow page-table partitioning approach is called virtualization-enabled integrity services (VIS) and is described in more detail in [8, 9].
The P-MAPS core manages two sets of page tables:
- Active page table (APT). This is the page table created and managed by the P-MAPS core in response to the creation and manipulation of the guest page table (owned and managed by the OS).
- Protected page table (PPT). This is the page table created and managed by the P-MAPS core in response to a registration by a software module running in the guest OS. In response to the registration, the software module is measured as described in the "P-MAPS Memory Services" section of this article, and a PPT is created for the software application such that the rest of the OS code (running via the APT mappings) cannot execute within the address space defined by the PPT. The setup of the PPT is shown in Figure 3. (The interaction between the APT and PPT for protecting a particular application during its execution is described later in the "P-MAPS Steady State: Application Protection" section of this article.)
Memory eventing. The page-based access control system is used to report memory access events to a protected auditing agent that, in turn, may be used to apply policies to application memory accesses or to record events for audit log purposes.
P-MAPS Initialization and Launch
A high-level view of a trusted launch process is shown in Figure 4. Note that in that figure, on the left, the OS is first in host mode, that is, running natively. The OS is then temporarily quiesced when the P-MAPS core loader runs. Finally, the OS is in guest mode, and the applications interact with the P-MAPS core for protection. The pseudo code for the launch is described in detail in this section.
The top-level pseudo code for the P-MAPS core launch is shown in Table 1.
//OS is in "host" mode //current mode of operation of this code is untrusted 1. Disable Interrupts 2. Save Segment Registers 3. Save Stack Pointer 4. Save all GPRs 5. Save EFlags 6. Launch P-MAPS (pseudo code for this step is described in detail in the next section) //Execution should resume at point 7 after launch with //OS in "guest" mode and Active and Protected Page //Tables managed by P-MAPS core. 7. Restore EFlags 8. Restore all GPRs 9. Restore Stack Pointer 10. Restore Segment Registers 11. Restore Interrupts
The P-MAPS loader loads the chipset SINIT ACM together with the P-MAPS core into memory, along with the supporting components. The P-MAPS loader also restores MTRRs that are saved in the os_mle_data (which is a data structure located in the TXT Heap). The os_mle_data used for P-MAPS core operation is shown in Table 2.
OS_MLE_DATA (Data used from OS by P-MAPS loader and core) //os state saved (untrusted) MTRR STATE MSR STATE OS CR3 OS STACK OS RETURN VIRTUAL ADDRESS OS RETURN PHYSICAL ADDRESS OS GDT VIRTUAL ADDRESS OS GDT PHYSICAL ADDRESS OS TSS VIRTUAL ADDRESS OS TSS PHYSICAL ADDRESS //p-maps setup POST-SENTER PAGE TABLE MEMORY (scrubbed before use) P-MAPS CORE ENTRY PAGE PHYSICAL (measured code) P-MAPS CORE ENTRY PAGE VIRTUAL (retained from OS) P-MAPS GDT (measured data) P-MAPS STACK PHYSICAL BASE (retained from OS) P-MAPS STACK VIRTUAL BASE (retained from OS) P-MAPS CORE PHYSICAL BASE (scrubbed before use) P-MAPS CORE EXIT PAGE PHYSICAL (measured code) P-MAPS CORE EXIT PAGE VIRTUAL (retained from OS)
The memory allocated via OS services is not trusted. The P-MAPS loader allocates additional memory to stage the launch of the P-MAPS core. This includes memory for the following elements:
- MLE page table. Used by the processor to map the memory elements that will be measured by the GETSEC[SENTER] instruction.
- MLE header. Holds the P-MAPS code entry-point linear address (as interpreted by the MLE page table). After measurement of the P-MAPS core, the ACM transfers control into this entry-point, in protected non-paged mode.
- Post-SENTER trampoline code and data. This code is measured as part of the MLE and is responsible for switching to the measured global descriptor table (GDT), restoring the memory type range registers (MTRRs), and setting up the post-SENTER page table.
- Post-SENTER page table. The P-MAPS core is relocated in memory to execute from an identity memory map that is created via the post-SENTER page table. This page table is created by the measured relocator code. The mapped memory area is pre-allocated by the P-MAPS loader and is passed in the os_mle_data.
- Post-SENTER GDT. This GDT is used in the post-SENTER trampoline code. The GDT is prepared and measured in memory as part of the launch measurement performed by the processor.
- Post-SENTER relocator code. This (measured) code scrubs the memory into which it relocates the P-MAPS core. The base address of the P-MAPS core is passed to this relocator via the os_mle_data. This code library is pre-compiled at a well-known (static) virtual address base. The post- SENTER code that creates the post-SENTER page table maps this code at the well-known virtual address.
- Un-relocated P-MAPS core. This measured code is the P-MAPS core that is relocated and executed in VMX root mode to provide the application protection service.
- Pre-allocated memory. The memory for the P-MAPS core, the P-MAPS coremanaged heap, and the P-MAPS stack are all pre-allocated and are cleared by the trusted P-MAPS loader before usage.
The P-MAPS core (MLE) memory layout is shown in Figure 5.
The Launch P-MAPS step is described in more detail in Table 3. At launch time, the system is considered to be untrusted.
//current mode of operation is untrusted. 1. Allocate memory to stage P-MAPS for measurement. 2. Load chipset SINIT ACM. 3. Load P-MAPS (unrelocated) core binary image. 4. Create MLE page table that maps part of P-MAPS loader and P-MAPS core that is to be measured and compared against platform launch control policy (LCP). 5. Issue processor instruction GETSEC[SENTER].//the above instruction causes the processor to verify the ACM, which then verifies the //P-MAPS loader and unrelocated P-MAPS core against the LCP in the TPM //control resumes at item 6 after GETSEC[SENTER] in protected non-paging mode //following operations are trusted (that is, measured)6. 6. P-MAPS loader loads measured GDT. 7. Clear TXT error and status registers. 8. Restore MTRRs from state saved in os_mle_data (located on the TXT Heap). 9. Create post-SENTER page table that will be used to enter P-MAPS core. (Note: paging is not turned on yet). The mapping createdin this page table is described in detail below. 10. Switch to post-SENTER page table. 11. Establish stack from (scrubbed) allocated memory. 12. Invoke relocator module to relocate measured P-MAPS core to scrubbed memory (allocated and passed via os_mle_data). 13. Push data needed for OS resume on stack. This includes the OS's original CR3, stack, and return EIP. These data are retrieved from the os_mle_data in the TXT Heap. 14. Push reference to P-MAPS handoff structure in memory on stack (P-MAPS handoff memory mapped in Step 9). 15. Invoke P-MAPS core entry. The P-MAPS core initialization is described in Figure 7(a).//After Step 15, the P-MAPS core activates VMX and transitions //the "host" OS into a "guest" configuration OS. //Execution resumes at Step 16 (with any error information in GPRs). If successful, the CR3 used //by the guest references an active page table managed by the P-MAPS core.16. 16. Check GPRs for any error information. 17. If no error, restore OS resume data from stack. 18. Switch to OS guest CR3. Note that this action now causes a VMexit that is handled by the P-MAPS core that creates an active page table corresponding to the guest page table used by the OS. This APT ensures that the OS mapping cannot tamper with any of the P-MAPS core memory. The P-MAPS core memory includes the active and protected page tables. 19. Jump to the OS return EIP (virtual address mapped in guest page table, and therefore in active page table).
The sequence of operations for the creation of the post-SENTER page table is shown in Table 4.
1. Map (measured) entry trampoline pages as an identity and an OS-mirrored virtual address range. 2. Map (measured) relocator module pages to static (well-known) virtual address. 3. Map (measured) unrelocated P-MAPS core (identity mapped). 4. Map (scrubbed) P-MAPS core stack pages (identity mapped). 5. Map OS GDT and IDT. These are used only for creating the guest VMCS. The P-MAPS core uses its own (memory protected) GDT and IDT. 6. Map OS TSS. These are used only for creating the guest VMCS. 7. Map (measured) exit trampoline pages as an identity and an OS-mirrored virtual address range. 8. Map (scrubbed) memory where P-MAPS core is relocated into (identity mapped).
P-MAPS Steady State: Application Protection
Once the P-MAPS core is in place (shown by the P-MAPS steady state in Figure 6), applications can register with it for protection. The registration interface is implemented via a parameterized VMCALL into the P-MAPS core, where VMCALL is an Intel VT instruction. The initial registration received by the P-MAPS core is untrusted. The P-MAPS core verifies the measurement of the runtime memory state of the application, based on the integrity manifest provided by the application. Once the application memory passes the measurement checks, the P-MAPS core creates a PPT for the application. All page tables managed by the P-MAPS core are in the P-MAPS heap, which is allowed to be mapped in any APT or PPT created for OS execution.
The pages for the application that are successfully measured are isolated by the P-MAPS core into a PPT. The protected application may allocate new memory that can be inserted by the P-MAPS core into the PPT after scrubbing. When the protected application is executed, it is not necessary to mask interrupts or interfere with OS operation of other unprotected or unknown applications. If an interrupt occurs, the OS interrupt service routine execution causes the execution to fault into the P-MAPS core; the P-MAPS core verifies if a protected application was executing (via a PPT), and if so, transfers control to the active page table to let the (unprotected) OS interrupt service routine complete. Additionally, the P-MAPS core records the interrupt point of the application so that it can verify that it is being resumed from the correct point.
Further, paging of the application pages is not affected; any access to P-MAPS protected pages from the OS is considered equivalent to an attack, so the affected pages are subjected to an integrity check (in the P-MAPS fault routine), and they are un-linked from the PPT. When the page is swapped back in, and code from the protected code page is executed, the fault is internal to the PPT, and the P-MAPS core verifies the integrity check value on the page contents before linking the page to the PPT. This allows the OS operation to continue unhindered but does not affect the security of the protected application.
The P-MAPS core allows the following policies to be enforced for a protected application:
- Code pages cannot be written.
- Code or data pages may be entirely hidden.
- Data pages may be read/write or hidden.
- Specific data pages may be shared between trusted and untrusted code.
- The code page can be executed only from specific entry points.
The events handled by the P-MAPS core for memory management of the protected application are best shown in flowcharts shown in Figure 7(a) and 7(b).
The P-MAPS teardown is achieved as shown in Figure 8. Before issuing a VMXOFF VT instruction that exits VM root mode, the P-MAPS core ensures that there are no more applications being protected by P-MAPS and that the teardown request arrived from the protected service that launched the P-MAPS core.
If these conditions are satisfied, the P-MAPS core scrubs any secrets that were held in protected memory, caps TPM PCRs, issues a VMXOFF to relinquish Intel VT hardware control, and issues a GETSEC[SEXIT] to exit trusted mode (to allow a subsequent measured launch to take place). The P-MAPS core transfers control back into the untrusted portion of the P-MAPS loader, which in turn de-allocates the P-MAPS memory (if required). The P-MAPS loader may also keep the memory allocated until system shutdown to allow subsequent launches, if such an action is required. As shown in Figure 8, the OS resumes in host mode after P-MAPS teardown.