Parallel

Protecting Critical Applications on Mobile Platforms

P-MAPS is a processor-measured service layer that reduces the trusted computing base and improves the runtime security of user applications

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 [7].

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 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.

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.

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.

Figure 8: P-MAPS Teardown (Source: Intel Corporation, 2009)

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.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!