Patent Description:
The article by <NPL>, describes methods for efficient virtualization-based application protection against untrusted operating system.

The article by <NPL>, describes techniques for isolation of software modules running concurrently and sharing resources.

<CIT> describes techniques for providing secure operation, For example, a method comprises receiving an enclave program for operation in an enclave, identifying at least one shared object dependency of the enclave program, determining whether the shared object dependency corresponds to at least one enclave shared object, causing association between the shared object dependency and the enclave shared object in circumstances where the shared object dependency corresponds to the enclave shared object, and causing association between the shared object dependency and an enclave-loadable non-enclave shared object in circumstances where the shared object dependency fails to correspond to the enclave shared object.

In a conventional data processing system, an application may use a so-called "logical address" to access memory. The operating system (OS) may translate that logical address into a linear address. For instance, a running process may use logical addresses, and when instructions in that process request access to memory, the OS may use descriptor tables to translate the logical addresses into linear addresses. A linear address may also be referred to as a virtual address.

Furthermore, the data processing system may include a central processing unit (CPU) with a memory management unit (MMU), and the OS may use that MMU to translate virtual addresses into physical addresses. For instance, the MMU may provide for a page directory for each active process, and one or more page tables for each page directory. In particular, the page tables may include a page table entry (PTE) for each page of virtual memory, to identify the corresponding physical page. In general, the MMU may store the page directory and the page tables in random access memory (RAM), but the MMU may use a translation lookaside buffer (TLB) to cache recently used PTEs. The MMU may also use other hardware resources (e.g., descriptor tables) to service memory access requests. For example, a control register (CR) in the CPU (e.g., CR3) may point to the physical address of the page directory for the current process. When the data processing system allows the OS to access the MMU directly, the page tables referenced above may be referred to as OS page tables.

Unfortunately, an OS may be infected with malware. And if the OS has access to all of the data stored in memory, the OS may wreak all kinds of havoc with the system. For instance, in a rooted kernel, the attacker can compromise the security of the system by modifying the entries in the page table, for instance changing a PTE to point to some malicious code. This kind of change can lead to code injection, and the malware can thereby gain access to critical data.

The present invention tries to overcome these problems and is defined by the subject-matter of the independent claims. Additional features of the present invention are presented in the dependent claims.

For purposes of illustration, the present disclosure describes one or more example embodiments. However, the present teachings are not limited to those particular embodiments.

This detailed description includes the following six parts:.

Those parts are presented below, after the following introductory material.

For a data processing system that supports virtualization, an OS may run in a virtual machine (VM) on top of a virtual machine manager (VMM). An OS that runs in a VM may be referred to as a guest OS, and the underlying VMM may be referred to as the host OS. Different VMMs may use different techniques to prevent the guest OS from having unlimited access to memory. Those techniques may involve a page table managed by the guest to map a guest virtual address (GVA) to a guest physical address. That page table may be referred to as an OS page table or a guest page table. The VMM may then translate the guest physical address (GPA) to a host physical address (HPA).

According to one technique for limiting guest access to memory, a host OS uses a so-called "shadow page table" (SPT) to prevent the guest from changing the PTEs used for address translation. With this technique, the guest maintains one copy of the guest page table (GPT), and the host maintains a second copy of the GPT in a memory region that is hidden from the guest. The second copy is referred to as a shadow page table (SPT). In addition, the host uses the MMU to maintain a page table for translating from GPAs to HPAs. The page table that is managed by the VMM through use of the MMU hardware may also be referred to as hardware page table. The host maintains the SPT by trapping each page fault when the guest tries to access memory. In response to the page fault, the host updates the SPT entry for that page. Subsequently, during address translation, the host uses this SPT instead of the GPT. And since the SPT is maintained in an isolated memory region, it cannot be modified even in an attack from a rooted kernel. Thus, the host may use the SPT to prevent the guest OS from accessing certain physical pages, for example. However, this approach increases the cost of memory access since two address translations need to be performed for each memory access: one by the guest OS, using the shadow page table, and then another by the VMM, using the hardware page table. Also, the cost of trapping each page fault by the VMM to update the SPT may adversely affect system performance.

Conventional trusted execution environment (TEE) solutions may be resource constrained in one or more of the following ways: (<NUM>) They may require a trusted application (TA) in a TEE to be hosted in a separate OS or a real time OS (RTOS). (<NUM>) They may require special hardware support or micro-code extensions in order to facilitate the trusted execution. The technology described by ARM Ltd. under the name or trademark TRUSTZONE has the former requirement, and it requires a special hardware mode. Technology like that described by Intel Corporation under the name or trademark INTEL® SOFTWARE GUARD EXTENSIONS (SGX) may utilize micro-code extensions to support a TEE.

This disclosure introduces a protection model that supports features which may include, without limitation, dynamic memory allocation in the TEE. Some or all of the components which implement this protection model operate below the level of a guest OS. In other words, some or all of the components operate at the platform level. Accordingly, for purposes of this disclosure, the technology introduced herein may be referred to as Platform Protection Technology (PPT). As described in greater detail below, one of the benefits of PPT is the ability to protect some or all of the code and data belonging to certain software modules from user-level (e.g., ring-<NUM>) malware and from kernel-level (e.g., ring-<NUM>) malware. PPT may provide isolation between various trusted entities, along with the ability to allocate, free, and reuse the memory dynamically at runtime. In addition, the PPT memory sharing model may allow memory sharing between TAs and the untrusted OS, in addition to between TAs.

Also, PPT may be managed by the hypervisor, and the guest OS may not have access to shared memory unless explicitly permitted by the hypervisor. Also, PPT may provide for shared memory without copying the data being shared. In addition, a TA can send a request to a PPT hypervisor to determine whether that TA has exclusive or shared rights on a particular memory buffer. PPT may also provide for memory cleanup after the crash or exit of a TA and/or after the crash or exit of the process that created the TA.

PPT may utilize second level address translation (SLAT). For instance, in one embodiment, a data processing system uses extended page table (EPT) technology to implement SLAT. Using EPTs may be more efficient than using SPTs. More details on EPT technology and other options for platform security are provided below.

<FIG> is a block diagram illustrating some components and communication flows for an example embodiment of the PPT architecture. As indicated in the key, trusted components are illustrated in <FIG> with dotted fill. The bottom of <FIG> shows a trusted security engine <NUM> at the level of hardware and firmware. Security engine <NUM> may be used to assist in secure boot using cryptographic and hash operations, for instance. Security engine <NUM> may be used to ensure that the system boots to a trusted computing base (TCB), for example.

The logical level above the hardware and firmware may be referred to as the hypervisor space. A trusted PPT VMM <NUM> may operate in the hypervisor space. PPT VMM <NUM> may also be referred to as PPT hypervisor <NUM>.

The next logical level up may be referred to as the kernel space. An untrusted PPT driver <NUM> may operate in the kernel space. Various interrupt handlers or interrupt service routines (ISRs) may also operate in the kernel space. For instance, PPT driver <NUM> may install a set of trusted ISRs (TISRs) <NUM> to operate in the kernel space. As described in greater detail below, TISRs <NUM> may serve as trampolines to allow execution to be transferred from an untrusted environment to a trusted environment and vice-versa. An untrusted security engine driver <NUM> may also operate in the kernel space. A software application running on a host OS or a guest OS may use security engine driver <NUM> to communicate with security engine <NUM>.

In one embodiment, PPT provides a TEE by keeping only the components that are authenticated by trusted entities, such as hardware manufacturers, original equipment manufacturers (OEMs), or known third party vendors, in the trust control boundary of the data processing system. PPT deliberately keeps the operating system and other system libraries out of the TCB, because rooting the platform may result in installation of a malicious OS or malicious system libraries.

The next logical level up may be referred to as the user space. One or more untrusted applications <NUM> may run in the user space. Untrusted application <NUM> may use one or more sets untrusted libraries in the user space. Those untrusted library sets may include a set of untrusted PPT libraries (UPLs) <NUM>. UPLs <NUM> may include an untrusted PPT loader <NUM>. A set of trusted PPT libraries (TPLs) <NUM> may also be used in the user space. Untrusted application <NUM> may use PPT loader <NUM> and TPLs <NUM> to launch a trusted application (TA) <NUM>. For instance, a developer may write TA <NUM> and statically link it against TPL <NUM>. Launching or starting that combined static application may cause the system to create a TEE <NUM>, with TA <NUM> executing within TEE <NUM>.

Referring again to the kernel space, whenever a TA communicates with security engine <NUM>, the TA encrypts the data and then sends it over the insecure channel of security engine driver <NUM>. For instance, a TA that serves as a platform service TA may use security engine driver <NUM> to write a blob to secure storage managed by security engine <NUM> or to derive a symmetric encryption key for a given TA. Security engine <NUM> has the key to decrypt or encrypt the data being shared with the TA.

For purposes of illustration, this disclosure involves a hypothetical scenario in which untrusted application <NUM> is a banking application and TA <NUM> is a trusted authentication function that is launched and used by that banking application. However, as will be readily apparent to those of ordinary skill in the art, many other kinds of untrusted applications and trusted applications may use PPT.

<FIG> illustrates runtime relationships amongst various components. For example, <FIG> shows that TA <NUM> runs within the context of untrusted application <NUM>. And the double-headed arrows on <FIG> pertain to communications between components at the different levels. For instance, arrow <NUM> shows the transfer of execution from untrusted to trusted environment and vice-versa going via TISRs <NUM> acting as trampolines. Arrow <NUM> shows the hypercall-based communication mechanism used by the untrusted or trusted applications to get service from VMM <NUM>. Arrow <NUM> shows encrypted data flowing between untrusted frameworks via the untrusted security engine driver. Arrow <NUM> shows that security engine driver <NUM> is passing encrypted data to security engine <NUM>.

Arrow <NUM> shows the services provided by VMM <NUM> to PPT driver <NUM>. For example, this kind of communication may occur when PPT driver <NUM> uses VMM <NUM> to create a virtual interrupt descriptor table (IDT). Subsequently, when an interrupt/exception arrives, the processor indexes into the virtual IDT (VIDT) to obtain a pointer to the appropriate ISR among TISRs <NUM>. That TISR may then determine whether (a) the interrupt/exception should be passed to an untrusted ISR (UISR) or (b) it should be handled by the TISR itself. Arrow <NUM> also represents the kind of communications which occur when PPT driver <NUM> registers the trusted ISRs <NUM> with VMM <NUM>, so VMM <NUM> can install these ISRs in trusted memory.

<FIG> is a block diagram illustrating an example embodiment of a data processing system <NUM> that uses PPT to execute and protect one or more TAs <NUM>. Data processing system <NUM> may be implemented as a portable or handheld computing device, such as a smartphone or a tablet, for instance, or as any other suitable type of computing device. For example, in one embodiment, data processing system <NUM> uses a processor <NUM> like those distributed by Intel Corporation under the name or trademark INTEL® ATOM, and data processing system <NUM> uses PPT architecture to run hypervisor <NUM> and to create TEE <NUM>. Data processing system <NUM> may use VMM <NUM> to create isolated memory regions to host code and data belonging to security sensitive portions of an application running in a rich execution environment. VMM <NUM> may support features such as CPU virtualization (including descriptor table exiting) and memory virtualization, including support for EPTs and for virtualization functions or instructions. Those virtualization functions or instructions may include an instruction which enables VMs to use processor functions without exiting into the VMM. Those processor instructions may include an instruction for efficiently switching between the untrusted environment (or world) and the trusted world. In one embodiment, such an instruction may be referred to as a VMFUNC instruction, and that instruction may use the processor functionality of switching the EPTs (and thus transitioning between untrusted and trusted worlds) without causing a VMEXIT (i.e., without switching from the guest to the VMM world). Avoiding VMEXITS helps reduce or eliminate the cost of switching across untrusted and trusted worlds.

In the embodiment of <FIG>, data processing system <NUM> includes at least one processor <NUM> in communication with various hardware components, such as RAM <NUM>, mass storage <NUM>, and security hardware <NUM>. In one embodiment, all of those components may be implemented as a system-on-a-chip (SOC). In other embodiments, multiple different chips or other components may be used. For instance, mass storage <NUM> may be implemented using any suitable storage technology or combination of storage technologies, including without limitation a hard disk drive (HDD), a solid state drive (SSD), read-only memory (ROM), and/or other types of non-volatile or volatile storage technologies. In one embodiment, processor <NUM> represents one processing core, and security hardware <NUM> is part of a different processing core, with security firmware <NUM> residing on storage that is either embedded on that same core or linked to that core. Security engine <NUM> (from <FIG>) may be implemented with hardware and related firmware, such as security hardware <NUM> and security firmware <NUM>. Processor <NUM> may include various control registers (CRs) <NUM>, such as CR3.

Mass storage <NUM> includes various sets of instructions that may be loaded into RAM <NUM> and executed by processor <NUM>. Those sets of instructions may include software such as PPT VMM <NUM>, a guest OS <NUM>, untrusted application <NUM> with associated UPLs <NUM>, and TA <NUM> with associated TPLs <NUM>. And unlike <FIG>, which focuses more on the runtime relationships between certain components, <FIG> depicts the logical separation of software components, data structures, and such. For instance, <FIG> shows that components such as TA <NUM> and untrusted application <NUM> are logically distinct from guest OS <NUM>.

As shown, guest OS <NUM> may include an OS page table <NUM>, which may also be referred to as guest page table (GPT) <NUM>. In one embodiment, guest OS <NUM> may be an image of an OS distributed by Google Inc. under the name or trademark ANDROID. Other embodiments may use different OSs. OS <NUM> may also include an IDT <NUM> and associated ISRs <NUM>, as well as other components, such as PPT driver <NUM> and security engine driver <NUM>. VMM <NUM> may allow guest OS <NUM> to update that IDT and those ISRs. Accordingly, IDT <NUM> may be referred to as an untrusted IDT (UIDT <NUM>), and ISRs <NUM> may be referred to as untrusted ISRs (UISRs) <NUM>.

In addition, VMM <NUM> may create a trusted kernel context (TKC) <NUM> within the context of guest OS <NUM>. VMM <NUM> may also install a VIDT <NUM> and associated TISRs <NUM> into guest OS <NUM>. When installing VIDT <NUM>, VMM <NUM> may also update a register in CRs <NUM> to point to VIDT <NUM> instead of UIDT <NUM>. And when installing TISRs <NUM>, VMM <NUM> may load them into TKC <NUM>. VMM <NUM> may subsequently prevent guest OS <NUM> from modifying that register and from modifying the contents of TKC <NUM>.

In the embodiment of <FIG>, guest OS <NUM> operates within a virtual machine (VM) <NUM> that is created and managed by VMM <NUM>. In addition, untrusted application <NUM> and TA <NUM> both run on top of guest OS <NUM>, within that same VM <NUM>. However, PPT enforces memory isolation between the trusted components and the untrusted components.

In addition, VMM <NUM> may load an asserted page table (APT) <NUM> into TKC <NUM>. More details about APTs are provided below with regard to <FIG>.

PPT may include unique memory management techniques in the TEE for dynamic memory allocation, shared memory, and garbage collection. PPT may provide these benefits without requiring the TA to be hosted in a separate OS or in an RTOS, and without requiring special hardware support or micro-code extensions.

PPT may provide a TEE that isolates portions (or all) of the code and data belonging to a third party application from the main execution environment, thereby enabling that third party application to operate as a TA. In particular, VMM <NUM> may use an EPT to provide a trusted view of code and data for that TA, while preventing untrusted applications from accessing that code and data. For instance, VMM <NUM> may use a different EPT for the untrusted applications, with that EPT providing an untrusted view of memory that does not include the memory in the trusted view. The memory in the trusted view may therefore be referred to as an isolated memory region.

In one embodiment, PPT uses hardware-assisted virtualization technology (VT), such as the technology distributed by Intel Corporation under the name or trademark INTEL® VT, to establish a trust boundary. PPT configures VMM <NUM> in a protected memory region. In particular, that protected memory region is inaccessible to OS <NUM> and to the other devices in the system. PPT VMM <NUM> hosts the memory for the code and data of TAs. In particular, VMM <NUM> uses EPTs <NUM> to protect the TAs, where the memory for each TA is mapped only in one EPT. Any unauthorized attempt to access a TA's memory results in an EPT violation, thereby assuring that only secure and authorized access to a TA's code and data is permitted. VMM <NUM> thus uses EPTs <NUM> to provide a trusted view of memory for each TA.

The TA itself is executed via the standard OS scheduler, resulting in no changes to the existing execution model and without the need for an RTOS. In other words, PPT does not require additional VMs. The VM with the untrusted runtime system (URTS) and the guest OS is the only VM running on top of the PPT VMM. The URTS and the guest OS may be referred to collectively as the rich execution environment (REE). The URTS may also be referred to as the untrusted framework. In one embodiment, one EPT is used to provide a trusted view for each TA, and another EPT is used to provide an untrusted view for the REE.

As described in greater detail below, PPT may also offer OS-agnostic memory management - including dynamic (heap based) memory allocation and cleanup after the execution of a TA under all circumstances, including unexpected TA crashes and the hosting service termination.

As indicated above, VMM <NUM> uses EPTs <NUM> to provide trusted views of memory and untrusted views. In particular, the example scenario depicted in <FIG> involves one untrusted application <NUM> and one TA <NUM>. Accordingly, the example scenario involves two EPTs <NUM> - one EPT for untrusted application <NUM> and its associated untrusted environment (including, e.g., OS <NUM>), and another EPT for TA <NUM>. The untrusted environment could also include multiple untrusted applications, and VMM <NUM> could use the same EPT for all of those untrusted applications. However, if multiple TAs were to be launched, VMM <NUM> would use a different EPT for each TA. Accordingly, the EPT for the untrusted environment provides an untrusted view of memory, and the EPT for TA <NUM> provides a trusted view.

In other words, an EPT is like a lens into memory, and the region of memory that can be accessed via an EPT constitutes a view. Similarly, a view may be thought of as a container, and this container may host or contain code and data. For instance, the view for TA <NUM> may contain the code and data for TA <NUM>.

If an EPT has been created for a TA, that EPT may be referred to as a trusted EPT; and the view it provides may be referred to as a trusted view. Similarly, if an EPT has been created for the untrusted environment (which includes the guest OS and any untrusted applications running on that OS) that EPT may be referred to as an untrusted EPT, and the view it provides may be referred to as an untrusted view. For purposes of this disclosure, an untrusted view may also be referred to as view <NUM>, and a trusted view may be referred to as view <NUM>.

Each view runs with a unique EPT, thereby providing isolation from all other views. In other words, VMM <NUM> uses a unique EPT for each different view, so the software that runs in a given view is prevented from accessing the memory outside of that view.

The example scenario also involves one GPT <NUM>, for untrusted application <NUM>. As described in greater detail below, TA <NUM> does not use a GPT; instead, it uses one APT <NUM>.

<FIG> is a flow diagram that illustrates how GVAs are translated into host physical pages, according to an example embodiment. For instance, <FIG> illustrates that guest OS <NUM> uses GVAs and GPT <NUM> to determine guest physical pages, such as a guest physical page A and a guest physical page B. In addition, <FIG> illustrates that VMM <NUM> uses EPTs to translate guest physical pages A and B into host physical pages A and B, respectively. Furthermore, <FIG> illustrates that different views may provide for different types of access for the same GVA. For instance, <FIG> illustrates how memory view <NUM> provides for read-only (R _ _) access to the host physical pages, while memory view <NUM> provides for read-and-execute access (R _ X) to the host physical pages.

Referring again to <FIG> and <FIG>, PPT driver <NUM> manages multiple tasks, including setting up and managing VIDT <NUM> and hosting the ISRs for certain interrupts, such as interrupts <NUM>, <NUM>, and <NUM>, for instance. In one embodiment, the ISR for interrupt <NUM> (Int-<NUM>) causes the currently executing process to transition from the untrusted code execution to a trusted view. The ISR for interrupt <NUM> (Int-<NUM>) causes execution control to transfer from the trusted view to the untrusted. The ISR for interrupt <NUM> (Int-<NUM>) causes the current process to resume a trusted view after having been interrupted by an asynchronous interrupt.

For purposes is this disclosure, interrupts which serve the purposes discussed above with regard to interrupts <NUM>-<NUM> may be referred to as a TA-enter interrupt, a TA-resume interrupt, , and a TA-exit interrupt, respectively. In addition, those interrupts may be referred to in general as PPT interrupts. Similarly, the corresponding TISRs may be referred to as a TA-enter ISR, a TA-resume ISR, and a TA-exit ISR, respectively, and more generally as PPT ISRs. In other embodiments, other interrupt numbers may be used as PPT interrupts.

Running at a higher privilege than guest OS <NUM>, VMM <NUM> provides the required isolation of the code and data in a trusted view from rest of the views, including view <NUM> (i.e., the untrusted view). VMM <NUM> implements the multi-view model and manages the EPT pointers <NUM> for each view.

User applications and other OS-based software communicate with hypervisor <NUM> through hypercalls, which may be implemented either through cpuid or vmcalls.

In the example embodiment, VMM <NUM> executes at a higher privilege as it runs in the root mode as supported by the virtualization technology distributed by Intel Corporation under the name of trademark INTEL® VT or INTEL® VT-X. That virtualization technology may use virtual machine extensions (VMX) to provide for entry into the root mode. Accordingly, the root mode may be referred to as VMX root mode. In other embodiments, other technologies may be used to provide for similar functionality.

Also, VMM <NUM> manages EPTs to protect the memory that has been allocated from the memory space that is managed by VMM <NUM>, thereby providing for isolation of guest-accessible physical memory. Each memory view is managed by the hypervisor using a separate EPT hierarchy. As indicated above with regard to <FIG>, each EPT maps guest physical memory pages with appropriate read/write/execute permissions to the physical memory pages that guest OS <NUM> utilizes. VMM <NUM> may perform the processor page walk that translates the guest virtual address to the eventual host physical page in a nested manner.

In one embodiment, all trusted views constitute memory that has been allocated from the VMM heap and all untrusted views constitute memory with the same host physical address as the guest physical address allocated by the OS. For instance, an untrusted EPT may specify that GPA equals HPA, which practically means that guest owns the memory that is attempting to access. However, other embodiments may use other approaches. For instance, in other embodiments, the VMM may not allocate new host physical memory from its heap for trusted views, but may instead only change the permissions in the EPT.

Once one or more trusted views are constructed, the control to execution from trusted to untrusted view goes through the TISRs <NUM>.

In one embodiment, an EPT defines a view by specifying access rights and a mapping from guest physicals pages to host physical pages. However, which application can access the view is controlled by a combination of TISRs <NUM> and VMM <NUM>. For instance, a TISR in one embodiment may allow only the application that created the view to use that view. In another embodiment, that restriction can be relaxed by using a different TISR.

Also, as indicated above, in one embodiment VMM <NUM> runs in VMX root mode only. When VMX root mode is active, the EPTs are not active. The memory used by VMM <NUM> for its own code and data is not visible in either trusted or untrusted EPTs mappings, and thus it remains protected from the guest world. However, when data processing system <NUM> is running in guest mode (i.e., non VMX root mode), one of the EPTs will be used, to provide for memory protection.

TA <NUM> may allocate memory dynamically.

<FIG> is a flow diagram that illustrates an example overall flow for dynamic memory allocation by TA <NUM>, after untrusted application <NUM> has launched TA <NUM>. The flow of <FIG> starts with TA <NUM> executing with a trusted view of memory. In other words, VMM <NUM> is using a trusted EPT among EPTs <NUM> to provide a trusted view of memory for TA <NUM>.

TA <NUM> may then use a trusted memory allocation instruction or function (e.g., malloc). TA <NUM> may call the trusted allocate function from a trusted side C library (e.g., tlibc) among the TPLs <NUM>, for instance. The trusted allocate function may use an out-call (oCall) function, and the oCall function may temporarily exit from the trusted view to an untrusted view for the actual system call for memory allocation aligned on page size. The oCall function may use an untrusted allocate function (e.g., PPT-malloc) from UPLs <NUM> to perform the memory allocation operation, always on page boundaries. The allocate function from UPLs <NUM> may then make a hypercall to VMM <NUM>, to instruct VMM <NUM> to give exclusive access to the newly allocated memory to the trusted view originally used by TA <NUM>.

VMM <NUM> may then make sure that the caller (i.e., the allocate function from UPLs <NUM>) has update (e.g., read-and-write or "RW") access, based on OS page table mappings. For instance, VMM <NUM> may walk GPT <NUM> to get the access permissions, page by page, for the range of virtual addresses that were just allocated. In other words, VMM <NUM> may determine whether GPT <NUM> provides the hosting process (which is running in an untrusted view) with RW access. For purposes of <FIG>, the hosting process includes UPLs <NUM> and any other software executing within the view for the untrusted environment.

If the hosting process in the untrusted view does not have RW access, VMM <NUM> may fail the hypercall by returning an error in the return status. However, if the hosting process running has RW access, VMM <NUM> may update the trusted EPT among EPTs <NUM> for TA <NUM> with the requested permissions, after ensuring that the requested permissions do not give "execute" permissions on that memory. VMM <NUM> may thus dynamically adjust the view for TA <NUM> to include the allocated memory.

If TA <NUM> has requested exclusive access to the requested memory, the hypercall will convey that need/parameter to VMM <NUM>. And to give TA <NUM> exclusive access, VMM <NUM> allocates protected memory from its heap and maps that memory in the EPT for the trusted view for TA <NUM>.

On return from the PPT-malloc function in UPLs <NUM> to the trusted allocate function in TPLs <NUM>, PPT-malloc returns the address of the allocated memory buffer or region. As indicted below, the trusted allocate function may subsequently return that memory pointer to TA <NUM>. Thus, virtual address allocation is happening in the untrusted environment, and VMM <NUM> is mapping a new physical region identified by HPAs to that same virtual address range.

After PPT-malloc has returned the memory pointer to the trusted allocate function, the trusted allocate function may then ensure that memory buffer access rights are exclusive to TA <NUM>.

<FIG> is a flow diagram that illustrates an example process for checking access rights. As illustrated, TA <NUM> can use TPLs <NUM> to pass a memory address and size to VMM <NUM> with a rights inquiry. In response, VMM <NUM> may indicate whether TA <NUM> has exclusive rights or shared rights over the specified memory range. Also, the memory range can be of any type (e.g., malloc'ed memory, stack memory, or shared memory.

Referring again to <FIG>, TLPs <NUM> may then initialize the allocated memory before giving the pointer back to TA <NUM>. Alternatively, TLPs <NUM> may skip the initialization step, for instance if VMM <NUM> has copied data from untrusted guest memory to memory allocated by VMM <NUM>. Also, in other embodiments or scenarios, the hypercall to give exclusive TA access to memory may be called from contexts other than the malloc context.

As can be seen from <FIG>, PPT ensures that TA <NUM> gets growing heap as per the runtime requirements. More importantly, this is done in a secure manner where the trusted application library gets to ensure the right permissions are given to the memory pages in question through a hypercall.

PPT also provides TA <NUM> with a memory freeing function (e.g., "Free") to be called from the trusted environment, and that function may behave very similarly to malloc mentioned above except that it frees the previously allocated memory.

PPT also provides for shared memory for scenarios including the following: (i) untrusted application <NUM> shares a buffer with TA <NUM>, or vice versa; and (ii) TA <NUM> shares a buffer with another TA. The two entities between which sharing happens may or may not be in the same process.

In an example process, TA <NUM> shares memory with another TA, which may be referred to as TA2. Also, those two TAs reside in different processes. The sharing process involves two main steps: sharing and mapping.

For the sharing step, TA <NUM> creates a first buffer. TA <NUM> then requests VMM <NUM> to share the first buffer with a list of entities -- TA2 in this case. VMM <NUM> creates local data structures for managing shared memory and returns a buffer handle to TA <NUM>. This buffer handle may be referred to as a shared memory handle.

For the mapping step, VMM <NUM> passes the shared memory handle to the process in which TA2 resides. TA2 then creates a second buffer with a starting address. Using the starting address for the second buffer and the shared memory handle, TA2 requests VMM <NUM> to map to the shared buffer. In response, VMM <NUM> updates the EPT for TA <NUM> and the EPT for TA2 so that those EPTs map the same physical pages to the virtual pages of buffers created by TA <NUM> and TA2. Hence, TA2 can access the shared data of TA1 by accessing the buffer created by TA2.

If TA <NUM> and TA2 reside in the same process, then TA2 doesn't need to create a new buffer. It may just call the map request with same buffer address created by TA1.

Also, to make this solution generic, TA <NUM> or TA2 can be replaced by an untrusted application in the above flow.

One benefit of this solution is that no data is copied. Another benefit is that the OS is not involved in data sharing. VMM <NUM> manages the shared memory. The memory can only be accessed by the TAs that have been granted explicit access by VMM <NUM>. Hence, the shared memory is secure.

Garbage collection of a TA should be done when memory is no longer required. Other than the clean termination of the TA, memory may no longer be required if the TA crashes during execution or if the process that created the TEE session exits.

<FIG> is a flow diagram that illustrates an example overall flow for cleaning up memory. As shown at arrow <NUM>, a caller process (e.g., untrusted application <NUM>) creates the trusted application in a TEE (e.g., TA <NUM> in TEE <NUM>). For instance, untrusted application <NUM> may use PPT loader <NUM> to create TA <NUM>.

In addition, data processing system <NUM> starts a special process called the monitor <NUM> at boot time. In one embodiment, monitor <NUM> is an untrusted process that operates more or less in parallel to untrusted application <NUM> and TEE <NUM>, and monitor <NUM> keeps track of all the processes that create a TA. For instance, as shown at arrow <NUM>, once untrusted application <NUM> creates TA <NUM>, untrusted application <NUM> may connect itself with monitor <NUM>. In particular, one of UPLs <NUM> executing in the context of untrusted application <NUM> may connect with monitor <NUM>, using named pipes or any other suitable mechanism, including portable OS interface (POSIX) inter-process communication (IPC) mechanisms like signals, sockets, etc. As shown at arrow <NUM>, untrusted application <NUM> may then use TA <NUM>.

Once execution of TA <NUM> is complete, the caller process (untrusted application <NUM>) checks whether TA <NUM> crashed during its execution. If untrusted application <NUM> determines that TA <NUM> exited or crashed, untrusted application <NUM> may perform memory cleanup straight away, as shown at arrow <NUM>. Otherwise, untrusted application <NUM> may continue to run. Once untrusted application <NUM> exits, the pipe between untrusted application (UA) <NUM> and monitor <NUM> breaks. This is a trigger to the monitor process to initiate garbage collection, as shown at arrow <NUM>.

This garbage collection is independent of any OS or RTOS, since this a protected TA memory which even the OS does not have access to. VMM <NUM> keeps track of the memory assigned to each TA and relies on the monitor process and the untrusted side process to initiate the cleaning process. If the TA crashes, the untrusted side process (e.g., untrusted application <NUM>) should initiate the cleaning of the TA memory. If the untrusted side process itself crashes, then the monitor process will initiate the garbage collection.

An APT uses a different approach to provide protection similar to that provided by an SPT. One difference between an APT and an SPT is that the APT is not maintained based on page faults. Instead, the PPT VMM creates an entry in the APT for each code page and each data page associated with the TA when the TA is being loaded into the memory. For instance, as indicated below, PPT loader <NUM> may automatically instruct VMM <NUM> to create the entries for APT <NUM> on a page-by-page basis, as PPT loader <NUM> loads each page for TA <NUM> into memory.

This approach improves the run time performance of the TA, since it mitigates constant VM-exits and VM-entries caused due to page faults. An APT also leads to better performance because the page table footprint is small. The PPT VMM only puts entries in the APT for the memory that needs to be accessed by the TA. This also results in smaller memory requirements for an APT, compared with an SPT.

Additionally, when an APT is created, the memory to hold the APT is not allocated from the guest OS memory, but from an isolated memory region to which the guest OS has no access. Memory virtualization is used to explicitly give access to the APT only to the TA which owns it. The OS cannot read or write to these pages. Instead, the APT is managed completely by the PPT VMM. Since the guest OS cannot modify entries in the APT, the aforementioned attacks are mitigated.

A benefit of using an APT is that it can be used in systems that don't employ a real-time OS (RTOS) and it can be used without specialized processor instructions. By contrast, other systems may require an RTOS running on a different processor to provide a secure page table for a TA. Furthermore, an APTs is created by a VMM which is in the TCB of its system.

Referring again to <FIG>, in the example scenario, VMM <NUM> creates APT <NUM> when TA <NUM> is being loaded into RAM <NUM>. The memory for APT <NUM> is protected from the view of OS <NUM>. Hence, OS <NUM> cannot read or write to it. APT <NUM> is completely managed in the VMX root mode by VMM <NUM>.

As described in greater detail below, when PPT loader <NUM> loads TA <NUM>, PPT loader <NUM> registers each of the code and data pages for TA <NUM> with VMM <NUM>. In response, VMM <NUM> walks the OS page tables and gets the GVA to GPA mapping for that page and the page attributes, and VMM <NUM> then creates a similar entry in APT <NUM>. This continues until the whole TA is loaded. While registering TA pages with the hypervisor, PPT loader <NUM> also sends page type (Code/Data/Guard Page) as a parameter to VMM <NUM>, and VMM <NUM> sets appropriate permissions (RX/RW/RO) for those pages in APT <NUM>.

Once all the pages of TA <NUM> are registered, PPT loader <NUM> signals VMM <NUM> to lock down APT <NUM>. From that point onwards, no more entries for additional code pages can be added to APT <NUM>.

For each entry to be created in APT <NUM>, the memory is taken from an isolated memory region to which OS <NUM> has no access. That isolated memory region may be managed by VMM <NUM>. In one embodiment, the hypervisor gives the owner TA exclusive rights to the APT memory using an approach like that described above with regard to <FIG>.

Just before the entering TA <NUM>, one of the TISRs <NUM> updates the control register (CR) that is supposed to point to the page table base for TA <NUM> (e.g., CR3) to make that CR point to the APT root for TA <NUM>.

<FIG> presents a flowchart depicting operations associated with creating an APT, according to an example embodiment. In particular, <FIG> depicts those operations primarily from the perspective of PPT loader <NUM>. The illustrated process starts at block <NUM> with untrusted application <NUM> invoking PPT loader <NUM> to launch TA <NUM>. In response, as shown at block <NUM>, PPT loader <NUM> reads all of TA <NUM> into memory. For instance, PPT loader may read TA <NUM> into PPT loader's memory space. As shown at block <NUM>, PPT loader <NUM> may then allocate dynamic memory equivalent to the size required to host TA <NUM>. After PPT loader has finished loading TA <NUM> into that memory as described below, that memory will include code, static data, stack memory and some other special pages.

As shown at block <NUM>, this dynamic allocation will cause OS <NUM> to create entries in GPT <NUM> for the allocated pages. As shown at block <NUM>, PPT loader then parses the TA image that was read, and copies the contents from the first page into the allocated memory. Additionally, PPT loader registers that page with VMM <NUM>, as shown at block <NUM>. As described in greater detail below with regard to <FIG>, VMM <NUM> may then add that page to the trusted view for TA <NUM>.

As shown at block <NUM>, PPT loader <NUM> may then determine whether all of the pages for TA <NUM> have been loaded and registered. If they have not, the process may return to block <NUM>, with PPT loader <NUM> loading and registering each page, one by one, as indicated above.

After all of the pages have been loaded and registered, PPT loader <NUM> may instruct VVM <NUM> to lock APT <NUM>, as shown at block <NUM>.

<FIG> presents another flowchart depicting operations associated with creating an APT, according to an example embodiment. In particular, <FIG> depicts those operations primarily from the perspective of VMM <NUM>. Those operations may start at block <NUM> with VMM <NUM> determining whether it has received a request from PPT loader for registration of a page for TA <NUM>. If PPT loader is registering a page with VMM <NUM>, as shown at block <NUM>, VMM <NUM> may allocate memory for that TA page from the isolated memory region.

Also, as shown at block <NUM>, if APT <NUM> needs another page to accommodate another entry, or if this is the first entry and thus the first page for APT <NUM>, VMM <NUM> may allocate a page for APT <NUM> from isolated memory. As shown at block <NUM>, VMM <NUM> may then walk GPT <NUM> for that virtual page address to get the corresponding GPA. VMM <NUM> may then add that same mapping from GVA to GPA to APT <NUM> by creating a new entry, as shown at block <NUM>. As shown at block <NUM>, VMM <NUM> may then allocate a new entry in the EPT for TA <NUM> by mapping the GPA to the HPA from block <NUM>.

As shown at block <NUM>, VVM <NUM> may then determine whether PPT loader <NUM> has instructed VMM <NUM> to lock APT <NUM>. For instance, PPT loader <NUM> may identify the code pages for TA <NUM>, and PPT loader may instruct VMM <NUM> to lock the APT entries for those pages. In response, as shown at block <NUM>, VMM <NUM> may consider APT <NUM> to be locked with regard to code pages, and VMM <NUM> may therefore prevent any further code pages from being added to APT <NUM>. However, other dynamic heap pages may be added to the view for TA <NUM>, and thus to APT <NUM>, later on. For example, in shared memory situation, an untrusted view may want to share some memory with the trusted view; and in that case, VMM <NUM> may add entries to APT <NUM> corresponding to the shared memory.

As shown at block <NUM>, after VMM <NUM> has locked APT <NUM>, a TA-enter ISR from TISRs <NUM> may load the root address for APT <NUM> into CR3. That TA-enter ISR is called at the time of enter flow. In other words, after TA <NUM> is created by the process described through block <NUM>, untrusted code flow may want to enter into TA <NUM> for initialization or using services exposed by TA <NUM>. On each entry into TA <NUM>, the trampoline flow loads the root address for APT <NUM> into CR3, to switch to the trusted view page table. As described in greater detail below, that trampoline flow may be executed by one of TISRs <NUM>.

Accordingly, TA creation may end at block <NUM>, and TA entry may start at block <NUM>, with the view switching from untrusted to trusted. Then, as shown at block <NUM>, VMM <NUM> causes TA <NUM> to start executing with a trusted view, and the process of <FIG> may end.

Subsequently, a TA-exit ISR may switch from the trusted view to an untrusted view by modifying CR3 to point to GPT <NUM>.

<FIG> is a block diagram illustrating some of the operations associated with creating APT <NUM>. In addition to the operations described above, <FIG> shows that VMM <NUM> invalidates internal caches such as TLBs that contain GVA to HPA mappings and mappings between GPAs and HPAs, to ensure that the guest software is able to address the correct physical page when referenced through the GVA. Also, at arrow <NUM>, <FIG> illustrates the memory management module creating an APT entry for a page. In particular, the memory management module may configure that entry with page attributes that match the page attributes in GPT <NUM> and with page permissions based on the page type.

Jumping to the middle of a function by compromising the caller stack is a common security concern. The impact of this exploitation is heightened if a jump could be done from untrusted to trusted application space, as such a jump would break the TEE itself. To mitigate this, a common approach is to develop an architecture where the jump from untrusted to trusted space is made to a predetermined location in the TEE, and the TEE then jumps to a particular trusted method after setting up the trusted environment.

A jump to a TA may also happen after an interrupt has taken execution out to the OS handler, and then the runtime resumes the TA execution from the point it was interrupted. A malware/rootkit may attack the untrusted runtime and jump to an arbitrary location in the TA which can compromise the security. A system with TEEs based on a hypervisor may use the technology described by ARM Ltd. under the name or trademark TRUSTZONE to switch into and out of the secure world. However, that technology requires specialized hardware instructions and a special hardware mode, and it requires running the TEE in the context of a secure OS host which runs in secure world mode. Consequently, that technology requires the VMM to do either paravirtualization or full virtualization.

This part describes PPT features that obviate the need for special hardware support and the need for the VMM to provide full or complete virtualization, to enable the data processing system to run both a secure OS and an unsecure OS. For instance, as described in greater detail below, a data processing system with PPT may use a VIDT to facilitate safe entry in the TA. Furthermore, the data processing system may run the TEE in the context of an unsecure OS itself. Consequently, switches to secure world and insecure world are as simple as changing the EPT pointers, and that change may be performed by a single CPU instruction.

Referring again to <FIG>, entry into a TA <NUM> happens primarily for two reasons: (<NUM>) untrusted application <NUM> calling TA <NUM> to make use of functionalities exposed by TA <NUM>, and (<NUM>) resuming from an asynchronous exit that happened due to various interrupts and/or exceptions while running TA <NUM> code. In the first case, data processing system <NUM> may use the TA-enter ISR as a trampoline to jump to a pre-determined location in TA <NUM>. In the second case, data processing system <NUM> may use the TA-resume ISR to safely resume the TA <NUM> code from the next instruction pending when the interrupt happened.

<FIG> is a block diagram illustrating various secure data structures accessed by TISRs <NUM>, according to an example embodiment. Such data structures may be referred to in general as PPT data structures (PDSs). One of those structures is an SGX Enclave Control Structure (SECS) <NUM>. SECS <NUM> may be implemented as a shared page between VMM <NUM> and TISRs <NUM>. VMM <NUM> may create one SECS for each TA. SECS <NUM> contains data for managing TA <NUM>, such as the base address for TA <NUM>. For instance, after PPT loader <NUM> has loaded TA <NUM> into memory, PPT loader <NUM> may allocate memory and copy the TA code, data, and thread context related pages in this memory. The start address of this allocated memory becomes the TA base address. PPT loader <NUM> may then pass that base address for TA <NUM> to VMM <NUM> as part of a create_view() hypercall. VMM <NUM> may then store that base address in the SECS page for the newly created view.

As illustrated, the trusted view <NUM> for TA <NUM> may include code and data pages from TA <NUM> and TPLs <NUM>. Trusted view <NUM> may also include one or more thread context data structures (TCDS) <NUM>, to store context data for each thread within the TA <NUM> process. As illustrated, TCDS <NUM> may contain a thread control structure (TCS), thread local storage (TLS) for thread data (TD), a state save area (SSA), guard pages, a stack page, a parameter page, etc. TCDS <NUM> and each structure within TCDS <NUM> may also constitute a secure data structure that is accessed by TISRs <NUM>.

Each PDS may be accessible to and used by different components. For instance, the TD may be accessible to and used by TA <NUM>, the TCS may be accessible to and used by TISRs <NUM>, SECS <NUM> may be shared between VMM <NUM> and TISRs <NUM>, the SSA may be used only by TISRs <NUM>, etc. However, data processing system <NUM> may create a distinct set of PDSs for each view, and those PDSs may be allocated from VMM heap memory.

In one embodiment, PPT loader <NUM> prepares the TLS as part of the process for initializing some thread specific-structures for the TA <NUM>. One or more programs from TPLs <NUM> on the trusted side then take the initialized content of the TLS and do some relocations on the structure members and create a TD. With regard to <FIG>, SECS <NUM> may reside in RAM <NUM> outside of VM <NUM>, as a trusted page shared between VMM <NUM> and TISRs <NUM>.

<FIG> is a flow diagram that illustrates entry to and exit from TA <NUM> using TISRs, according to an example embodiment. In particular, <FIG> illustrates an example flow involving a typical call from untrusted application <NUM> to TA <NUM>.

However, before the process of <FIG> begins (for instance, when the binary for TA <NUM> was being built), the developer will have defined a common entry point for TA <NUM> using an Executable and Linkable Format (ELF) symbol in the ELF header in the binary for TA <NUM>. That entry point may be defined in terms of an offset from the base address. Also, data processing system <NUM> will have created the TCS for TA <NUM>, and data processing system <NUM> will have stored the entry point offset in the TCS.

In addition, to is protect confidentiality and integrity, the TCS is included in an offline signature process which includes hashing the content of all code and data pages for TA <NUM> (which pages include TCDS <NUM>) and signing the hash with the Rivest-Shamir-Adleman (RSA) private key of the TA vendor. The content that is hashed may be referred to as the TA blob. VMM <NUM> subsequently performs (a) hash verification to ensure the integrity of the TA blob (including the integrity of the TCS) and (b) signature verification using the RSA public key of the TA vendor to ensure the confidentiality of the TA blob (including the confidentiality of the TCS).

Untrusted application <NUM> may then use PPT loader <NUM> to load TA <NUM> into memory.

As illustrated in <FIG>, untrusted application <NUM> may then make a call to TA <NUM>. In particular, untrusted application <NUM> may parse the ELF header for TA <NUM> to extract various symbols, such as the entry point offset, and untrusted application <NUM> may then call a function or execute a statement for entering the trusted view, using that that offset as a parameter.

For purposes of this disclosure, a function or statement for calling a trusted application from an untrusted application may be referred to as an entry call. In some embodiments, entry calls may be implemented as ecall or Se_ecall functions in a UPL such as UPLs <NUM>. As described in greater detail below, an ecall function may use a TA-enter interrupt to invoke a TA-enter ISR, and the TA-enter ISR may use the VMFUNC instruction to switch from an untrusted view to a trusted view.

In particular, in the embodiment of <FIG>, when the ecall function is called, the URTS responds by loading the parameters from the call into registers and then invoking the reserved TA-enter interrupt (e.g., Int-<NUM>). The URTS may invoke the software interrupt using an "int" instruction, for instance. Data processing system <NUM> may then automatically launch the corresponding TA-enter ISR from TISRs <NUM>, based on VIDT <NUM>.

In one embodiment, VIDT <NUM> uses teachings like those described in U. <NUM>,<NUM>,<NUM> to handle such interrupts. For instance, VIDT <NUM> may include an exit stub for exiting from the view of the interrupted program to the view of the TISR registered in VIDT <NUM>, and a re-entry stub for each TA for switching the view of the interrupt handler back to the view of the interrupted program. Also, VIDT <NUM> may reside in a host memory page that has a permission view of read-only to all other programs to disallow tampering of the VIDT <NUM>.

As shown in <FIG>, once the TA-enter ISR has been launched, it may read and validate SECS <NUM>. If SECS <NUM> is valid, the TA-enter ISR then uses the VMFUNC instruction to switch to the trusted view of TA <NUM>. In addition, the TA-enter ISR switches to the trusted page table (i.e., APT <NUM>) to mitigate against page remapping attacks. The TA-enter ISR also copies all of the general purpose register (GPR) state, including the return instruction pointer (RIP) that was automatically saved by the hardware on "int", along with the hardware saved register state, to the trusted ring-<NUM> stack to further enhance the security. In addition, the TA-enter ISR reads the entry point offset from TCS <NUM>.

In one embodiment, data processing system <NUM> uses EPT protections to protect the TCS and the other PDSs, so that the EPT for the untrusted view does not have permission to access these private data structures. Consequently, the TA-enter ISR may rely on the offset being correct. The TA-enter ISR then retrieves the base address of TA <NUM> from SECS <NUM>, and adds the offset to the base address. This addition gives the actual entry point address of TA <NUM>.

The TA-enter ISR then replaces or overwrites the RIP that was automatically saved by the hardware on "int" with the entry point address for TA <NUM>. The TA-enter ISR then executes an interrupt return or "iret" instruction, which cause control to jump to that entry point.

If this is the first ecall, the TRTS (e.g., one or more programs in TPLs <NUM>) initializes the TD for TA <NUM> by adding the TCS address to various fields in the TLS that were populated by PPT loader <NUM>. And even though the TLS may have been considered untrusted when it was initialized by PPT loader <NUM>, it may be considered to be a confidentially and integrity protected data structure because subsequently, as a part of a trusted page, all the initialized content of the TLS will have been copied to the protected memory by VMM <NUM>. And the initialization may be considered reliable because the TLS was also a part of the TA blob that was hashed and signed and later verified by VMM <NUM>.

After initialization, TD contains a pointer to the trusted stack. The TRTS then uses that trusted stack pointer to switch to the trusted stack, since the TA execution must use the known private stack for saving local variables and return addresses of the TA functions. The TRTS may then pass control to TA <NUM>, and TA <NUM> may then execute.

After the TA function returns, control for the TA entry-exit flow goes back to TRTS (e.g., one or more programs in TPLs <NUM>), and the TRTS then safely returns back by invoking the TA-exit interrupt (e.g., Int-<NUM>). As a part of this safe return, the TA exit code clears the GPRs, thus protecting the information from leak through registers. In addition, the TA exit code switches back to the untrusted stack before invoking the TA-exit interrupt.

The TA-exit ISR would then switch to the untrusted view and load the regular OS page tables by pointing CR3 to the OS page table base at GPT <NUM>. Also, the TRTS passes the return IP in one of the registers, and the TA-exit ISR loads that IP to the interrupt stack return frame. The TA-exit ISR than executes an Iret, which causes control to jump to the next instruction to the enter instruction (i.e., the next instruction after the TA-enter interrupt). In response, the URTS then properly returns control back to the caller of ecall (i.e., untrusted application <NUM>).

<FIG> is a flow diagram that illustrates asynchronous exit from and resume to TA <NUM>, according to an example embodiment. Such a resume from an asynchronous exit may happen when an interrupt comes while executing the TA code.

If an interrupt occurs while executing TA <NUM>, the interrupt causes an asynchronous exit. VIDT <NUM> is set up to ensure that a trusted ISR executes for each such asynchronous exit. For instance, in response to the interrupt, VIDT <NUM> may cause a general purpose (GP) or "non-reserved" ISR from TISRs <NUM> to determine whether the currently executing code is using a TA. For example, that TISR may use a view-id function to determine whether the current view is a trusted view. If the current view is not a trusted view, then the TISR hands over the interrupt to the guest OS's interrupt handler.

However, as indicated in <FIG>, if the current view is a trusted view, the TISR saves the current GPR state, including the RIP, in the SSA, which is a data region in TA <NUM> that is not visible outside the trusted view.

The TISR also replaces the RIP on the current stack with the asynchronous exit pointer (AEP) of the untrusted runtime in the interrupt stack. The TISR also replaces the trusted runtime stack pointer (RSP) with the untrusted RSP on the interrupt stack. This is done so that an "iret" can jump to a known exit point in the URTS.

Also, the TISR prepares synthetic GPR state on the interrupt stack. This ensures that the potential trusted secret information available in the GPRs is not exposed to the outside world. One of the GPRs in the synthetic state contains a flag indicating that, for control to come back to TA <NUM>, the control must come from the resume flow.

The TISR then switches from trusted to untrusted page tables (e.g., by switching CR3 from pointing to APT <NUM> to GPT <NUM>).

The TISR then switches from trusted view to untrusted view using VMFUNC. The TISR then switches from trusted ring-<NUM> stack to untrusted ring-<NUM> stack. The TISR then copies all of the synthetic GPR state to the untrusted stack. The TISR then jumps to the OS ISR by executing a return instruction. The OS ISR then handles the interrupt.

The OS ISR then executes an "iret," at which point the control gets transferred to the AEP in the URTS. The URTS then pushes the target view id in another GPR. In other words, the URTS saves the identifier for the view-to-enter in a register. The URTS then triggers the reserved TA-exit interrupt (e.g., Int-<NUM>) using the "int" instruction.

Then, the rest of the flow for re-entering TA <NUM> after an asynchronous exit may be similar to the synchronous entry, except that the entry point is taken from the RIP entry in the SSA. Also, the GPR state of trusted at the time of the asynchronous interrupt is taken from the SSA and put in the trusted ring-<NUM> stack, so that on "iret," the architectural state is preserved on re-entry to TA <NUM>.

A TEE requires at least one data structure that contains state information for correct and secure execution. For instance, in one embodiment, PPT involves an SECS for each TA, a TCS for each TA, etc., as indicated above. Such data structures need to be secured against read, write, and execute access from the untrusted world. Some techniques to provide protection through encryption or restricted permissions utilize OS-managed page tables or VMM-managed EPTs. However, those techniques may be too complicated or insufficient, considering the variety of attacks that are possible.

This disclosure introduces a secure cookie value (SCV) that is obtained from a secure hardware agent and that is used by a trusted software block (such as VMM <NUM>) to patch software that is protected with regard to integrity and confidentially (such as TA <NUM>). After patching, this SCV becomes a part of the protected software. The SCV is then compared with a corresponding value in an EPT-protected data structure. In one embodiment, that EPT-protected data structure is SECS <NUM>. In case of a mismatch, execution of the protected software is aborted before that software can leak out any security sensitive information from the TEE. This solution may also be immune to attacks based on page remapping. For instance, this solution provides protection even if a compromised OS kernel performs memory remapping of the private data pages of the TEE.

To protect the private data of TA <NUM> running in the context of TEE <NUM>, the trampoline code that allows transitions in and out of TA <NUM> perform SCV checks. In one embodiment, that trampoline code is implemented as TISRs <NUM>. The SCV itself is randomly generated by hardware and cached by VMM <NUM>. VMM <NUM> then writes or patches the SCV into the TISR flow. For instance, VMM <NUM> may patch the SCV to various instruction offsets in TISRs <NUM>. In addition, VMM <NUM> writes the SCV into the SECS for TA <NUM> (i.e., SECS <NUM>). Then, before transferring control to TA <NUM>, one or more of the programs in TISRs <NUM> checks the SCV in SECS <NUM> against the SCV that was patched into TISRs <NUM> to make sure they match. The TISR aborts execution of TA <NUM> if the check fails. Thus, the checks compare a randomly generated (by hardware) SCV stored in an EPT protected data structure (SECS <NUM>) with the value patched by a trusted software entity (VMM <NUM>) in the trampoline code (TISRs <NUM>), and the trampoline execution is aborted if the check fails. Consequently, TEE <NUM> is not activated.

The physical contents of SECS <NUM> in the trusted world are hidden using EPT-based memory virtualization techniques. But the trampoline execution requires that the correct data structure is referenced in the trampoline code even if the page tables of the OS are manipulated by an attacker to map the data structure's virtual address to a different physical page. The random secure cookie checks protect against this type of attack.

<FIG> is a block diagram that illustrates memory mapping for TA <NUM> between a virtual address space and a physical address space. As indicated above, a virtual address may also be referred to as a linear address. Accordingly, <FIG> depicts the guest virtual address space for TA <NUM> as a "TA Linear Address Space," and <FIG> depicts a corresponding "Host Physical Memory. " Accordingly, the illustrated data structures may be accessed through the same virtual address for both TEEs and untrusted REEs. However, the physical copies of the data structures are kept different, based on EPT mappings.

In particular, <FIG> shows that, in the linear address space, structures such as the SECS, the VIDTs, the ISRs, the global descriptor table (GDT), etc. are only accessible to software running at the highest privilege level (e.g., ring <NUM>). In addition, <FIG> shows that the current view remaps some objects to host physical memory addresses that are above the top of the memory that is addressable by the OS. In particular, the GDT and shared memory reside below the top of OS-usable memory, but other components (e.g., the TA code and data, the SECS, etc.) reside above the top of OS-usable memory. As indicated in <FIG>, the components residing above the top of OS-usable memory have been remapped via a view to the hypervisor or VMM heap.

Consequently, those components are protected from direct memory access (DMA) attacks. Some devices may use DMA to directly access the physical memory (i.e., to access physical memory without going through page tables or EPTs to get linear to physical address translations). However, VMM heap is allocated from a special memory pool that is hardware protected against DMA access. Thus, VMM memory is protected against DMA-based attacks, which might otherwise lead to data theft or unintended code execution.

The GVA to GPA mapping is controlled by the OS page tables, which are not in the TCB of the system. PPT ensures that the private copies of the data structures are valid through the mechanism of SCVs, which do not require specific OS support, and which also provide protection from page remapping attacks (which involve changes the OS page table entries). In addition, SCVs do not require private page tables to be set up to map virtual addresses to secure physical addresses.

In one embodiment, every TA (e.g., TA <NUM>) running inside a TEE (e.g., TEE <NUM>) has its private SECS (e.g., SECS <NUM>). SECS <NUM> is used while entering TA <NUM> and exiting from TA <NUM>. The data in SECS <NUM> is unique to TA <NUM>, and SECS <NUM> is accessed only by protected trampoline pages, such as TISRs <NUM>. SECS <NUM> cannot be accessed by any other trusted or untrusted component outside of the TCB for TA <NUM>.

In addition, components must be running at the highest privilege level (e.g., ring <NUM>) to access pages containing SECS <NUM>. And TISRs <NUM> run only at the highest privilege level. Also, VMM <NUM>, which runs beneath OS <NUM>, maps the SECS pages and the TISR trampoline pages to ring <NUM>. VMM <NUM> also configures those trampoline pages with execute-only permission.

During initialization of VMM <NUM>, VMM <NUM> uses a random number generator in processor <NUM> or security hardware <NUM> to obtain a random number or nonce to serve as the system SCV. VMM <NUM> then patches that SCV into TISRs <NUM> to add the cookie in the code where the comparison will take place. VMM <NUM> also writes that SCV into SECS <NUM> at the time of TA creation. Subsequently, the trampoline code compares the patched SCV with the SCV in SECS <NUM>. Also, if there are multiple TA's, VMM <NUM> may give each TA the same SCV.

<FIG> presents a flowchart depicting operations associated with creating and saving an SCV according to an example embodiment. The illustrated process starts at block <NUM> with PPT loader <NUM> calling PPT driver <NUM>, for instance in response to untrusted application <NUM> calling TA <NUM>. PPT driver <NUM> may have already been initialized.

As shown at block <NUM>, PPT driver <NUM> may then pass the GVA of SECS <NUM> to VMM <NUM> with a request to register SECS <NUM>. As shown at block <NUM>, PPT driver <NUM> may then allocate the SECS <NUM> for TA <NUM>.

As shown at block <NUM>, VMM <NUM> may then load an SCV into SECS <NUM>. As indicated above, VMM <NUM> may have obtained that SCV when VMM <NUM> was initialized. As shown at block <NUM>, VMM <NUM> may then map the GVA of SECS <NUM> in the APT for TA <NUM> (i.e., APT <NUM>), and VMM <NUM> may create EPT mappings to map the GPA for SECS <NUM> to the page that was allocated for SECS, as indicated in block <NUM>.

As shown at block <NUM>, PPT driver <NUM> may then allocate memory for VIDT code pages for each CPU in data processing system <NUM>. For instance, PPT driver <NUM> may allocate memory for TISRs <NUM>. PPT driver <NUM> may also register those pages with VMM <NUM>. As shown at block <NUM>, VMM <NUM> may then map the VIDT code pages to EPTs <NUM>. As shown at block <NUM>, VMM <NUM> may then patch the binary for TISRs <NUM> with the SCV. The process of <FIG> may then end.

<FIG> is a flowchart of an example embodiment of process for creating a PPT data structure for storing an SCV. In particular, the example process involves creating SECS <NUM> for TA <NUM>. That process may start at block <NUM> with PPT loader <NUM> calling VMM <NUM> to create a trusted view for TEE <NUM> and TA <NUM>. As shown at block <NUM>, VMM <NUM> may then determine wither VIDT <NUM> has been initialized yet. If it has not, VMM <NUM> may initialize VIDT <NUM>, as shown at block <NUM>. For instance, VMM <NUM> may perform signature and hash verification of the TISR flows and then install TISRs <NUM> if verification is successful.

As shown at block <NUM>, VMM <NUM> may then create the trusted view for TA <NUM>. For instance, VMM <NUM> may add an EPT to EPTs <NUM> to serve as an EPT root structure, thereby creating the view. VMM <NUM> may subsequently add GPA-to-HPA page mappings to that EPT for TA code, data, TCDS, SECS, etc..

For example, as shown at block <NUM>, VMM <NUM> then allocates memory for SECS <NUM> and then updates the EPT for TA <NUM> in EPTs <NUM> to provide access to SECS <NUM>. As shown at block <NUM>, VMM <NUM> then maps SECS <NUM> to the GVA which was created during registration of SECS <NUM> with VIDT <NUM>. , see block <NUM> of <FIG>. ) The process of <FIG> may then end.

<FIG> is a block diagram that illustrates PPT data structure mapping according to an example embodiment. In particular, <FIG> depicts a scenario in which multiple TAs have been created, and <FIG> illustrates that the GVA for each different SECS for each different TA points the appropriate HPA based, on the current active view. The "SECS GVA" to "SECS GPA" mapping may be done by guest OS <NUM>. The vertical line represents the translations performed by EPTs <NUM>. And the boxes on the right show that, if there are multiple TAs, each different TA gets a different EPT, and each different EPT maps the same SECS GPA to a different HPA.

<FIG> is a flowchart depicting operations associated with switching from a rich execution environment to a trusted execution environment, according to an example embodiment. The illustrated process starts at block <NUM> with a program in the REE initiating a switch to the TEE and using a GPR to pass the identifier for the view for that TEE. For instance, as described with regard to <FIG>, untrusted application <NUM> may use an ecall to call TA <NUM>, and in response the REE may trigger a TA-enter interrupt. In response, as shown at block <NUM>, one of TISRs <NUM> (e.g., the TA-enter ISR) may intercept the TA-enter interrupt and, in response, switch from the untrusted view to the trusted view for TA <NUM>.

For example, in one embodiment, the VMM maintains a pointer to the currently-active EPT on that CPU. That pointer may be a VMX data structure called the EPT-pointer or EPTP. The VMM may also maintain another data structure that contains pointers for each view's EPT. That data structure may be called the EPTP list page. The VMFUNC instruction may read the EPT list page using a specified view-id as an index to obtain the EPTP pointer for that view. The VMM may then internally update EPTP with that EPTP pointer.

As shown at block <NUM>, after switching the view, the ISR may then read the SCV from the SECS for the current view (e.g., SECS <NUM>). As shown at block <NUM>, the ISR may then read the SCV from TA to be executed (e.g., TA <NUM>), and the ISR may determine whether the patched SCV n the ISR and the SCV for TA <NUM> in SECS <NUM> match. If the SCVs do no match, the ISR may conclude that an attack is being attempted, and the ISR may take remedial action, as shown at block <NUM>. For instance, the ISR may conclude that it has detected an invalid attempt to switch view into a trusted application view, and in response the ISR may permanently block view switching for that view handle. The ISR may also take other remedial measures. For instance, the ISR may cause a system shutdown by making a VMM assert hypercall.

However, if the SCVs match, the ISR may then pass control to the TA, as shown at block <NUM>. The process of <FIG> may then end.

As indicated above, a TA is an application that runs in an execution environment that is isolated from the REE, and the applications running in the REE cannot access the TA address space. This poses a problem for debugging runtime TA bugs from conventional debugging tools (e.g., the GNU Debugger (GDB)) that run in the REE environment.

This disclosure introduces a debugging technique that can provide information concerning TA execution state at the time of fault without crashing the process that hosts the TA. For instance, this technique may provide information from registers, including the instruction pointer (IP), from the stack, from exceptions, etc. Furthermore, this information can be shared with the corresponding REE in a secure manner, and it can be used to debug the TA and resolve the problem. As described in greater detail below, this technique uses VIDT <NUM> and an associated PPT exception handler (PEH).

Basically, VIDT <NUM> and the PEH bypass the OS exception handler if the exception (e.g., a page fault) is generated within a TA. The PEH accomplishes this by handling the exception and serving as trampoline code that switches the execution from TEE to REE. On seeing the crash status, the REE collects the information from the PEH and passes the information to the program that called the TA service, such as untrusted application <NUM>. Untrusted application <NUM> may then choose to initiate the destruction of the TA. But, since TEE OS exception handler is not invoked, the hosting process is not killed. VIDT <NUM> and the PEH thus virtualize the interrupts and exceptions and provide a secure mechanism to switch between the TA and the REE.

As indicated above with regard to <FIG>, VMM <NUM> may install VIDT <NUM> into guest OS <NUM>, and VMM <NUM> may update a register in CRs <NUM> to point to VIDT <NUM> instead of UIDT <NUM>. VIDT <NUM> may include gates for trapping interrupts or exceptions and for automatically invoking certain specified ISRs in response to those interrupts. In particular, the VIDT gate descriptors are configured to transfer control to a software handler (e.g., the PEH) that distinguishes the architectural exceptions from the other interrupt sources based on the vector number generated by the hardware on interrupt/exception. Architectural exceptions may identify faults in process execution, such as a general protection fault, a page fault, a divide-by-zero fault, etc. Other interrupt sources may include device interrupts, timer interrupts, performance monitoring interrupts, etc. The same IDT may be used to vector all interrupts. However, for purpose of exception handling, the PEH may process only the architectural exceptions, based on the vector that caused the jump in the asynchronous exit TISR.

If the exception is generated from within the TA, the PEH collects the faulting data like IP, exception type (e.g., page fault, GP fault, divide by zero, etc.), stack trace, and faulting address accessed during the fault. However, the REE exception handler is not invoked. Instead, control is directly transferred back to the process that called the TA by exiting the TA. In addition, a "TA-crashed" status is returned in a pre-defined GPR to the process that called the TA entry point. The PEH also sets an "invalid-state" flag in the SECS for that TA, so that further entry in the TA may be avoided.

As indicated above, a TA is created within the address space of the calling process, and the VMM remaps the calling process to EPTs during the creation of the view for the TA. The calling process cannot directly access the mapped EPT memory for the TA because that memory is isolated from the calling process. However, the calling process can enter the TA's view by using technology such as the VMFUNC instruction described above.

As indicated above, PPT uses custom ISRs for reserved interrupts such as TA-enter, TA-resume, and TA-exit, to manage the transitions between untrusted application and TA. As part of the process for switching the view securely, the ISR creates an isolated stack for the TA, fills in the required parameters for TA, and then jumps to the TA entry point.

<FIG> is a flow diagram illustrating a process to support debugging, in according with an example embodiment. In the illustrated process, software in the REE (e.g., untrusted application <NUM>) calls a TA (e.g., TA <NUM>), which causes the REE to trigger a TA-enter interrupt (e.g., Int-<NUM>), as described above. Alternatively, the TA may have been interrupted by an asynchronous event, and the flow of <FIG> may start with control returning to the TA via a TA-resume interrupt (e.g., Int-<NUM>).

As shown in <FIG>, for the "Enter flow," the TA-enter ISR saves the untrusted stack pointer and untrusted base pointer in the SSA, which is part of the TCDS. For the "Resume flow," the TA-resume ISR restores TA context (e.g., the state of the GPRs, the IP, the trusted stack pointer) from the SSA. As indicated above, this TA context will have been saved by the asynchronous exit TISR, which will have been invoked earlier, for instance when a guest interrupt hit while the TA was executing.

Control is then passed to the TA, and then the TA then executes. The TA may then experience an exception, an interrupt, or some other fault (e.g., of the code has a bug). If the TA faults, in response, the PEH identifies the source of the fault. For instance, the PEH may differentiate whether the fault was generated by the TA or outside the TEE, based on the current state of the execution context. If the source is not the TA, PEH forwards the fault to the UIDT to be processed by the OS.

However, if the source is the TA, the PEH handles the exception or fault and collects data pertaining to the fault, such as IP, stack trace, and memory address accessed during the fault. In addition, the PEH records the fault status in the SECS for the TA. As indicated above, the processing element also sets a "TA-crashed" status in a pre-defined GPR. enter the TA after fault. Data processing system <NUM> may subsequently prevent further entry into the TA, based on the fault status in the SECS and/or the TA-crashed flag.

In addition, the PEH creates a secure buffer to share the data dump for the fault with the REE. In particular, the VMM creates this dump buffer during the creation of the TA view, and the VMM assigns this dump buffer in the SECS of the TA. For instance, the VMM may save a reference or pointer to the dump buffer in the SECS. This dump buffer can be accessed by the PEH in ring <NUM> when the PEH is executing under the TA context. Also, if the fault happened within the TA, the PEH traces through the TA stack and dumps the stack trace along with the IP address that caused the fault, the type of the exception, etc. into the dump buffer.

The PEH then shares the dump buffer with the REE by simply exiting the TA view. The REE can then read the TA crash status from the GPR, and the REE may choose to clean the TA view. For instance, the REE may invoke a destroy-view hypercall to instruct the VM to clean up the view.

However, before cleaning the faulted TA memory, the REE can read the dump buffer from VMM <NUM>. Based on the dump buffer, the REE can then identify the TA stack, the IP, etc., to debug and resolve the issue.

In one embodiment, the VMM simply copies the data over to an untrusted buffer. In another embodiment, the VMM encrypts the data from the dump buffer before sharing it with the REE, and the REE then decrypt the data.

In addition, the data processing system may execute a secure boot process that provides for a TEE debug policy based on hardware and/or firmware debug tokens. An administrator may configure certain features through these tokens to provision them on the device. After that, on boot, the security engine firmware <NUM> may read these token values from static RAM (SRAM) or some other secure tamper-proof memory and enable or disable the TEE debug policy based on the tokens.

Alternatively, the ability to install a TEE debug token may be limited to the manufacturer of the data processing system, such as an original equipment manufacturer (OEM), and/or the manufacturer of the CPU. And only if the TEE debug token is installed would the VMM enable the TEE debug features.

PPT thus enables powerful debugging in an isolated TEE, without requiring any specialized software tools or hardware to debug the TAs.

As has been described, a data processing system may use PPT to protect some or all of the code and data belonging to certain software modules from user-level (e.g., ring-<NUM>) malware and from kernel-level (e.g., ring-<NUM>) malware. PPT may provide isolation between various trusted entities, along with the ability to allocate, free, and reuse the memory dynamically at runtime. In addition, the PPT memory sharing model may allow memory sharing between TAs and the untrusted OS, in addition to between TAs.

In light of the principles and example embodiments described and illustrated herein, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles. Also, the foregoing discussion has focused on particular embodiments, but other configurations are contemplated. Also, even though expressions such as "an embodiment," "one embodiment," "another embodiment," or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these phrases may reference the same embodiment or different embodiments, and those embodiments are combinable into other embodiments.

For instance, in one embodiment, the binary translators may use the same Tag-U value (e.g., 0x03) for all internal transfer destinations within the unmanaged code and for all transfers within the unmanaged code to those destinations. In another embodiment, the binary translators may use the same Tag-U value at the entry point for all defined functions, and for the calls to those functions, while using one or more different Tag-U values for other types of destinations.

Any suitable operating environment and programming language (or combination of operating environments and programming languages) may be used to implement components described herein. The present teachings may also be used to advantage in many different kinds of data processing systems. Example data processing systems include, without limitation, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframe computers, mini-computers, client-server systems, personal computers (PCs), workstations, servers, portable computers, laptop computers, tablet computers, personal digital assistants (PDAs), telephones, handheld devices, entertainment devices such as audio devices, video devices, audio/video devices (e.g., televisions and set top boxes), vehicular processing systems, and other devices for processing or transmitting information. Accordingly, unless explicitly specified otherwise or required by the context, references to any particular type of data processing system (e.g., a mobile device) should be understood as encompassing other types of data processing systems, as well. Also, unless expressly specified otherwise, components that are described as being coupled to each other, in communication with each other, responsive to each other, or the like need not be in continuous communication with each other and need not be directly coupled to each other. Likewise, when one component is described as receiving data from or sending data to another component, that data may be sent or received through one or more intermediate components, unless expressly specified otherwise. In addition, some components of the data processing system may be implemented as adapter cards with interfaces (e.g., a connector) for communicating with a bus. Alternatively, devices or components may be implemented as embedded controllers, using components such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, and the like. For purposes of this disclosure, the term "bus" includes pathways that may be shared by more than two devices, as well as point-to-point pathways.

This disclosure may refer to instructions, functions, procedures, data structures, application programs, microcode, configuration settings, and other kinds of data. As described above, when the data is accessed by a machine or device, the machine or device may respond by performing tasks, defining abstract data types or low-level hardware contexts, and/or performing other operations. For instance, data storage, RAM, and/or flash memory may include various sets of instructions which, when executed, perform various operations. Such sets of instructions may be referred to in general as software. In addition, the term "program" may be used in general to cover a broad range of software constructs, including applications, routines, modules, drivers, subprograms, processes, and other types of software components. Also, applications and/or other data that are described above as residing on a particular device in one example embodiment may, in other embodiments, reside on one or more other devices. And computing operations that are described above as being performed on one particular device in one example embodiment may, in other embodiments, be executed by one or more other devices.

It should also be understood that the hardware and software components depicted herein represent functional elements that are reasonably self-contained so that each can be designed, constructed, or updated substantially independently of the others. In alternative embodiments, many of the components may be implemented as hardware, software, or combinations of hardware and software for providing the functionality described and illustrated herein. For example, alternative embodiments include machine accessible media encoding instructions or control logic for performing the operations of the invention. Such embodiments may also be referred to as program products. Such machine accessible media may include, without limitation, tangible storage media such as magnetic disks, optical disks, RAM, ROM, etc., as well as processors, controllers, and other components that include RAM, ROM, and/or other storage facilities. For purposes of this disclosure, the term "ROM" may be used in general to refer to non-volatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc. In some embodiments, some or all of the control logic for implementing the described operations may be implemented in hardware logic (e.g., as part of an integrated circuit chip, a programmable gate array (PGA), an ASIC, etc.). In at least one embodiment, the instructions for all components may be stored in one non-transitory machine accessible medium. In at least one other embodiment, two or more non-transitory machine accessible media may be used for storing the instructions for the components. For instance, instructions for one component may be stored in one medium, and instructions another component may be stored in another medium. Alternatively, a portion of the instructions for one component may be stored in one medium, and the rest of the instructions for that component (as well instructions for other components), may be stored in one or more other media. Instructions may also be used in a distributed environment, and may be stored locally and/or remotely for access by single or multi-processor machines.

Also, although one or more example processes have been described with regard to particular operations performed in a particular sequence, numerous modifications could be applied to those processes to derive numerous alternative embodiments of the present invention. For example, alternative embodiments may include processes that use fewer than all of the disclosed operations, process that use additional operations, and processes in which the individual operations disclosed herein are combined, subdivided, rearranged, or otherwise altered.

Claim 1:
A method comprising:
enabling, by a virtual machine monitor, VMM, (<NUM>) an untrusted application (<NUM>) and a trusted application, TA, (<NUM>) to run on top of a single operating system, OS, (<NUM>) running on a processor (<NUM>) of a device (<NUM>) while preventing the untrusted application (<NUM>) from accessing memory (<NUM>) used by the trusted application (<NUM>), wherein the OS (<NUM>) comprises an untrusted interrupt descriptor table, IDT, (<NUM>) with gates that associate interrupt vectors with untrusted interrupt service routines, ISRs, (<NUM>);
creating, by the VMM (<NUM>), a virtual IDT, VIDT, (<NUM>) with gates that associate interrupt vectors with trusted ISRs (<NUM>), wherein the trusted ISRs (<NUM>) comprise a TA-enter ISR that causes the device (<NUM>) to switch from an untrusted memory view associated with the untrusted application (<NUM>) to a trusted memory view associated with the trusted application (<NUM>) and to jump to a pre-determined location in the trusted application (<NUM>);
configuring, by the VMM (<NUM>), the processor (<NUM>) of the device (<NUM>) to use the VIDT (<NUM>) instead of the untrusted IDT, UIDT, (<NUM>); and
after configuring the processor (<NUM>) to use the VIDT (<NUM>) instead of the UIDT (<NUM>), responding to a TA-enter interrupt used by the untrusted application (<NUM>) by invoking the TA-enter ISR.