Patent Description:
Software applications may store sensitive data such as passwords, account numbers, financial and health records. Various safeguards may be used to protect such sensitive data, for example, a host operating system may prevent unauthorized users from accessing operating system resources, and the application may encrypt sensitive data, but the application has no safeguard against processes having higher privileges, including the host operating system itself. Secured execution technologies provide the capability to run applications without requiring trust in the system administrator or the system software itself, such as a host operating system or hypervisor. In order to do so, a secured execution technology may create an enclave - a protected environment in which the data within the enclave is isolated from the rest of the system. Code and data inside an enclave are not visible and cannot be manipulated by untrusted processes outside the enclave, and the only way to communicate from within the enclave with the unsecured environment outside the enclave is by sending and receiving messages.

One aspects of the disclosure provides a method for creating trusted applications stored in memory of a host computing device. The method includes creating, by one or more processors of the host computing device, an enclave manager in an untrusted environment of the host computing device, the enclave manager including instructions for creating one or more enclaves; generating, by the one or more processors, an enclave in memory of the host computing device using the enclave manager; generating, by the one or more processors, one or more enclave clients of the enclave by the enclave manager such that the one or more enclave clients configured to provide one or more entry points into the enclave; and creating, by the one or more processors, one or more trusted application instances in the enclave.

In one example, the entry points include a plurality of different functions. In this example, the plurality of different functions include one or more of an initialize function, a finalize function, a run function, a donate thread function, a handle signal function, and a destroy function. In addition, the initialize function allows the one or more enclave clients to take system resources to run the one or more trusted application instances. In addition or alternatively, the finalize function allows the one or more enclave clients to relinquish system resources. In addition or alternatively, the run function allows the one or more enclave clients to execute functions of the one or more trusted application instances. In addition or alternatively, the donate thread function allows the one or more enclave clients to have an operating system of the host computing device provide a thread to enter the enclave. In addition or alternatively, the handle signal function allows the one or more enclave clients handle signals sent to the one or more trusted application instances. In addition or alternatively, the destroy function allows the one or more enclave clients to terminate the enclave.

In another example, the one or more enclave clients are further configured to allow code to run in the enclave. In another example, generating the enclave includes using an application having a trusted application designation. In another example, the method also includes using the enclave manager to maintain a hierarchical namespace by binding the enclave to an identifier in the hierarchical namespace. In this example, the one or more trusted application instances includes code that stores sensitive data of an application running in the untrusted environment. In addition or alternatively, the enclave manager is created by the application. In addition or alternatively, the one or more trusted application instances includes code that executes the sensitive data of the application. In another example, the method also includes using the enclave manager to provide platform services including a software-based clock. In another example, the enclave is generated in a system having an isolation kernel and isolation capable hardware. In another example, the enclave is generated in a system having hardware secure execution primitives and isolation capable hardware. In another example, the enclave is generated in a system having a hardware secure element. In another example, enclave is generated in a system remote from the untrusted environment.

Another aspect of the disclosure provides a method for handling threads of execution using an enclave stored in memory of a host computing device. The method includes receiving, by one or more processors, from an application running in the enclave, a request for a new thread of execution for a function of the application; adding, by the one or more processors, the request for a new thread to a queue of requests the request; requesting, by one or more processors, host software of the host computing device to create the new thread requested by the function in the enclave based on the queue of requests; and allowing, by one or more processors, the new thread to enter the enclave.

In one example, the host software includes a host operating system. In another example, the host software includes a host hypervisor. In another example, the method also includes entering a first thread into the enclave, wherein entering the first thread triggers the request for the new thread and the first thread requires the functionality of the enclave in order to accomplish a task. In another example, the queue of requests is maintained by runtime functionality of the enclave as metadata. In another example, the method also includes using metadata of the enclave to track the function, an argument for the function, and a return value for the new thread. In another example, the method also includes using metadata of the enclave to track a status of the new thread in order to allow the application to access a return value for the new thread. In this example, the method also includes using the host software to send the return value for the thread to the new thread.

In another example, the method also includes allowing the new thread to exit the enclave and, in response to receiving a request form the new thread for a second new thread, using the host software create the second new thread outside of the enclave. In this example, the method also includes after the new thread has exited the enclave, allowing the new thread to enter the enclave and allowing the second new thread to enter the enclave. In addition or alternatively, the method also includes using the queue of request to identify a second function, executing the second function in the enclave using the second new thread to obtain a return value, and allowing the second new thread to exit the enclave after executing the second function. In addition or alternatively, after allowing the second new thread to enter the enclave, determining that the queue of requests is empty and based on the determination, allowing the second new thread to exit the enclave. In addition or alternatively, after allowing the second new thread to enter the enclave, determining that the queue of requests is empty and based on the determination, tearing down the enclave.

In another example, the method also includes creating the queue of requests in metadata of the enclave using runtime functionality of the enclave. In another example, the method also includes updating the queue of requests as the application running in the enclave sends new requests for additional thread of execution for one or more functions of the application. In another example, the new thread is configured to enter the enclave and execute the function. In another example, the enclave is implemented in a system having an isolation kernel and isolation capable hardware. In another example, the enclave is implemented in a system having hardware secure execution primitives and isolation capable hardware. In another example, the method also includes generating the enclave in a system having a hardware secure element. In another example, the enclave is implemented in a system remote from the untrusted environment.

Another aspect of the disclosure provides a method for handling file operations for files of an enclave stored in memory of a host computing device. The method includes receiving, by one or more processors of the host computing device, a request from a function in an enclave to perform a file operation at a file path; delegating, by the one or more processors, the file operation to a host; translating, by the one or more processors, a value of a flag of the file path into a native value of the host computing device for the flag; and forwarding, by the one or more processors, the file path to an enclave manager outside the enclave for further forwarding to host software of the host computing device.

In one example, the file path indicates that the file is in a host access domain configured for handling non-sensitive data available and modifiable by other untrusted software running on the host computing device. In this example, the flag indicates that the file in the host access domain is handled as if in the secure access domain configured for handling encrypted and/or signed data. In addition or alternatively, the method also includes using the file path to determine whether to delegate the file operation to the host software. In another example, the method also includes using the enclave manager to request that the host software opens a file at the file path. In this example, the method also includes receiving, using the enclave manager, a file descriptor from the host software for the file and translating a value of the file descriptor from a native value of the host computing device for the file descriptor into a new value for use inside of the enclave. In addition, the method also includes using a registry to track a mapping between the native value for the file descriptor and the new value. In this example, translating the value of the file descriptor is based on the registry.

In another example, the method also includes using a registry to track a mapping between the native value for the flag and an pre-translation value of the flag for use within the enclave. In this example, translating the value of the flag is based on the registry. In addition or alternatively, the file path indicates that the file is in a secure access domain configured for handling encrypted and/or signed data. In addition or alternatively, the file path indicates that the file is in a virtual memory access domain not backed by persistent storage. In another example, the method also includes adding a prefix to the file path, and wherein the file path forwarded to the enclave manager is the prefixed file path. In another example, the host software includes a host operating system. In another example, the host software includes a host hypervisor. In another example, the method also includes generating the enclave manager outside of the enclave, and the enclave manager includes instructions for creating one or more enclaves. In another example, the method also includes generating the enclave in a system having an isolation kernel and isolation capable hardware. In another example, the method also includes generating the enclave in a system having hardware secure execution primitives and isolation capable hardware. In another example, the method also includes the enclave in a system having a hardware secure element. In another example, the method also includes generating the enclave in a system remote from the untrusted environment.

Another aspect of the disclosure provides a method for handling signals delivered from host software to an enclave stored in memory of a host computing device. The method includes receiving, by one or more processors of the host computing device, a signal at the enclave; in response to receiving the signal, mapping, by the one or more processors, a user-defined signal handler in the enclave to the received signal; sending, by the one or more processors, the mapping to an enclave manager outside of the enclave; generating, by the one or more processors, using the enclave manager instructions indicating that when the signal is received by the host software, the host software must send a host signal function into the enclave to find the user-defined signal handler in order to handle the signal inside of the enclave; and sending the instructions to the host software.

In one example, the method also includes using an enclave manager and the mapping to define a function for the user-defined signal handler outside of the enclave. In another example, the method also includes translating a host value for the signal to an enclave value for the signal for use when the signal is within the enclave. In this example, the translating also includes translating the host value for the signal to a bridge value for signal outside of the enclave and when the signal enters the enclave, translating the bridge value into an enclave value for use when the signal is within the enclave. In another example, the method also includes translating a host value for the signal to an enclave value for the signal for use when the signal is outside of the enclave. In this example, the translating also includes, before the signal is allowed to leave the enclave, translating the enclave value to a bridge value and when the signal has left the enclave, translating the bridge value into the host value for use when the signal is outside of the enclave.

In another example, the method also includes receiving, at the host software, the signal; in response to receiving the signal at the host software, using the instructions to identify the host signal function; and using the host signal function to find the user-defined signal handler in order to handle the signal inside of the enclave. In this example, if the user-defined signal handler is not found, ignoring the signal received at the host software. In another example, the signal is received at the enclave from outside of the enclave. In another example, the method also includes sending, by the enclave, the signal to the enclave manager in order to send the signal to a second enclave. In this example, the method also includes upon receipt of the signal at the enclave manager, using the enclave manager to forward a function to the host software, in response to receiving the function using the host software, interrupting code running in the second enclave and sending a signal to a signal manager of the second enclave to establish a secure channel with the enclave, and sending the signal to the second enclave over the secure channel. In this example, the method also includes finding the user-defined signal handler in order to handle the signal inside of the second enclave. In addition or alternatively, the method also includes, after the signal is handled, resuming the interrupted code.

In another example, the host software includes a host operating system. In another example, the host software includes a host hypervisor. In another example, the method also includes generating the enclave manager outside of the enclave, and the enclave manager includes instructions for creating one or more enclaves. In another example, the method also includes generating the enclave in a system having an isolation kernel and isolation capable hardware. In another example, the method also includes generating the enclave in a system having hardware secure execution primitives and isolation capable hardware. In another example, the method also includes generating the enclave in a system having a hardware secure element. In another example, the method also includes generating the enclave in a system remote from the untrusted environment.

The technology generally relates to a uniform enclave interface. Secured execution technologies may differ significantly from vendor to vendor in their backend implementations. For instance, enclaves may be supported by different application programming interfaces, applications, and system software (for instance, different operating systems) running on different types of hardware and/or machines. Therefore, for an application to take advantage of the protected environment of a particular secured execution technology backend, the application would need to be designed specifically for the particular secured execution technology, operating system, and in some instances, hardware, backend. The uniform enclave interface described herein implements an abstract set of security guarantees based on which the programmers or users may write software without taking account of how the secured technology is implemented on a particular backend implementation. In other words, the features described herein may be implemented using various different application programming interfaces, applications, and system software (for instance, different operating systems) running on different types of hardware and/or machines and effectively "hide" these details and differences from a user writing software using the uniform enclave interface.

The uniform enclave interface may provide a framework to enable code and data to be securely stored and/or run inside enclaves. The framework may include several basic components, such as an enclave manager, one or more enclave clients, and one or more trusted applications. The enclave manager may be in an untrusted environment and may be configured to create enclaves and enclave clients. The enclave clients may be configured to provide limited entry points for code to enter and exit the enclaves. The trusted applications may be base classes configured to allow users to augment with custom logic handling inside the enclave, resulting in trusted user application instances that can securely run inside the enclave.

Enclaves often are not implemented with a full-fledged operating system and therefore cannot complete certain tasks necessary for running trusted user application instances. In this regard, the uniform enclave interface may provide additional features to enable trusted user application instances to run securely inside the enclaves.

Thread creation and scheduling features may be implemented in the uniform enclave interface. In this regard, when a function inside an enclave requests a new thread, an enclave runtime may exit the enclave to request that the host create a new thread. A queue of new thread requests may be kept inside the enclave. After the host creates the new thread, the enclave runtime re-enters the enclave and waits for the new thread to also enter the enclave. Once the new thread enters the enclave, it checks the queue of new thread requests to execute the function that requested it. When the new thread returns from the function that requested it, it saves the return value and exits the enclave.

File operation features may also be implemented in the uniform enclave interface. In this regard, file paths are separated into access domains having different security properties. A file path may be designated with a path prefix to indicate that the file path belongs to a particular access domain. For example, for file paths in a host access domain containing non-sensitive data, an IO manager inside the enclave may delegate file operations on such file paths directly to the host. For another example, for file paths in a secure access domain containing encrypted or signed data, the IO manager may still delegate the file operations on such file paths to the host, but does not give the host access to cryptographic keys stored inside the enclave such that the host may not access decrypted/unsigned data. For yet another example, for file paths in a virtual memory device domain containing highly sensitive data, the IO manager may not delegate file operations on such file paths to the host at all, rather, the IO manager directly instructs CPU hardware to perform the file operations.

Signal handling features may also be implemented in the uniform enclave interface. In this regard, a framework is provided such that a user may register a signal and a user-defined signal handler for the signal inside the enclave. The signal is also registered on the host with a corresponding host signal handler configured to identify the enclave where the corresponding user-defined signal handler is, enter the enclave, and find and call the corresponding user-defined signal handler to handle the signal. In addition, for signals sent between two enclaves, a remote procedure call ("RPC") may be established between the two enclaves to ensure secure delivery even if the host is hostile.

<FIG> includes an example enclave system <NUM> in which the features described herein may be implemented. It should not be considered as limiting the scope of the disclosure or usefulness of the features described herein. In this example, enclave system <NUM> can include computing devices <NUM>, <NUM>, <NUM> and storage system <NUM> connected via a network <NUM>. Each computing device <NUM>, <NUM>, <NUM> can contain one or more processors <NUM>, memory <NUM> and other components typically present in general purpose computing devices.

Although only a few computing devices and a storage systems are depicted in the system <NUM>, the system may be expanded to any number of additional devices. In addition to a system including a plurality of computing devices and storage systems connected via a network, the features described herein may be equally applicable to other types of devices such as individual chips, including those incorporating System on Chip (SoC) or other chips with memory, that may include one or more enclaves.

Memory <NUM> of each of computing devices <NUM>, <NUM>, <NUM> can store information accessible by the one or more processors <NUM>, including instructions that can be executed by the one or more processors. The memory can also include data that can be retrieved, manipulated or stored by the processor. The memory can be of any non-transitory type capable of storing information accessible by the processor, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories.

The instructions can be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by the one or more processors. In that regard, the terms "instructions," "application," "steps," and "programs" can be used interchangeably herein. The instructions can be stored in object code format for direct processing by a processor, or in any other computing device language including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. Functions, methods, and routines of the instructions are explained in more detail below.

Data may be retrieved, stored or modified by the one or more processors <NUM> in accordance with the instructions. For instance, although the subject matter described herein is not limited by any particular data structure, the data can be stored in computer registers, in a relational database as a table having many different fields and records, or XML documents. The data can also be formatted in any computing device-readable format such as, but not limited to, binary values, ASCII or Unicode. Moreover, the data can comprise any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other memories such as at other network locations, or information that is used by a function to calculate the relevant data.

The one or more processors <NUM> can be any conventional processors, such as a commercially available CPU. Alternatively, the processors can be dedicated components such as an application specific integrated circuit ("ASIC") or other hardware-based processor. Although not necessary, one or more of computing devices <NUM> may include specialized hardware components to perform specific computing processes, such as decoding video, matching video frames with images, distorting videos, encoding distorted videos, etc. faster or more efficiently.

Although <FIG> functionally illustrates the processor, memory, and other elements of computing device <NUM> as being within the same block, the processor, computer, computing device, or memory can actually comprise multiple processors, computers, computing devices, or memories that may or may not be stored within the same physical housing. For example, the memory can be a hard drive or other storage media located in housings different from that of the computing devices <NUM>. Accordingly, references to a processor, computer, computing device, or memory will be understood to include references to a collection of processors, computers, computing devices, or memories that may or may not operate in parallel. For example, the computing devices <NUM> may include server computing devices operating as a load-balanced server farm, distributed system, etc. Yet further, although some functions described below are indicated as taking place on a single computing device having a single processor, various aspects of the subject matter described herein can be implemented by a plurality of computing devices, for example, communicating information over network <NUM>.

Each of the computing devices <NUM>, <NUM>, <NUM> can be at different nodes of a network <NUM> and capable of directly and indirectly communicating with other nodes of network <NUM>. Although only a few computing devices are depicted in <FIG>, it should be appreciated that a typical system can include a large number of connected computing devices, with each different computing device being at a different node of the network <NUM>. The network <NUM> and intervening nodes described herein can be interconnected using various protocols and systems, such that the network can be part of the Internet, World Wide Web, specific intranets, wide area networks, or local networks. The network can utilize standard communications protocols, such as Ethernet, WiFi and HTTP, protocols that are proprietary to one or more companies, and various combinations of the foregoing. Although certain advantages are obtained when information is transmitted or received as noted above, other aspects of the subject matter described herein are not limited to any particular manner of transmission of information.

Like the memory discussed above, the storage system <NUM> may also store information that can be accessed by the computing devices <NUM>, <NUM>, <NUM>. However, in this case, the storage system <NUM> may store information that can be accessed over the network <NUM>. As with the memory, the storage system can include any non-transitory type capable of storing information accessible by the processor, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories.

In this example, the instructions of each of computing devices <NUM>, <NUM>, <NUM> may include one or more applications. These applications may define enclaves <NUM>, <NUM>, <NUM>, <NUM> within memory, either locally at memory <NUM> or remotely at the storage system <NUM>. Each enclave may be "hosted" by the hardware on which the enclave is stored and the software, including operating system software, which is executed on the host computing device. For instance, computing device <NUM> may be a host computing device for enclaves <NUM> and <NUM>, and computing device <NUM> may be a host computing device of enclave <NUM>. In addition, each of enclaves <NUM>, <NUM>, <NUM> and <NUM> may be implemented using or on various different application programming interfaces, applications, and system software running on different types of machines (i.e. different types of computing devices). As an example, computing devices <NUM> and <NUM> may be different types of machines, running different applications and software with different security protocols, running different operating systems, using different hardware devices. Similarly, enclaves <NUM>, <NUM>, <NUM> and <NUM> may each be backed or created by different application programming interfaces and/or applications with different system configurations.

Each enclave can be used to store data and instructions while at the same time limit the use of such data and instructions by other applications. For instance the data may include sensitive information such as passwords, credit card data, social security numbers, or any other information that a user would want to keep confidential. And, as discussed further below, the instructions may be used to limit the access to such data. Although computing device <NUM> includes only two enclaves, computing device <NUM> includes only <NUM> enclave, computing device <NUM> includes no enclaves, and storage system <NUM> includes only <NUM> enclave, any number of enclaves may be defined with the memory of the computing devices <NUM>, <NUM> or storage system <NUM>.

<FIG> shows an example uniform enclave interface <NUM> for any of enclaves <NUM>, <NUM>, <NUM>, or <NUM>. Thus, the uniform enclave interface <NUM> may be implemented in a memory on a processor of a computing device, for example, such as in memory <NUM> of computing devices <NUM>, <NUM> or <NUM> shown in <FIG>. As shown, User Application <NUM> is running in an Untrusted Application Context <NUM>, which is vulnerable to manipulations by processes having higher privileges, such as an operating system or a hypervisor. However, the User Application <NUM> may have certain components that require greater protection than others. For example, the User Application may be a password manager application that has a key vault component. Such components may be stored and/or executed in enclaves, while other components of the application may be stored and/or executed in an untrusted environment or rather, outside of the enclave. In this regard, the User Application <NUM> may create an Enclave Manager <NUM> for the User Application <NUM> in the Untrusted Application Context <NUM>. The Enclave Manager <NUM> may include instructions for creating one or more enclaves and may be implemented in any of a number of different ways, for example, as object code running in a single process, as code stored in a library, or as an RPC service.

The Enclave Manager <NUM> may create one or more enclaves, such as Trusted Enclave <NUM> of N <NUM> and Trusted Enclave M or N <NUM>, where N is the total number of enclaves generated by the Enclave Manager <NUM>. In each of the enclaves created by the Enclave Manager <NUM>, a trusted application instance, such as Trusted Application Instance <NUM> and Trusted Application Instance <NUM>, may be stored and/or executed. For example, Trusted Application Instance <NUM> and Trusted Application Instance <NUM> may be two different sets of codes that stores and/or executes sensitive data of User Application <NUM>, or copies of the same code that stores and/or executes sensitive data of User Application <NUM>.

The framework provided by the uniform enclave interface may define an abstraction that allows users to concretize with specific instructions. In this regard, the uniform enclave interface may define a "Trusted Application," which is the base class for all user enclaves, such as Trusted Enclave <NUM> of N <NUM> and Trusted Enclave M or N <NUM>. Users of the uniform enclave interface can then extend this abstract base class by augmenting with custom logic handling to create "Trusted User Applications" that perform specific functions defined by the user. For example, Trusted Application Instance <NUM> and Trusted Application Instance <NUM> are trusted user applications defined by the user using the Trusted Application abstract base class.

The Enclave Manager <NUM> may create Trusted Enclave <NUM> of N <NUM> and Trusted Enclave M of N <NUM> on the same backend, on two backends of a same type, or on two backends of different types. In this regard, the enclave manager may have features that enable implementation of enclaves across multiple different and/or different types of backends. For instance, the Enclave Manager <NUM> may be configured to bind enclaves to identifiers or names in a namespace. For example, the Enclave Manager <NUM> may bind each enclave instance it creates, such as Trusted Enclave <NUM> of N <NUM> and Trusted Enclave M of N <NUM>, to a name in a common, hierarchical namespace. This way, a uniform reference may be made to loaded enclaves regardless of differences in enclave identifiers due to particular implementations. For another instance, since not all backends make available all platform resources to an enclave, the enclave manager may also provide platform services to enclaves. For example, the Enclave Manager <NUM> may implement a clock via software for an Intel SGX backend, since a high-frequency hardware clock is not provided by Intel SGX.

The Enclave Manager <NUM> may also generate one or more enclave clients to provide entry points for code to enter and exit the enclaves. Enclave clients are handles that allow code to run in an enclave. As shown, Enclave Manager <NUM> creates Enclave Client J of K <NUM> to provide entry points for Trusted Enclave <NUM> of N <NUM>, and Enclave Client <NUM> of K <NUM> to provide entry points for Trusted Enclave M of N <NUM>, where K is the total number of enclave clients generated by the Enclave Manager <NUM>. Both Enclave Client J of K <NUM> and Enclave Client <NUM> of K <NUM> are in the Untrusted Application Context <NUM>, and provide an interface between the User Application <NUM> and Trusted Application Instance <NUM> and Trusted Application Instance <NUM>.

The entry points may include any number of different functions, such as "enter and initialize," "enter and finalize," "enter and run," "enter and donate thread," "enter and handle signal," and "enter and destroy. " As such, these functions, such as "enter and run," "enter and donate thread," etc. may be interfaces of one or more enclave clients generated by an Enclave Manager, such as an Enclave Manager <NUM>. For instance, Enclave Client J of K <NUM> may use "enter and initialize" to send code into Trusted Enclave <NUM> of N <NUM> to take system resources required to run the Trusted Application Instance <NUM>, and to provide configuration data to the Trusted Enclave <NUM> of N <NUM>. Enclave Client J of K <NUM> may use "enter and finalize" to relinquish let go of the system resources in Trusted Enclave <NUM> of N <NUM> that is no longer needed. Enclave Client J of K <NUM> may use "enter and run" to execute functions of the Trusted Application Instance <NUM>. Enclave Client J of K <NUM> may use "enter and donate thread" to have the operating system provide a thread to enter into the Trusted Enclave <NUM> of N <NUM>. When the Trusted Application Instance <NUM> wants to send a signal (for instance to another enclave, a particular thread within the enclave, a process outside of the enclave, to the signal's own thread, etc.), or when a signal is sent to the Trusted Application Instance <NUM>, Enclave Client J of K <NUM> may use "enter and handle signal" to handle the signal. When Enclave Client J of K <NUM> is no longer needed, Enclave Client J of K <NUM> may use "enter and destroy" to terminate Trusted Enclave <NUM> of N <NUM>. The actual implementation details of such functions may be specific to the features of the backend in which the enclave is operating.

As noted above, the uniform enclave interface <NUM> may be used for enclaves implemented across any of a number of different types of application programming interfaces, applications, and system software (for instance, different operating systems) running on different types of machines. As such, the uniform enclave interface may also support any number of different types of security architectures and system configurations, such as the example configurations shown in <FIG>. For example, Trusted Enclave <NUM> of N <NUM> and Trusted Enclave M of N <NUM> may be implemented as Trusted Enclave <NUM> shown in any of <FIG>. In addition, trusted enclave <NUM> may represent any of enclaves <NUM>, <NUM>, <NUM> and <NUM>. Each of the example system configurations may be implemented on a computing device, for example, such as computing device <NUM> shown in <FIG>.

<FIG> shows an example system configuration 300A. An Untrusted User Application <NUM> is running in Untrusted User Space <NUM>. Since Untrusted User Space <NUM> is on Ring <NUM> and Untrusted Operating System <NUM> is on Ring <NUM>, the Untrusted Operating System <NUM> has higher privileges and therefore would be able to manipulate Untrusted User Application <NUM>. To prevent the Untrusted Operating System <NUM> from accessing certain sensitive data of the Untrusted User Application <NUM>, a Trusted Enclave <NUM> is created. In this regard, an Isolation Kernel <NUM> uses Isolation Capable Hardware <NUM> to isolate system resources for Trusted Enclave <NUM>. The Isolation Kernel <NUM> is a Hypervisor on Ring -<NUM>, which could control Ring <NUM> hardware access. For example, hardware features such as virtualization support (for instance, Intel VMX or AMD-V) may be used.

<FIG> shows an example system configuration 300B. Untrusted User Application <NUM> is running in Untrusted User Space <NUM> (Ring <NUM>), and to prevent the Untrusted Operating System <NUM> (Ring <NUM>) from accessing certain sensitive data of the Untrusted User Application <NUM>, a Trusted Enclave <NUM> is created. In the example system configuration 300B, however, Hardware Secure Execution Primitives <NUM> use Isolation Capable Hardware <NUM> to isolate system resources for Trusted Enclave <NUM>. For example, Hardware Secure Execution Primitives <NUM> could be or include Intel SGX or ARM TrustZone.

<FIG> shows an example system configuration 300C. Untrusted User Application <NUM> is shown running in Untrusted User Space <NUM> (Ring <NUM>), and to prevent the Untrusted Operating System <NUM> (Ring <NUM>) from accessing certain sensitive data of the Untrusted User Application <NUM>, a Trusted Enclave <NUM> is created. The example system configuration 300C is implemented using a Hardware Secure Element <NUM> that is physically separate from Untrusted Hardware <NUM>. For instance, this example backend may be implemented using an embedded secure system-on-a-chip co-processor.

<FIG> shows an example system configuration 300D. Untrusted User Application <NUM> is running in Untrusted User Space <NUM> (Ring <NUM>), and to prevent the Untrusted Operating System <NUM> (Ring <NUM>) from accessing certain sensitive data of the Untrusted User Application <NUM>, a Trusted Enclave <NUM> is created. In this example, the Trusted Enclave <NUM> is implemented on a Trusted Execution Environment <NUM> that is remote from Untrusted Hardware <NUM>. For instance, the Trusted Execution Environment <NUM> may be located on a trusted computing device in a network.

Enclaves often are not implemented with a full-fledged operating system and therefore cannot complete certain tasks necessary for running a trusted application instance inside an enclave. For example, an application programming interface of the backend may not be able to implement CPU scheduling or resource allocation. Thus, the enclave must rely on the untrusted host software, such as an operating system or hypervisor, for certain tasks. One way to accomplish this is to incorporate a scheduler code in the enclave, but this would overcomplicate the enclave, which would increase an attack surface at the enclave's boundary.

<FIG> shows an example timing diagram <NUM> for handling threads of execution without overcomplicating the enclave or increasing the attack surface, where the arrows represent the flow of data, message, or information between various components. The example operations shown in <FIG> may be performed by one or more processors of a host computing device for an enclave, such as enclaves <NUM>, <NUM>, <NUM> and <NUM> and one or more processors <NUM> of the computing devices <NUM>, <NUM>, <NUM>.

<FIG> shows various threads created by host software, here an Operating System <NUM>, Thread A <NUM> and Thread B <NUM>, inside and outside of an Enclave <NUM> (dashed-line box). In this example, enclave <NUM> may represent any of enclaves <NUM>, <NUM>, <NUM> and <NUM>. As such, enclave <NUM> may be implemented on any of a number of different types of backends and system configurations, for example, such as the example system configurations for Trusted Enclave <NUM> shown in <FIG>. As described above with respect to <FIG>, an enclave, such as Enclave <NUM>, may have entry points through which code, such as Thread A <NUM> and Thread B <NUM>, may enter and exit.

Events of the operations of <FIG> are shown in an example chronological order from top to bottom. Starting from the top of the diagram, Thread A <NUM>, which requires the functionality of enclave <NUM> to accomplish some task, enters the Enclave <NUM> via entry point "EnterAndRunQ. " Once inside the Enclave <NUM>, Thread A may trigger additional processes. For instance, in Enclave <NUM> receives a request from the application running inside the Enclave <NUM> for a new thread of execution for one of its functions. As shown, the application made the request by calling "pthread_create()" with a "start_routine. " A queue of "start_routine" requested by various functions may be created, updated, and otherwise maintained by runtime functionality of the Enclave <NUM> as metadata in the enclave. The runtime functionality for Enclave <NUM> may also use metadata of the enclave to track which function the application inside the Enclave <NUM> is requesting a thread for, the function's argument, and a return value. The metadata may also store information such as waiting to execute, running, returned, or joined in order to track the status of the thread. Such thread status metadata may thus allow the application running inside of Enclave <NUM> to use POSIX threading APIs to wait for a thread and gets the thread's return value. For instance, "host_donate_thread return" may be the return value for an existing call in <FIG>.

Thread A in Enclave <NUM> then exits the Enclave <NUM> via exit point "host_donate_thread()", for instance, making a call to request the Operating System <NUM> for a new thread. Once outside the Enclave <NUM>, Thread A <NUM> requests Operating System <NUM> to create a thread by calling "pthread_create(). " A return value is represented by "pthread_create return". The Operating System <NUM> responds by sending the return value to Thread A <NUM> and creates a new thread, Thread B <NUM>, outside the Enclave <NUM>.

After learning from "pthread_create return" ("return from pthread_create()")that a new thread, Thread B <NUM>, has been created by the Operating System <NUM>, Thread A <NUM> re-enters the Enclave <NUM> to wait for Thread B <NUM> to also enter the Enclave <NUM>. Once Thread B <NUM> enters Enclave <NUM> via entry point "donate_thread()," Thread B in Enclave <NUM> checks the "start_routine" queue and executes the function in the queue that requested it (i.e. requested a new thread that is now Thread B). In addition, Thread B <NUM> entering Enclave <NUM> also triggers the removal of the function from the queue (and/or the request for a new thread, now Thread B, from the queue). Once Thread B in Enclave <NUM> finishes executing the function requested of it, Thread B in Enclave <NUM> saves the return value and then exits the Enclave <NUM> (not shown).

If, upon entering Enclave <NUM>, Thread B in Enclave <NUM> found that the "start_routine" queue is empty, Thread B in Enclave <NUM> then would either leave the Enclave <NUM> and return to some location where it is needed outside the Enclave or tear down the Enclave <NUM> due to an unexpected condition, such as when the queue is empty.

Applications operating inside an enclave commonly must save state in order to be effective, but the enclave does not have direct access to any persistent hardware and the host, such as an operating system or hypervisor, is not trusted to securely persist sensitive data on the enclave's behalf. Further, applications running in the enclave may not have been written with an adversarial host in mind, and therefore security requirements of individual data persistence operations may need to be inferred based on context. To reduce the attack surface at the enclave's boundary, instead of including file system implementation in the enclave, the example features described herein selectively delegate file operations to the host, such as an operating system or hypervisor, and provide additional protections by the enclave as needed.

In this regard, file paths are separated into access domains having different security properties. The access domains may be configured during initialization of the enclave. A file path may be designated with a path prefix to indicate that the file path belongs to a particular access domain. All file paths having the same path prefix belong to the same access domain, unless the path prefix is superseded by a more specific prefix for another access domain.

Likewise for directories, the same security properties can be maintained for all members of one directory recursively. The access domains may be nested within each other by having a path with another access domain as a directory ancestor, in which case the descendent access domain does not inherit security properties from the ancestor. For instance, for a given access domain at "/ABC" and another one at "/ABC/123r", these directories are nested. However, the access domains may not be related in any meaningful way: the fact that "/ABC/<NUM>" shares part of its prefix with "/ABC" does not mean that it inherits any of the properties of "/ABC").

<FIG> show example timing diagrams 500A-C for handling various types of files, where the arrows represent the flow of data, message, or information between various components. The example operations shown in <FIG> may be performed by one or more processor of a host computing device for an enclave, such as enclaves <NUM>, <NUM>, <NUM> and <NUM> and the one or more processors <NUM> of the computing devices <NUM>, <NUM>, <NUM>. <FIG> show an Enclave <NUM> (dashed-line box) having an IO Manager <NUM> responsible for delegation of file operations. In this example, enclave <NUM> may represent any of enclaves <NUM>, <NUM>, <NUM> and <NUM>. As such, enclave <NUM> may be implemented on any of a number of different types of backends or system configurations, such as the example system configurations for Trusted Enclave <NUM> shown in <FIG>. As described above with respect to <FIG>, an enclave, such as Enclave <NUM>, may have entry points through which code may enter and exit.

<FIG> shows example file operations for a host access domain. A host access domain may be configured for handling non-sensitive data that is expected to be available and modifiable by other untrusted software running within the host computing device and host software, for instance, operating system or hypervisor. Events of the example operations of <FIG> are shown in an example chronological order from top to bottom.

The first file operation shown is an open operation. Initially, the CPU is executing code, here Thread <NUM>, inside of Enclave <NUM>. Inside the Enclave <NUM>, an application of the Enclave User Code <NUM> requests to open a file at file path "/insecure/file. " The request reaches and initiates the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to an IO Manager <NUM> within the Enclave <NUM>, which is responsible for deciding whether to delegate the file operations to the Host Operating System <NUM>. The IO Manager <NUM> looks up the file path "/insecure/file," determines that the file path indicates that the file is in the host access domain and may add a path prefix to the file path.

The file path may also include flags for the POSIX calls, like open, that may include additional arguments that tell it to open the file read-only/read-write/etc or whether to create the file if it doesn't exist, etc. However, across different backends, the values of those flags (e.g., is read-write a "<NUM>" or a "<NUM>") can vary, so translation needs to occur. As such, the IO Manager <NUM> then translates any flag, which may be different for different backends (i.e. different application programming interfaces, etc.), into corresponding host or native values of the Host Operating System <NUM> ("NATIVE" or Host Access Domain), and delegates the open operation to the Host Operating System <NUM> using the native values. This enables the IO Manager <NUM> to function like a virtual filesystem.

Next, the IO Manager <NUM> passes on the prefixed path to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then requests the Host Operating System <NUM> to open the file at the prefixed file path. The Host Operating System <NUM> opens the file and returns a file descriptor "hostFD" to the Enclave Manager <NUM>. The Enclave Manager <NUM> then returns hostFD from the open file call.

The IO Manager may maintain a registry or mapping of host file descriptors, internal file descriptors (that is, file descriptors to be used inside of the enclave) and other information. For instance, when the IO Manager, registers hostFD, the IO Manager also creates a mapping between the host file descriptor (hostFD) and its own set of file descriptors (in this case, fd). In this regard, all interactions with the file descriptor inside of the enclave is according to the IO Manager's mapping (i.e. hostFD is used outside of the enclave and hostFD is referred to as fd inside the enclave). As such, the file descriptor "fd" is then passed back to the POSIX Layer <NUM> and then to the Enclave User Code <NUM>.

The second file operation shown is a read operation. An application of the Enclave User Code <NUM> requests to read the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd ("lookupFD(fd)") in the mapping (i.e. hostFD), delegates the read operation to the Host Operating System <NUM>, and translates any flag into native values of the Host Operating System <NUM>. Next, the IO Manager <NUM> passes on the file descriptor hostFD to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then requests the Host Operating System <NUM> to read the file with the file descriptor hostFD. The Host Operating System <NUM> reads the file and returns data read from the file to the Enclave Manager <NUM>. The Enclave Manager <NUM> passes the data to the IO Manager <NUM> inside the Enclave <NUM>, which in turn passes the data back to the POSIX Layer <NUM>, and the POSIX Layer <NUM> passes the data back to the Enclave User Code <NUM>.

The third file operation shown is a close operation. An application of the Enclave User Code <NUM> requests to close the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd, delegates the close operation to the Host Operating System <NUM>, and translates any flag into native values of the Host Operating System <NUM>. The IO Manager <NUM> also deregisters the file with file descriptor fd. Next, the IO Manager <NUM> passes on the file descriptor hostFD to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then requests the Host Operating System <NUM> to close the file with the file descriptor hostFD. The Host Operating System <NUM> then closes the file.

<FIG> shows example file operations for a secure access domain. A secure access domain may be configured for handling encrypted or signed data. The host need not be trusted for handling such encrypted or signed data because only the enclave has the necessary keys, thus the untrusted host only has access to the data in the encrypted/signed form. Events of the example operations are shown in <FIG> in am example chronological order from top to bottom.

The first file operation shown is an open operation. Initially, the CPU is executing code, here Thread <NUM>, inside of Enclave <NUM>. Inside the Enclave <NUM>, an application of the Enclave User Code <NUM> requests to open a file at file path "/secure/file. " The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager looks up the file path "/secure/file," determines that the file path indicates that the file is in the secure access domain ("SECURE"), and adds a file prefix to the file path. The IO Manager <NUM> then translates any flag into native values of the Host Operating System <NUM>, and delegates the open operation to the Host Operating System <NUM> using the native values. Next, the IO Manager <NUM> passes on the prefixed file path to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then passes the prefixed path to the Host Operating System <NUM> to open the file. The Host Operating System <NUM> opens the file and returns a file descriptor hostFD to the Enclave Manager <NUM>. IO Manager <NUM> then registers the file descriptor hostFD and stores to the mapping, as discussed above, the file descriptor fd. The file descriptor fd is then passed back to the POSIX Layer <NUM> and then to the Enclave User Code <NUM>.

The second file operation shown is a read operation. An application of the Enclave User Code <NUM> requests to read the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd ("lookupFD(fd)") in the mapping (i.e. hostFD), delegates the read operation to the Host Operating System <NUM>, and translates any flag into native values of the Host Operating System <NUM>. Next, the IO Manager <NUM> passes on the file descriptor hostFD to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then requests the Host Operating System <NUM> to read the file with the file descriptor hostFD. The Host Operating System <NUM> reads the file and returns encrypted data read from the file to the Enclave Manager <NUM>. Since the encryption key is located only inside the Enclave <NUM>, the Host Operating System <NUM> would not be able to read the original data. The Enclave Manager <NUM> then passes the encrypted data to the IO Manager <NUM> inside the Enclave <NUM>. Once inside the Enclave <NUM>, the IO Manager <NUM> decrypts the encrypted data with the encryption key inside the Enclave <NUM> and passes the decrypted data back to the POSIX Layer <NUM>, which the POSIX Layer <NUM> passes to the Enclave User Code <NUM>. In this regard, encrypted and/or signed data is persisted by creating mirror operations, such that where there is a read operation in the host domain, there is a corresponding read operation in the enclave.

The third file operation shown is a close operation. An application of the Enclave User Code <NUM> requests to close the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd ("lookupFD(fd)") in the mapping (i.e. hostFD) in order to translate from the enclave value to the native value of the host Operating System <NUM> and delegates the read operation to the Host Operating System <NUM> using the native value. The IO Manager <NUM> also deregisters the file with file descriptor fd. Next, the IO Manager <NUM> passes on the file descriptor hostFD (i.e. the native value) to the Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then requests the Host Operating System <NUM> to close the file with the file descriptor hostFD. The Host Operating System <NUM> closes the file. Additionally or alternatively, files in the host access domain can also be treated with similar security properties as files in the secure access domain by specifying a flag with the file operation. For example, in <FIG>, if the file in the host access domain was opened with a flag O_SECURE, the file would be treated the same way as shown in <FIG>. This may allow a user to specify at the time of "open" whether a file is secure rather than when the enclave is create. <FIG> shows example operations for a virtual memory access domain representing memory that is not backed by persistent storage and does not involve the host operating system at all. A virtual memory access domain may be configured for handling highly sensitive data intended to be protected by the enclave and not accessible by the untrusted world, including the host. The virtual memory access domain provides virtual devices at standard paths for data generation. This virtual memory may be implemented completely within the enclave, with no delegation or mirror operations to the host. For example, the virtual memory may be used to perform random number generation, which may be useful as because instructions to the CPU may be required to provide the needed entropy for cryptographic-grade random data. The virtual devices may also be used to generate other data, for example completely zeroed data, where deviations from expectations on the data could have dire security consequences. Events of the example operations of <FIG> are shown in an example chronological order from top to bottom.

The first file operation shown is an open operation. Initially, the CPU is executing code, here Thread <NUM>, inside of the enclave <NUM>. Inside the Enclave <NUM>, an application of the Enclave User Code <NUM> requests to open a file at file path "/dev/random. " The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file path "/dev/random" and determines that the file path indicates that the file is in the virtual memory access domain ("MEMORY"). Recognizing that highly sensitive data is being handled, the IO Manager <NUM> does not delegate any operation to the Host Operating System <NUM> or create any mirror operations to the Host Operating System <NUM>, but simply registers the file as internal in the mapping as described above, and returns file descriptor fd to the POSIX Layer <NUM>. The POSIX Layer <NUM> in turn passes the file descriptor fd back to the Enclave User Code <NUM>.

The second file operation shown is a read operation. An application of the Enclave User Code <NUM> requests to read the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd and determines that the file descriptor indicates that the file is in the virtual memory access domain. Recognizing that highly sensitive data is being handled, the IO Manager <NUM> does not delegate any operation to the Host Operating System <NUM> or create any mirror operations to the Host Operating System <NUM>. Rather, the IO Manager sends a request for a random number ("RDRAND") to be generated directly to the CPU Hardware <NUM>. The CPU Hardware <NUM> generates secure random data and directly sends the secure random data back to the IO Manager <NUM> in the Enclave <NUM>. This way, the untrusted Host Operating System <NUM> cannot manipulate the secure random data. The IO Manager <NUM> then passes the secure random data to the POSIX Layer <NUM>, which the POSIX Layer <NUM> passes to the Enclave User Code <NUM>.

The third file operation shown is a close operation. An application of the Enclave User Code <NUM> requests to close the file with file descriptor fd. The request reaches the POSIX Layer <NUM> within the Enclave <NUM>. The POSIX Layer <NUM> then passes on the request to the IO Manager <NUM> within the Enclave <NUM>. The IO Manager <NUM> looks up the file descriptor fd and determines that the file descriptor indicates that the file is in the memory device access domain. Recognizing that highly sensitive data is being handled, the IO Manager <NUM> does not delegate any operation to the Host Operating System <NUM> or create any mirror operations to the Host Operating System <NUM>, but simply deregisters the file as internal, and nothing is returned o the POSIX Layer <NUM>. Thus, the POSIX Layer <NUM> passes nothing to the Enclave User Code <NUM>.

Although <FIG> show single path based file operations, the operations shown are may also be applicable to multiple path based operations. Signals may provide ways to deliver asynchronous events to a process of a thread. A signal can be sent from a kernel to a process, from a process to another process, or from the process to itself. For example, a Linux kernel implements a plurality of different types of signals signals where users are able to implement their own signal handlers for all except SIGKILL and SIGSTOP. However, in the case of enclaves, wherein there is no operating system, when a signal arrives, the thread/process that runs the enclave is interrupted, and the operating system's default handler will be called, which usually terminates the application in the enclave without the enclave being aware of the signal. Further, containers (such as Nginx, Redis, MySQL) may register their own signal handler in the source code, but would not be able to run in an enclave where signals are not available. Although some software packages (such as Intel SGX, SDK) have built-in signal handling for a few signals, they are not extensible to new signals other than those already supported.

As such, the example systems described herein provide a framework that implements signals inside an enclave so that users could register their own signal handler or ignore certain signals inside the enclave, just as they could if the application is running directly on the host. The example systems maintain a mapping between registered signals and registered handlers inside the enclave. A signal handler registered by a user is stored as a signal handler inside the enclave. Meanwhile, a function that enters the enclave and calls the corresponding signal handler in the enclave is registered as a host signal handler on the host. Thus, when a signal arrives, the host signal handler is called by the host operating system to identify the right enclave to enter, enter the boundary of that enclave, and then find and call the registered signal handler inside the enclave.

<FIG> show example timing diagrams 600A-C for handling signals, where the arrows represent the flow of data, message, or information between various components. The example operations shown in <FIG> may be performed by one or more processors of a host computing device for an enclave, such as enclaves <NUM>, <NUM>, <NUM> and <NUM> and the one or more processors <NUM> of the computing devices <NUM>, <NUM>, <NUM>. <FIG> show an Enclave <NUM> (dashed-line box) having a Signal Manager <NUM> inside that keeps a mapping of signals. In this example, enclave <NUM> may represent any of enclaves <NUM>, <NUM>, <NUM> and <NUM>. As such, enclave <NUM> may be implemented on any of a number of different types of backends and system configurations, for example, such as the example system configurations for Trusted Enclave <NUM> shown in <FIG>. As described above with respect to <FIG>, an enclave, such as Enclave <NUM>, may have entry points through which code may enter and exit.

<FIG> shows example operations when a signal handler is registered. Events of the example operations are shown in an example chronological order from top to bottom. Initially, the CPU is running code, such as Thread <NUM>, inside of the Enclave <NUM>. A user defines a signal handler function "myhandler" in the Enclave User Code <NUM> inside the Enclave <NUM>. The handler may be called using the POSIX API "sigaction ()" such that, when a signal "SIGUSR1" is received, "myhandler" is the user-defined routine that handles SIGUSR1. The signal SIGUSR1 and its user-defined signal handler myhandler are then registered in a registry of the POSIX Layer <NUM>. This mapping of SIGUSR1 to myhandler is then stored in the Signal Manager <NUM>. The Host Operating System <NUM> also needs to know this mapping so that it knows that SIGUSR1 should be handled inside the Enclave <NUM>. In this regard, Signal Manager <NUM> sends the registration of SIGUSR1 to Enclave Manager <NUM> outside the Enclave <NUM>. The Enclave Manager <NUM> then defines a corresponding function "signalHandler" and calls "sigaction ()" in the Host Operating System <NUM> instructing the Host Operating System <NUM> that, if signal SIGUSR1 is received, the Host Operating System <NUM> should send a host signal function "enclaveHandler" into the Enclave <NUM> to find the myhandler function to handle SIGUSR1.

However, signals may be defined differently across different platforms, and may also be defined differently inside the enclave by the user as compared to by the host. Thus, a user who registers one signal number or value inside the enclave may end up registering a completely different signal number or value on the host. For instance, SIGURS <NUM> may have a value of <NUM> inside of the enclave and a value of <NUM> outside of the enclave. To avoid this problem, as in the examples above, the native values may be translated to enclave values. As an example, register(SIGUSR1) call may invoke translation from the enclave value of SIGUSR1 to the native value of SIGUSR1, and a deliverSignal(SIGUSR1) call may invoke translation from native value of SIGUSR1 to the encalve value of SIGUSR1. In other words, the signal value may also be translated between values native to the host operating system and native to the client. In some instances, a bridge value may be used such that every time a user registers a signal, it may be translated to this bridge value before exiting the enclave. Once outside the enclave, the bridge value may be translated into a corresponding host value before it is registered on the host. Likewise, when a signal arrives at the enclave, it may be first translated into the bridge value before entering the enclave, and once inside the enclave, the bridge value may be translated into a corresponding enclave value.

<FIG> shows example signal handling operations of a signal delivered from the host to the enclave. Events of the example operations of <FIG> are shown in an example chronological order from top to bottom. Initially, while CPU is running an application using Thread #<NUM><NUM>, another application running Thread #<NUM><NUM> wants to send a signal SIGUSR1 to Thread #<NUM>. The Host Operating System <NUM> interrupts an application in the Enclave User Code <NUM>, but also determines that the function enclaveHandle was registered on the host to handle SIGUSR1. The enclaveHandle then informs Enclave Manager <NUM> that it is an exception handler and enters the Enclave <NUM> to deliver information of the signal SIGUSR1 to the Signal Manager <NUM> inside the Enclave <NUM> and to find the user-defined signal handler myhandler to handle SIGUSR1. If, however, enclaveHandle does not find any signal handler registered by the user to handle SIGUSR1 in the Enclave <NUM>, SIGUSR1 would be ignored.

Once inside the Enclave <NUM>, the Signal Manager <NUM> and finds that myhandler is registered by the user to handle SIGUSR1. The function myhandler then calls myhandler in the Enclave User Code <NUM> to handle SIGUSR1. After SIGUSR1 is handled, the Host Operating System <NUM> then resumes the application in the Enclave User Code <NUM>.

<FIG> shows example signal handling operations of a signal delivered from one enclave to another enclave. In contrast to the example in <FIG>, where the signal sent originated from outside the Enclave <NUM> and therefore cannot be trusted, <FIG> shows an example when a signal originated from inside one enclave is to be sent to another enclave. Because both enclaves are secure from manipulations by the untrusted host, such a signal can be trusted if a trustworthy signal delivery mechanism is set up. In this regard, <FIG> shows that a secure connection, for instance via RPC, may be established between the two enclaves to ensure secure delivery.

Events of the example operations of <FIG> are shown in an example chronological order from top to bottom. Initially, while CPU is running an application on Thread #<NUM><NUM>, another application running Thread #<NUM><NUM> wants to send a signal SIGUSR1 to the enclave <NUM> which is running on Thread #<NUM>. For instance, the function kill() may be a POSIX interface that sends a signal ("SIGURS1") to a process ("enclave1", here Enclave <NUM>). The signal SIGUSR1, which originated from Enclave User Code <NUM> in a Second Enclave <NUM> (dashed-line box), is directed for Enclave <NUM>. The Second Enclave <NUM>, like Enclave <NUM>, may be implemented on any of a number of different types of backends, for example, such as the example backends for Trusted Enclave <NUM> shown in <FIG>. In this example and for ease of representation, the enclaves may share a single enclave manager, though multiple enclave managers may also be utilized.

The signal reaches POSIX Layer <NUM> of the Second Enclave <NUM>, and then tells the Signal Manager <NUM> of the Second Enclave <NUM> to send the signal to the Enclave <NUM>. The Signal Manager <NUM> of the Second Enclave <NUM> then forwards the signal to the Enclave Manager <NUM>. The Enclave Manager <NUM> forwards the kill function, now directed to a specific thread ("thread1") rather than a process or enclave, to the Host Operating System <NUM>. The Host Operating System <NUM> interrupts Enclave User Code <NUM> of the Enclave <NUM>. However, instead of passing on the signal SIGUSR1, the Host Operating System <NUM> is hostile and sends a signal SIGWRONG to the Signal Manager <NUM> of the Enclave <NUM>.

The Signal Manager <NUM> of the Enclave <NUM> looks up SIGWRONG and may establish a secure channel, for instance via RPC, with the Signal Manager <NUM> of the Second Enclave <NUM>. Over the established RPC, the Signal Manager <NUM> of the Second Enclave <NUM> sends the signal SIGUSR1 to the Signal Manager <NUM> of the Enclave <NUM>. The Signal Manager <NUM> of the Enclave <NUM> then calls the user defined signal handler myhandler in the Enclave User Code <NUM> to handle SIGUSR1. After SIGUSR1 is handled, the Host Operating System <NUM> then resumes the application in the Enclave User Code.

Claim 1:
A method for creating trusted applications stored in memory (<NUM>) of a host computing device (<NUM>), the method comprising:
creating, by one or more processors (<NUM>) of the host computing device (<NUM>), an enclave manager (<NUM>) in an untrusted environment of the host computing device (<NUM>), the enclave manager (<NUM>) including instructions for creating one or more enclaves (<NUM>, <NUM>, <NUM>, <NUM>), wherein the enclave manager (<NUM>) is created by an application that is running in the untrusted environment and implemented on the one or more processors (<NUM>), wherein the untrusted environment is vulnerable to manipulations by processes having higher privileges than the application;
generating, by the one or more processors (<NUM>), an enclave in memory (<NUM>) of the host computing device (<NUM>) using the enclave manager (<NUM>);
generating, by the enclave manager (<NUM>) implemented on the one or more processors (<NUM>), one or more enclave clients (<NUM>, <NUM>) of the enclave, the one or more enclave clients (<NUM>, <NUM>) configured to provide one or more entry points into the enclave, wherein the entry points comprise entry points that are arranged for entering code into enclave and for exiting code from the enclave; and
creating, by the one or more processors (<NUM>), one or more trusted application instances (<NUM>, <NUM>), of said application, in the enclave.