REDUCING LATENCY OF HARDWARE TRUSTED EXECUTION ENVIRONMENTS

TECHNICAL FIELD

The subject matter disclosed herein generally relates to hardware trusted execution environments (TEEs). Specifically, the present disclosure addresses systems and methods for reducing latency of hardware TEEs.

BACKGROUND

Hardware privilege levels may be used by a processor to limit memory access by applications running on a device. An operating system runs at a higher privilege level and can access all memory of the device and define memory ranges for other applications. The applications, running a lower privilege level, are restricted to accessing memory within the range defined by the operating system and are not able to access the memory of other applications or the operating system. However, an application has no protection from a malicious or compromised operating system.

A TEE is enabled by processor protections that guarantee that code and data loaded inside the TEE is protected from access by code executing outside of the TEE. Thus, the TEE provides an isolated execution environment that prevents, at the hardware level, access of the data and code contained in the TEE from malicious software, including the operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings.

FIG. 1 is a network diagram illustrating a network environment suitable for servers providing functions as a service using TEEs, according to some example embodiments.

FIG. 2 is a block diagram of a function-as-a-service server, according to some example embodiments, suitable for reducing latency of TEEs according to some example embodiments.

FIG. 3 is a block diagram of prior art ring-based memory protection.

FIG. 4 is a block diagram of enclave-based memory protection, suitable for reducing latency of TEEs according to some example embodiments.

FIG. 5 is a block diagram of a database schema, according to some example embodiments, suitable for use in reducing latency of TEEs.

FIG. 6 is a block diagram of a sequence of operations performed in building a TEE, according to some example embodiments.

FIG. 7 is a flowchart illustrating operations of a method suitable for initializing and providing access to TEEs, according to some example embodiments.

FIG. 8 is a flowchart illustrating operations of a method suitable for initializing and providing access to TEEs, according to some example embodiments.

FIG. 9 is a flowchart illustrating operations of a method suitable for initializing and providing access to TEEs, according to some example embodiments.

FIG. 10 is a block diagram showing one example of a software architecture for a computing device.

FIG. 11 is a block diagram of a machine in the example form of a computer system within which instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION

Example methods and systems are directed to reducing latency in providing TEEs. In the most general sense, a TEE is any trusted execution environment, regardless of how that trust is obtained. However, as used herein, TEEs are provided by executing code within a portion of memory protected from access by processes outside of the TEE, even if those processes are running at an elevated privilege level. Example TEEs include enclaves created by Intel® Software Guard Extensions (SGX) and trust domains created by Intel® Trust Domain Extensions (TDX).

TEEs may be used to enable the secure handling of confidential information by protecting the confidential information from all software outside of the TEE. TEEs may also be used for modular programming, wherein each module contains everything necessary for its own functionality without being exposed to vulnerabilities caused by other modules. For example, a code injection attack that is successful against one TEE cannot impact the code of another TEE.

Total memory encryption (TME) protects data in memory from being accessed by bypassing a processor. The system generates an encryption key within the processor on boot and never stores the key outside of the processor. The TME encryption key is an ephemeral key because it does not persist across reboots and is never stored outside of the processor. All data written by the processor to memory is encrypted using the encryption key and decrypted when it is read back from memory. Thus, a hardware-based attack that attempts to read data directly from memory without processor intermediation will fail.

Multi-key TME (MKTME) extends TME to make use of multiple keys. Individual memory pages may be encrypted using the ephemeral key of TME or using software-provided keys. This may provide increased security over TME with respect to software-based attacks, since an attacker will need to identify the particular key being used by targeted software rather than having the processor automatically decrypt any memory that the attack software has gained access to.

Initializing a TEE requires multiple steps before the TEE can begin executing, causing latency in applications that repeatedly create and destroy TEEs. Besides workload-specific initialization, workload-independent initialization is performed, such as adding memory to the enclave. In function-as-a-service (FaaS) environments, a large portion of the TEE is workload-independent, and thus can be performed prior to receiving the workload.

FaaS platforms provide cloud computing services that execute application logic but do not store data. By contrast with platform-as-a-service (PaaS) hosting providers, FaaS platforms do not have a constantly running server process. As a result, an initial request to a FaaS platform may take longer to handle than an equivalent request to a PaaS host, but at the advantage of reduced idle time and higher scalability. Reducing the latency of handling the initial request, as described herein, improves the attractiveness of the FaaS solution.

Certain steps performed during enclave initialization are identical for certain classes of workloads. For example, each enclave in a class may use heap memory. Thus, the common parts of the enclave initialization sequence (e.g., adding heap memory) may be performed before the enclave is requested. When an enclave is requested for a workload in the class and the parts to specialize the enclave for its particular purpose are known, the final steps to initialize the enclave are performed. This reduces latency over performing all initialization steps in response to a request for an enclave.

A TEE may be initialized ahead of time for a particular workload. The TEE is considered to be a template TEE. When a TEE for the workload is requested, the template TEE is forked, and the new copy is provided as the requested TEE. Since forking an existing TEE is faster than creating a new TEE from scratch, latency is reduced.

A TEE may be initialized ahead of time for a particular workload and marked read-only. The TEE is considered to be a template TEE. When a TEE for the workload is requested, a new TEE is created with read-only access to the template TEE. Multiple TEEs may have access to the template TEE safely, so long as the template TEE is read-only. Since creation of the new TEE with access to the template TEE is faster than creating a new TEE with all of the code and data of the template TEE from scratch, latency is reduced.

In some example embodiments, as described herein, a FaaS image is used to create a TEE using an ephemeral key. When a TEE for the FaaS is requested, the ephemeral key is assigned an access-controlled key identifier, allowing for rapid provisioning of the TEE in response.

By comparison with existing methods of initializing enclaves, the methods and systems discussed herein reduce latency. The reduction of latency may allow additional functionality to be protected in TEEs, for finer-grained TEEs to be used, or both, increasing system security. When these effects are considered in the aggregate, one or more of the methodologies described herein may obviate a need for certain efforts or resources that otherwise would be involved in initializing TEEs. Computing resources used by one or more machines, databases, or networks may similarly be reduced. Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, and cooling capacity.

FIG. 1 is a network diagram illustrating a network environment 100 suitable for servers providing functions as a service using TEEs, according to some example embodiments. The network environment 100 includes FaaS servers 110A and 110B, client devices 120A and 120B, and a network 130. The FaaS servers 110A-110B provide functions to client devices 120A-120B via the network 130. The client devices 120A and 120B may be devices of different tenants, such that each tenant wants to ensure that their tenant-specific data and code is not accessible by other tenants. Accordingly, the FaaS servers 110A-110B may use an enclave for each FaaS provided.

To reduce latency in providing functions, systems and methods described herein to reduce latency in TEE creation may be used. For example, a TEE for a function may be partially or wholly created by a FaaS server 110 prior to the function being requested by a client device 120.

The FaaS servers 110A-110B and the client devices 120A and 120B may each be implemented in a computer system, in whole or in part, as described below with respect to FIG. 9. The FaaS servers 110A and 110B may be referred to collectively as FaaS servers 110 or generically as a FaaS server 110. The client devices 120A and 120B may be referred to collectively as client devices 120 or generically as a client device 120.

Any of the machines, databases, or devices shown in FIG. 1 may be implemented in a general-purpose computer modified (e.g., configured or programmed) by software to be a special-purpose computer to perform the functions described herein for that machine, database, or device. For example, a computer system able to implement any one or more of the methodologies described herein is discussed below with respect to FIG. 9. As used herein, a “database” is a data storage resource and may store data structured as a text file, a table, a spreadsheet, a relational database (e.g., an object-relational database), a triple store, a hierarchical data store, a document-oriented NoSQL database, a file store, or any suitable combination thereof. The database may be an in-memory database. Moreover, any two or more of the machines, databases, or devices illustrated in FIG. 1 may be combined into a single machine, database, or device, and the functions described herein for any single machine, database, or device may be subdivided among multiple machines, databases, or devices.

The FaaS servers 110 and the client devices 120 are connected by the network 130. The network 130 may be any network that enables communication between or among machines, databases, and devices. Accordingly, the network 130 may be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof. The network 130 may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.

FIG. 2 is a block diagram of the FaaS server 110A, according to some example embodiments, suitable for reducing latency of TEEs according to some example embodiments. The FaaS server 110A is shown as including a communication module 210, an untrusted component 220 of an application, a trusted component 230 of an application, a trust domain module 240, a quoting enclave 250, a shared memory 260, and a private memory 270, all configured to communicate with each other (e.g., via a bus, shared memory, or a switch). Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine). For example, any module described herein may be implemented by a processor configured to perform the operations described herein for that module. Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

The communication module 210 receives data sent to the FaaS server 110A and transmits data from the FaaS server 110A. For example, the communication module 210 may receive, from the client device 120A, a request to perform a function. After the function is performed, the results of the function are provided by the communication module 210 to the client device 120A. Communications sent and received by the communication module 210 may be intermediated by the network 130.

The untrusted component 220 executes outside of an enclave. Thus, if the operating system or other untrusted components are compromised, the untrusted component 220 is vulnerable to attack. The trusted component 230 executes within an enclave. Thus, even if the operating system or the untrusted component 220 is compromised, the data and code of the trusted component 230 remains secure.

The trust domain module 240 creates and protects enclaves and is responsible for transitioning execution between the untrusted component 220 and the trusted component 230. Signed code may be provided to the trust domain module 240, which verifies that the code has not been modified since it was signed. The signed code is loaded into a portion of physical memory that is marked as being part of an enclave. Thereafter, hardware protections prevent access, modification, execution, or any suitable combination thereof of the enclave memory by untrusted software. The code may be encrypted using a key only available to the trust domain module 240.

Once the trusted component 230 is initialized, the untrusted component 220 can invoke functions of the trusted component 230 using special processor instructions of the trust domain module 240 that transition from an untrusted mode to a trusted mode. The trusted component 230 performs parameter verification, performs the requested function if the parameters are valid, and returns control to the untrusted component 220 via the trust domain module 240.

The trust domain module 240 may be implemented as one or more components of an Intel® hardware processor providing Intel® SGX, Intel® TDX, AMD® secure encrypted virtualization (SEV), ARM® TrustZone, or any suitable combination thereof. In Intel® SGX, attestation is the mechanism by which a third entity establishes that a software entity is running on an Intel® SGX enabled platform protected within an enclave prior to provisioning that software with secrets and protected data. Attestation relies on the ability of a platform to produce a credential that accurately reflects the signature of an enclave, which includes information on the enclave's security properties. The Intel® SGX architecture provides the mechanisms to support two forms of attestation. There is a mechanism for creating a basic assertion between enclaves running on the same platform, which supports local, or intra-platform attestation, and then another mechanism that provides the foundation for attestation between an enclave and a remote third party.

The quoting enclave 250 generates attestation for enclaves (e.g., the trusted component 230). The attestation is an evidence structure that uniquely identifies the attested enclave and the host (e.g., the FaaS server 110A), using asymmetric encryption and supported by built-in processor functions. The attestation may be provided to a client device 120 via the communication module 210, allowing the client device 120 to confirm that the trusted component 230 has not been compromised. For example, the processor may be manufactured with a built-in private key using hardware that prevents access of the key. Using this private key, the attestation structure can be signed by the processor and, using a corresponding public key published by the hardware manufacturer, the signature can be confirmed by the client device 120. This allows the client device 120 to ensure that the enclave on the remote device (e.g., the FaaS server 110A) has actually been created without being tampered with.

Both the untrusted component 220 and the trusted component 230 can access and modify the shared memory 260, but only the trusted component 230 can access and modify the private memory 270. Though only one untrusted component 220, one trusted component 230, and one private memory 270 are shown in FIG. 2, each application may have multiple trusted components 230, each with a corresponding private memory 270, and multiple untrusted components 220, without access to any of the private memories 270. Additionally, multiple applications may be run with separate memory spaces, and thus separate shared memories 260. In this context “shared” refers to the memory being accessible by all software and hardware with access to the memory space (e.g., an application and its operating system) not necessarily being accessible by all applications running on the system.

FIG. 3 is a block diagram 300 of prior art ring-based memory protection. The block diagram 300 includes applications 310 and 320 and an operating system 330. The operating system 330 executes processor commands in ring 0 (Intel® and AMD® processors), exception level 1 (ARM® processors), or an equivalent privilege level. The applications 310-320 execute processor commands in ring 3 (Intel® and AMD® processors), exception level 0 (ARM® processors), or an equivalent privilege level.

The hardware processor prevents code that is executing at the lower privilege level from accessing memory outside of the memory range defined by the operating system. Thus, the code of the application 310 cannot directly access the memory of the operating system 330 or the application 320 (as shown by the “X” in FIG. 3). The operating system 330 exposes some functionality to the applications 310-320 by predefining specific access points (e.g., by call gates, SYSENTER/SYSEXIT instructions on Intel® processors, SYSCALL/SYSRET instructions on AMD® processors, or any suitable combination or equivalent thereof).

Since the operating system 330 has access to all of memory, the applications 310 and 320 have no protection from a malicious operating system. For example, a competitor may modify the operating system before running the application 310 in order to gain access to the code and data of the application 310, permitting reverse engineering.

Additionally, if an application is able to exploit a vulnerability in the operating system 330 and promote itself to the privilege level of the operating system, the application would be able to access all of memory. For example, the application 310, which is not normally able to access the memory of the application 320 (as shown by the X between the applications 310 and 320 in FIG. 3), would be able to access the memory of the application 320 after promoting itself to ring 0 or exception level 1. Thus, if the user is tricked into running a malicious program (e.g., the application 310), private data of the user or an application provider may be accessed directly from memory (e.g., a banking password used by the application 320).

FIG. 4 is a block diagram 400 of enclave-based memory protection, suitable for reducing latency of TEEs according to some example embodiments. The block diagram 400 includes an application 410, an enclave 420, and an operating system 430. The operating system 430 executes processor commands in ring 0 (Intel® and AMD® processors), exception level 1 (ARM® processors), or an equivalent privilege level. The application 410 and the enclave 420 execute processor commands in ring 3 (Intel® and AMD® processors), exception level 0 (ARM® processors), or an equivalent privilege level.

The operating system 430 allocates the memory of the enclave 420 and indicates to the processor the code and data to be loaded into the enclave 420. However, once instantiated, the operating system 430 does not have access to the memory of the enclave 420. Thus, even if the operating system 430 is malicious or compromised, the code and data of the enclave 420 remains secure.

The enclave 420 may provide functionality to the application 410. The operating system 430 may control whether the application 410 is permitted to invoke functions of the enclave 420 (e.g., by using an ECALL instruction). Thus, a malicious application may be able to gain the ability to invoke functions of the enclave 420 by compromising the operating system 430. Nonetheless, the hardware processor will prevent the malicious application from directly accessing the memory or code of the enclave 420. Thus, while the code in the enclave 420 cannot assume that functions are being invoked correctly or by a non-attacker, the code in the enclave 420 has full control over parameter checking and other internal security measures and is only subject to its internal security vulnerabilities.

FIG. 5 is a block diagram of a database schema, according to some example embodiments, suitable for use in reducing latency of TEEs. The database schema 500 includes an enclave table 510. The enclave table 510 includes rows 530A, 530B, 530C, and 530D of a format 520.

The format 520 of the enclave table 510 includes an enclave identifier field, a status field, a read-only field, and a template identifier field. Each of the rows 530A-530D stores data for a single enclave. The enclave identifier is a unique identifier for the enclave. For example, when an enclave is created, the trust domain module 240 may assign the next unused identifier to the created enclave. The status field indicates the status of the enclave, such as initializing (created but not yet ready for use), initialized (ready for use but not yet in use), and allocated (in use). The read-only field indicates whether the enclave is read-only or not. The template identifier field contains the enclave identifier of another enclave that this enclave has read-only access to.

Thus, in the example of FIG. 5, four enclaves are shown in the enclave table 510. One of the enclaves is initializing, two are initialized, and one is allocated. Enclave 0, of the row 530A, is a read-only enclave and is used as a template for enclave 1, of the row 530B. Thus, the processor prevents enclave 0 from being executed but enclave 1 has access to the data and code of enclave 0. Additional enclaves may be created that also use enclave 0 as a template, allowing multiple enclaves to access the data and code of enclave 0 without multiplying the amount of memory consumed. Enclaves 1-3, of the rows 530B-530D, are not read-only, and thus can be executed.

FIG. 6 is a block diagram 600 of a sequence of operations performed by the trust domain module 240 in building a TEE, according to some example embodiments. As shown in FIG. 6, the sequence of operations includes ECREATE, EADD/EEXTEND, EINIT, EENTER, and FUNCTION START. The ECREATE operation creates the enclave. The EADD operation adds initial heap memory to the enclave. Additional memory may be added using the EEXTEND operation. The EINIT operation initializes the TEE for execution. Thereafter, the untrusted component 220 transfers execution to the TEE by requesting the trust domain module 240 to perform the EENTER operation. The trusted FUNCTION of the TEE is performed, in response to the FUNCTION START CALL, by executing the code within the TEE.

As shown in FIG. 6, the operations may be divided in at least two ways. One division shows that the ECREATE, EADD/EEXTEND, and EINIT operations are performed by the host application (e.g., the untrusted component 220) and the EENTER operation transfers control to the TEE, which performs the FUNCTION. Another division shows that the creation of the TEE and the allocation of heap memory for the TEE can be performed regardless of the particular code and data to be added to the TEE (“workload-independent operations”) while the initialization of the TEE and subsequent invocation of a TEE function depend on the particular code and data that are loaded (“workload-dependent operations”).

A pool of TEEs may be pre-initialized by performing the workload-independent operations before the TEEs are requested. In response to receiving a request for a TEE, the workload-dependent operations are performed. By comparison with solutions that do not perform the workload-independent operations before the request is received, the latency is reduced.

For a FaaS environment, each function may share a common runtime environment that is workload independent and is initialized before the workload-dependent operations are performed. The startup time of a FaaS function is an important metric in FaaS services, since shorter startup times allow for higher elasticity of the service.

FIG. 7 is a flowchart illustrating operations of a method 700 suitable for initializing and providing access to TEEs, according to some example embodiments. The method 700 includes operations 710, 720, 730, and 740. By way of example and not limitation, the method 700 may be performed by the FaaS server 110A of FIG. 1, using the modules, databases, and structures shown in FIGS. 2-4.

In operation 710, the trust domain module 240 pre-initializes a pool of enclaves. For example, the operations of creating the enclave and allocating heap memory to the enclave may be performed for each enclave in the pool of enclaves. In some example embodiments, the pool of enclaves includes 16-512 enclaves, 16 enclaves, 32 enclaves, or 128 enclaves.

In various example embodiments, the enclaves in the pool of enclaves are partially pre-initialized or fully pre-initialized. A fully pre-initialized enclave has at least one of the workload-specific operations performed before the enclave is requested. A partially pre-initialized enclave has only the workload-independent operations performed before the enclave is requested. Pre-initialized enclaves reduce the time-to-result for any enclave, but they are particularly valuable for short-lived ephemeral enclaves (e.g., FaaS workloads) where the initialization overhead dominates the overall execution time.

The pre-initialized enclaves may be created by forking or copying a template enclave. The template enclave is created first, with the desired state of the pre-initialized enclaves. Then the template enclave is forked or copied for each of the pre-initialized enclaves in the pool. In some example embodiments, the template enclave is itself part of the pool. In other example embodiments, the template enclave is read-only, not executable, and retained as a template for later use. The template enclave may include memory contents and layout for a FaaS.

Each enclave in the pool of enclaves may have its memory encrypted using a key stored in the processor. The key may be an ephemeral key (e.g., the TME ephemeral key) or a key with a key identifier that is accessible outside of the processor. The trust domain module 240 or an MKTME module may generate the key and assign it to the enclave. Thus, the key itself is never exposed outside of the processor. The enclave is assigned a portion of physical memory. Memory access requests originating from the physical memory of the enclave are associated with the key identifier, and thus the key, of the enclave. The processor does not apply the key of the enclave to memory accesses that originate from outside the physical memory of the enclave. As a result, memory accesses by untrusted applications or components (e.g., the untrusted component 220) can receive only the encrypted data or code of the enclave.

In some example embodiments, a different ephemeral key without a key identifier (e.g., an MKTME key) is used to encrypt each enclave in the pool of enclaves. Thereafter, when an enclave for the FaaS is requested, the ephemeral key is assigned an access-controlled key identifier by the trust domain module 240, allowing for rapid provisioning of the enclave in response.

The trust domain module 240, in operation 720, receives a request for an enclave. For example, the untrusted component 220 of an application may provide data identifying an enclave to the trust domain module 240 as part of the request. The data identifying the enclave may include a pointer to an address in the shared memory 260, accessible by the untrusted component 220.

The request may include a pre-computed hash value for the enclave and indicate a portion of the shared memory 260 (e.g., a portion identified by an address and a size included in the request) that contains the code and data for the enclave. The trust domain module 240 may perform a hash function on a binary memory state (e.g., the portion of the shared memory 260 indicated in the request) to confirm that the hash value provided in the request matches the computed hash value. If the hash values match, the trust domain module 240 has confirmed that the indicated memory actually contains the code and data of the requested enclave and the method 700 may proceed. If the hash values don't match, the trust domain module 240 may return an error value, preventing the modified memory from being loaded into the enclave.

In some example embodiments, the request includes an identifier of a template enclave. The trust domain module 240 creates the requested enclave with read-only permissions to access the template enclave. This allows the requested enclave to read data of the template enclave and execute functions of the template enclave without modifying the data or code of the template enclave. Accordingly, multiple enclaves may access the template enclave without conflict and the data and code of the template enclave is stored only once (rather than once for each of the multiple enclaves). As a result, less memory is copied during creation of the accessing enclaves, reducing latency.

In operation 730, in response to the received request, the trust domain module 240 selects an enclave from the pre-initialized pool of enclaves. The trust domain module 240 may modify the selected enclave by performing, based on the data identifying the enclave received with the request, additional operations on the selected enclave, such as the workload-specific operations shown in FIG. 4. The additional operations may include copying data or code from the address in the shared memory 260 indicated in the request to the private memory 270 allocated to the enclave.

In some example embodiments, the additional operations include re-encrypting the physical memory assigned to the enclave with a new key. For example, the pre-initialization step may have encrypted the physical memory of the enclave using an ephemeral key and the enclave may be re-encrypted using a unique key for the enclave, with a corresponding unique key identifier. In systems in which the key identifiers are a finite resource (e.g., with a fixed number of key identifiers available), using the ephemeral key for the pre-initialized enclaves may increase the maximum size of the pool of enclaves (e.g., to a size above the fixed number of available key identifiers). The additional operations may also include creating a secure extended page table (EPT) branch for the selected TEE that derives code mappings from the template TEE.

The trust domain module 240 provides access to the selected enclave in response to the request (operation 740). For example, a unique identifier of the initialized enclave may be returned, usable as a parameter for a later request (e.g., an EENTER command) to the trust domain module 240 to execute a function within the enclave.

Thereafter, the trust domain module 240 may determine that execution of the selected enclave is complete (e.g., in response to receiving an enclave exit instruction). The memory assigned to the completed enclave may be released. Alternatively, the state of the completed enclave may be restored to the pre-initialized state and the enclave may be returned to the pool. For example, the template enclave may be copied over the enclave, operations to reverse the workload-specific operations may be performed, a checkpoint of the enclave performed before the workload-specific operations are performed, and a restore of the checkpoint performed after execution is complete, or any suitable combination thereof.

By comparison with prior art implementations that do not perform the pre-initialization of the enclave (operation 710) before receiving the request for the enclave (operation 720), the delay between the receiving of the request and the providing of access (operation 740) is reduced. The reduction of latency may allow additional functionality to be protected in enclaves, for finer-grained enclaves to be used, or both, increasing system security. Additionally, when the enclave is invoked over the network 130 by a client device 120, processor cycles of the client device 120 that are used while waiting for a response from the FaaS server 110 are reduced, improving responsiveness and reducing power consumption.

FIG. 8 is a flowchart illustrating operations of a method 800 suitable for initializing and providing access to TEEs, according to some example embodiments. The method 800 includes operations 810, 820, 830, and 840. By way of example and not limitation, the method 800 may be performed by the FaaS server 110A of FIG. 1, using the modules, databases, and structures shown in FIGS. 2-4.

In operation 810, the trust domain module 240 creates a template enclave marked read-only. For example, the enclave may be fully created, with code and data loaded into the private memory 270. However, since the template enclave is read-only, functions of the template enclave cannot be directly invoked from the untrusted component 220. With reference to the enclave table 310 of FIG. 3, the row 330A shows a read-only template enclave.

The trust domain module 240, in operation 820, receives a request for an enclave. For example, the untrusted component 220 of an application may provide data identifying an enclave to the trust domain module 240 as part of the request. The data identifying the enclave may include a pointer to an address in the shared memory 260, accessible by the untrusted component 220.

In operation 830, in response to the received request, the trust domain module 240 copies the template enclave to create the requested enclave. For example, the trust domain module 240 may determine that the data identifying the enclave indicates that the requested enclave is for the same code and data as the template enclave. The determination may be based on a signature of the enclave code and data, a message authentication code (MAC) of the enclave code and data, asymmetric encryption, or any suitable combination thereof.

The trust domain module 240 provides access to the selected enclave in response to the request (operation 840). For example, a unique identifier of the initialized enclave may be returned, usable as a parameter to a later request (e.g., an EENTER command) to the trust domain module 240 to execute a function within the enclave.

By comparison with prior art implementations that create the enclave in response to receiving the request for the enclave (operation 820) instead of copying the template enclave to create the requested enclave (operation 830), the delay between the receiving of the request and the providing of access (operation 840) is reduced. The reduction of latency may allow additional functionality to be protected in enclaves, for finer-grained enclaves to be used, or both, increasing system security. Additionally, when the enclave is invoked over the network 130 by a client device 120, processor cycles of the client device 120 that are used while waiting for a response from the FaaS server 110 are reduced, improving responsiveness and reducing power consumption.

FIG. 9 is a flowchart illustrating operations of a method 900 suitable for initializing and providing access to TEEs, according to some example embodiments. The method 900 includes operations 910, 920, 930, and 940. By way of example and not limitation, the method 900 may be performed by the FaaS server 110A of FIG. 1, using the modules, databases, and structures shown in FIGS. 2-4.

In operation 910, the trust domain module 240 pre-initializes a first pool of enclaves of a first class and a second pool of enclaves of a second class. The pre-initializing is either complete or partial. For complete initialization, the enclaves in the pool are fully prepared for use and already loaded with the code and data of the enclave. Thus, all members of the class are identical. For partial initialization, the enclaves in the pool share one or more characteristics, such as the amount of heap memory used. The enclaves are initialized with respect to the shared characteristics, but the actual code and data of the enclave is not loaded during pre-initialization. Additionally, further customization may be performed at a later step. Accordingly, different enclaves may be members of the class when partial initialization is performed.

The trust domain module 240, in operation 920, receives a request for an enclave of the first class. For example, the untrusted component 220 of an application may provide data identifying an enclave to the trust domain module 240 as part of the request. The data identifying the enclave may include a pointer to an address in the shared memory 260, accessible by the untrusted component 220. The data identifying the class of the enclave may be included in the enclave or in the request.

In operation 930, in response to the received request, the trust domain module 240 selects an enclave from the pre-initialized pool of enclaves for the first class. The trust domain module 240 may modify the selected enclave by performing, based on the data identifying the enclave received with the request, additional operations on the selected enclave, such as the workload-specific operations shown in FIG. 4. The additional operations may include copying data or code from the address in the shared memory 260 indicated in the request to the private memory 270 allocated to the enclave.

The trust domain module 240 provides access to the selected enclave in response to the request (operation 940). For example, a unique identifier of the initialized enclave may be returned, usable as a parameter for a later request (e.g., an EENTER command) to the trust domain module 240 to execute a function within the enclave.

By using different pools of different classes, enclaves that are similar but in relatively low demand can be put into a common class for partial pre-initialization, reducing latency while consuming resources only in proportion to their demand. At the same time, enclaves that are in high demand can be fully pre-initialized, reducing latency still further.

In view of the above described implementations of subject matter, this application discloses the following list of examples, wherein one feature of an example in isolation or more than one feature of an example, taken in combination and, optionally, in combination with one or more features of one or more further examples, are further examples also falling within the disclosure of this application.

Example 1 is a system to provide a trusted execution environment (TEE), the system comprising: a processor; and a storage device coupled to the processor to store instructions that, when executed by the processor, cause the processor to: pre-initialize a pool of TEEs, the pre-initializing of each TEE of the pool of TEEs including allocating memory of the storage device for the TEE; after the pre-initializing of the pool of TEEs, receive a request for a TEE; select the TEE from the pre-initialized pool of TEEs; and provide access to the selected TEE in response to the request.

In Example 2, the subject matter of Example 1 includes, wherein the instructions further cause the processor to: prior to the providing of access to the selected TEE, modify the selected TEE based on information in the request.

In Example 3, the subject matter of Example 2 includes, wherein the modifying of the selected TEE comprises starting the selected TEE.

In Example 4, the subject matter of Examples 2-3 includes, wherein the modifying of the selected TEE comprises copying data or code to the allocated memory for the TEE.

In Example 5, the subject matter of Examples 2-4 includes, wherein the modifying of the selected TEE comprises: assigning an encryption key to the selected TEE; and encrypting the memory allocated to the TEE using the encryption key.

In Example 6, the subject matter of Examples 1-5 includes, wherein: the pre-initializing of the pool of TEEs comprises copying a state of a template TEE to each TEE of the pool of TEEs.

In Example 7, the subject matter of Examples 1-6 includes, wherein the instructions further cause the processor to: based on a determination that execution of the selected TEE is complete, restore the selected TEE to a state of a template TEE.

In Example 8, the subject matter of Examples 1-7 includes, wherein the instructions further cause the processor to: receive a request to release the selected TEE; and in response to the request to release the selected TEE, return the selected TEE to the pool of TEEs.

In Example 9, the subject matter of Examples 1-8 includes, wherein the instructions further cause the processor to: receive a pre-computed hash value; determine a hash value of a binary memory state; and based on the determined hash value and the pre-computed hash value, copy the binary memory state from unsecured memory to the selected TEE.

Example 10 is a system to provide a TEE, the system comprising: a processor; and a storage device coupled to the processor to store instructions that, when executed by the processor, cause the processor to: pre-initialize a pool of TEEs; create a template TEE stored in the storage device and marked read-only; receive a request; and in response to the request: copy the template TEE to create a TEE; and provide access to the created TEE.

In Example 11, the subject matter of Example 10 includes, wherein the template TEE comprises initial memory contents and layout for a function as a service (FaaS).

In Example 12, the subject matter of Examples 10-11 includes, wherein the processor prevents execution of the template TEE.

Example 13 is a method to provide a TEE, the method comprising: pre-initializing, by a processor, a pool of TEEs, the pre-initializing of each TEE of the pool of TEEs including allocating memory of a storage device for the TEE; after the pre-initializing of the pool of TEEs, receiving, by the processor, a request; and in response to the request: selecting, by the processor, a TEE from the pre-initialized pool of TEEs; and providing access, by the processor, to the selected TEE.

In Example 15, the subject matter of Example 14 includes, prior to the providing of access to the selected TEE, modifying the selected TEE based on information in the request.

In Example 16, the subject matter of Example 15 includes, wherein the modifying of the selected TEE comprises starting the selected TEE.

In Example 17, the subject matter of Examples 15-16 includes, wherein the modifying of the selected TEE comprises copying data or code to the allocated memory for the TEE.

In Example 18, the subject matter of Examples 15-17 includes, wherein the modifying of the selected TEE comprises: assigning an encryption key to the selected TEE; and encrypting the memory allocated to the TEE using the encryption key.

In Example 19, the subject matter of Examples 14-18 includes, wherein: the pre-initializing of the pool of TEEs comprises copying a state of a template TEE to each TEE of the pool of TEEs.

In Example 20, the subject matter of Examples 14-19 includes, based on a determination that execution of the selected TEE is complete, restoring the selected TEE to a state of a template TEE.

In Example 21, the subject matter of Examples 14-20 includes, receiving a request to release the selected TEE; and in response to the request to release the selected TEE, returning the selected TEE to the pool of TEEs.

In Example 22, the subject matter of Examples 14-21 includes, receiving a pre-computed hash value; determining a hash value of a binary memory state; and based on the determined hash value and the pre-computed hash value, copying the binary memory state from unsecured memory to the selected TEE.

Example 23 is a method to provide a trusted execution environment (TEE), the method comprising: creating, by a processor, a template TEE stored in a storage device and marked read-only; receiving, by the processor, a request; and in response to the request: copying the template TEE to create a TEE; and providing access to the created TEE.

In Example 24, the subject matter of Example 23 includes, wherein the template TEE comprises initial memory contents and layout for a function as a service (FaaS).

In Example 25, the subject matter of Examples 23-24 includes, wherein the processor prevents execution of the template TEE.

Example 26 is a method to provide a TEE, the method comprising: encrypting, by a processor, data and code using a first encryption key; storing the encrypted data and code in a storage device; receiving, by the processor, a request; in response to the request: assigning a second encryption key to a TEE; decrypting the encrypted data and code using the first encryption key; encrypting the decrypted data and code using the second encryption key; and providing access to the TEE.

Example 27 is a non-transitory computer readable medium having instructions for causing a processor to provide a TEE by performing operations comprising: pre-initializing a pool of TEEs, the pre-initializing of each TEE of the pool of TEEs including allocating memory of a storage device for the TEE; after the pre-initializing of the pool of TEEs, receiving a request for a TEE; selecting the TEE from the pre-initialized pool of TEEs; and providing access to the selected TEE in response to the request.

In Example 28, the subject matter of Example 27 includes, wherein the operations further comprise: prior to the providing of access to the selected TEE, modifying the selected TEE based on information in the request.

In Example 29, the subject matter of Example 28 includes, wherein the modifying of the selected TEE comprises starting the selected TEE.

In Example 30, the subject matter of Examples 28-29 includes, wherein the modifying of the selected TEE comprises copying data or code to the allocated memory for the TEE.

In Example 31, the subject matter of Examples 28-30 includes, wherein the modifying of the selected TEE comprises: assigning an encryption key to the selected TEE; and encrypting the memory allocated to the TEE using the encryption key.

In Example 32, the subject matter of Examples 27-31 includes, wherein: the pre-initializing of the pool of TEEs comprises copying a state of a template TEE to each TEE of the pool of TEEs.

In Example 33, the subject matter of Examples 27-32 includes, wherein the operations further comprise: based on a determination that execution of the selected TEE is complete, restoring the selected TEE to a state of a template TEE.

In Example 34, the subject matter of Examples 27-33 includes, wherein the operations further comprise: receiving a request to release the selected TEE; and in response to the request to release the selected TEE, returning the selected TEE to the pool of TEEs.

In Example 35, the subject matter of Examples 27-34 includes, wherein the operations further comprise: receiving a pre-computed hash value; determining a hash value of a binary memory state; and based on the determined hash value and the pre-computed hash value, copying the binary memory state from unsecured memory to the selected TEE.

Example 36 is a non-transitory computer readable medium having instructions for causing a processor to provide a TEE by performing operations comprising: creating a template TEE stored in a storage device and marked read-only; receiving a request; and in response to the request: copying the template TEE to create a TEE; and providing access to the created TEE.

In Example 37, the subject matter of Example 36 includes, wherein the template TEE comprises initial memory contents and layout for a function as a service (FaaS).

In Example 38, the subject matter of Examples 36-37 includes, wherein the operations further comprise: preventing execution of the template TEE.

Example 39 is a non-transitory computer readable medium having instructions for causing a processor to provide a TEE by performing operations comprising: encrypting data and code using a first encryption key; storing the encrypted data and code in a storage device; receiving a request; in response to the request: assigning a second encryption key to a TEE; decrypting the encrypted data and code using the first encryption key; encrypting the decrypted data and code using the second encryption key; and providing access to the TEE.

Example 40 is a system to provide a TEE, the system comprising: storage means; and processing means to: pre-initialize a pool of TEEs, the pre-initializing of each TEE of the pool of TEEs including allocating memory of the storage means for the TEE; receive a request for a TEE; select the TEE from the pre-initialized pool of TEEs; and provide access to the selected TEE in response to the request.

In Example 41, the subject matter of Example 40 includes, wherein the processing means is further to: prior to the providing of access to the selected TEE, modify the selected TEE based on information in the request.

In Example 42, the subject matter of Example 41 includes, wherein the modifying of the selected TEE comprises starting the selected TEE.

In Example 43, the subject matter of Examples 41-42 includes, wherein the modifying of the selected TEE comprises copying data or code to the allocated memory for the TEE.

In Example 44, the subject matter of Examples 41-43 includes, wherein the modifying of the selected TEE comprises: assigning an encryption key to the selected TEE; and encrypting the memory allocated to the TEE using the encryption key.

In Example 45, the subject matter of Examples 40-44 includes, wherein: the pre-initializing of the pool of TEEs comprises copying a state of a template TEE to each TEE of the pool of TEEs.

In Example 46, the subject matter of Examples 40-45 includes, wherein the processing means is further to: based on a determination that execution of the selected TEE is complete, restore the selected TEE to a state of a template TEE.

In Example 47, the subject matter of Examples 40-46 includes, wherein the processing means is further to: receive a request to release the selected TEE; and in response to the request to release the selected TEE, return the selected TEE to the pool of TEEs.

In Example 48, the subject matter of Examples 40-47 includes, wherein the processing means is further to: receive a pre-computed hash value; determine a hash value of a binary memory state; and based on the determined hash value and the pre-computed hash value, copy the binary memory state from unsecured memory to the selected TEE.

Example 49 is a system to provide a TEE, the system comprising: storage means; and processing means to: create a template TEE stored in the storage means and marked read-only; receive a request; and in response to the request: copy the template TEE to create a TEE; and provide access to the TEE.

In Example 50, the subject matter of Example 49 includes, wherein the template TEE comprises initial memory contents and layout for a function as a service (FaaS).

In Example 51, the subject matter of Examples 49-50 includes, wherein the processing means prevents execution of the template TEE.

Example 52 is a system to provide a TEE, the system comprising: storage means; and processing means to: encrypt data and code using a first encryption key; store the encrypted data and code in the storage means; receive a request; in response to the request: assign a second encryption key to a TEE; decrypt the encrypted data and code using the first encryption key; encrypt the decrypted data and code using the second encryption key; and provide access to the TEE.

Example 53 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement of any of Examples 1-52.

Example 54 is an apparatus comprising means to implement of any of Examples 1-52.

Example 55 is a system to implement of any of Examples 1-52.

Example 56 is a method to implement of any of Examples 1-52.

FIG. 10 is a block diagram 1000 showing one example of a software architecture 1002 for a computing device. The architecture 1002 may be used in conjunction with various hardware architectures, for example, as described herein. FIG. 10 is merely a non-limiting example of a software architecture and many other architectures may be implemented to facilitate the functionality described herein. A representative hardware layer 1004 is illustrated and can represent, for example, any of the above referenced computing devices. In some examples, the hardware layer 1004 may be implemented according to the architecture of the computer system of FIG. 10.

The representative hardware layer 1004 comprises one or more processing units 1006 having associated executable instructions 1008. Executable instructions 1008 represent the executable instructions of the software architecture 1002, including implementation of the methods, modules, subsystems, and components, and so forth described herein and may also include memory and/or storage modules 1010, which also have executable instructions 1008. Hardware layer 1004 may also comprise other hardware as indicated by other hardware 1012 which represents any other hardware of the hardware layer 1004, such as the other hardware illustrated as part of the software architecture 1002.

In the example architecture of FIG. 10, the software architecture 1002 may be conceptualized as a stack of layers where each layer provides particular functionality. For example, the software architecture 1002 may include layers such as an operating system 1014, libraries 1016, frameworks/middleware 1018, applications 1020, and presentation layer 1044. Operationally, the applications 1020 and/or other components within the layers may invoke application programming interface (API) calls 1024 through the software stack and access a response, returned values, and so forth illustrated as messages 1026 in response to the API calls 1024. The layers illustrated are representative in nature and not all software architectures have all layers. For example, some mobile or special purpose operating systems may not provide a frameworks/middleware layer 1018, while others may provide such a layer. Other software architectures may include additional or different layers.

The operating system 1014 may manage hardware resources and provide common services. The operating system 1014 may include, for example, a kernel 1028, services 1030, and drivers 1032. The kernel 1028 may act as an abstraction layer between the hardware and the other software layers. For example, the kernel 1028 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, and so on. The services 1030 may provide other common services for the other software layers. In some examples, the services 1030 include an interrupt service. The interrupt service may detect the receipt of an interrupt and, in response, cause the architecture 1002 to pause its current processing and execute an interrupt service routine (ISR) when an interrupt is accessed.

The drivers 1032 may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers 1032 may include display drivers, camera drivers, Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, NFC drivers, audio drivers, power management drivers, and so forth depending on the hardware configuration.

The libraries 1016 may provide a common infrastructure that may be utilized by the applications 1020 and/or other components and/or layers. The libraries 1016 typically provide functionality that allows other software modules to perform tasks in an easier fashion than to interface directly with the underlying operating system 1014 functionality (e.g., kernel 1028, services 1030 and/or drivers 1032). The libraries 1016 may include system libraries 1034 (e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 1016 may include API libraries 1036 such as media libraries (e.g., libraries to support presentation and manipulation of various media format such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., an OpenGL framework that may be used to render two-dimensional and three-dimensional in a graphic content on a display), database libraries (e.g., SQLite that may provide various relational database functions), web libraries (e.g., WebKit that may provide web browsing functionality), and the like. The libraries 1016 may also include a wide variety of other libraries 1038 to provide many other APIs to the applications 1020 and other software components/modules.

The frameworks/middleware 1018 may provide a higher-level common infrastructure that may be utilized by the applications 1020 and/or other software components/modules. For example, the frameworks/middleware 1018 may provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware 1018 may provide a broad spectrum of other APIs that may be utilized by the applications 1020 and/or other software components/modules, some of which may be specific to a particular operating system or platform.

The applications 1020 include built-in applications 1040 and/or third-party applications 1042. Examples of representative built-in applications 1040 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application. Third-party applications 1042 may include any of the built-in applications 1040 as well as a broad assortment of other applications. In a specific example, the third-party application 1042 (e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™ Windows® Phone, or other mobile computing device operating systems. In this example, the third-party application 1042 may invoke the API calls 1024 provided by the mobile operating system such as operating system 1014 to facilitate functionality described herein.

The applications 1020 may utilize built-in operating system functions (e.g., kernel 1028, services 1030 and/or drivers 1032), libraries (e.g., system libraries 1034, API libraries 1036, and other libraries 1038), frameworks/middleware 1018 to create user interfaces to interact with users of the system. Alternatively, or additionally, in some systems, interactions with a user may occur through a presentation layer, such as presentation layer 1044. In these systems, the application/module “logic” can be separated from the aspects of the application/module that interact with a user.

Some software architectures utilize virtual machines. In the example of FIG. 10, this is illustrated by virtual machine 1048. A virtual machine creates a software environment where applications/modules can execute as if they were executing on a hardware computing device. A virtual machine is hosted by a host operating system (operating system 1014) and typically, although not always, has a virtual machine monitor 1046, which manages the operation of the virtual machine 1048 as well as the interface with the host operating system (i.e., operating system 1014). A software architecture executes within the virtual machine 1048 such as an operating system 1050, libraries 1052, frameworks/middleware 1054, applications 1056 and/or presentation layer 1058. These layers of software architecture executing within the virtual machine 1048 can be the same as corresponding layers previously described or may be different.

Modules, Components and Logic

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied (1) on a non-transitory machine-readable medium or (2) in a transmission signal) or hardware-implemented modules. A hardware-implemented module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

In various embodiments, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware-implemented module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the term “hardware-implemented module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily or transitorily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each of the hardware-implemented modules need not be configured or instantiated at any one instance in time. For example, where the hardware-implemented modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware-implemented modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware-implemented module at one instance of time and to constitute a different hardware-implemented module at a different instance of time.

Hardware-implemented modules can provide information to, and receive information from, other hardware-implemented modules. Accordingly, the described hardware-implemented modules may be regarded as being communicatively coupled. Where multiple of such hardware-implemented modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses that connect the hardware-implemented modules). In embodiments in which multiple hardware-implemented modules are configured or instantiated at different times, communications between such hardware-implemented modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware-implemented modules have access. For example, one hardware-implemented module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware-implemented module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware-implemented modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.

Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment, or a server farm), while in other embodiments the processors may be distributed across a number of locations.

The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

Electronic Apparatus and System

Example embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, or software, or in combinations of them. Example embodiments may be implemented using a computer program product, e.g., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a standalone program or as a module, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

In example embodiments, operations may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method operations can also be performed by, and apparatus of example embodiments may be implemented as, special purpose logic circuitry, e.g., an FPGA or an ASIC.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In embodiments deploying a programmable computing system, it will be appreciated that both hardware and software architectures merit consideration. Specifically, it will be appreciated that the choice of whether to implement certain functionality in permanently configured hardware (e.g., an ASIC), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanently and temporarily configured hardware may be a design choice. Below are set out hardware (e.g., machine) and software architectures that may be deployed, in various example embodiments.

Example Machine Architecture and Machine-Readable Medium

FIG. 11 is a block diagram of a machine in the example form of a computer system 1100 within which instructions 1124 may be executed for causing the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system 1100 includes a processor 1102 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 1104, and a static memory 1106, which communicate with each other via a bus 1108. The computer system 1100 may further include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1100 also includes an alphanumeric input device 1112 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device 1114 (e.g., a mouse), a storage unit 1116, a signal generation device 1118 (e.g., a speaker), and a network interface device 1120.

Machine-Readable Medium

The storage unit 1116 includes a machine-readable medium 1122 on which is stored one or more sets of data structures and instructions 1124 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 1124 may also reside, completely or at least partially, within the main memory 1104 and/or within the processor 1102 during execution thereof by the computer system 1100, with the main memory 1104 and the processor 1102 also constituting machine-readable media 1122.

While the machine-readable medium 1122 is shown in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 1124 or data structures. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding, or carrying instructions 1124 for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 1124. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media 1122 include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and compact disc read-only memory (CD-ROM) and digital versatile disc read-only memory (DVD-ROM)disks. A machine-readable medium is not a transmission medium.

Transmission Medium

The instructions 1124 may further be transmitted or received over a communications network 1126 using a transmission medium. The instructions 1124 may be transmitted using the network interface device 1120 and any one of a number of well-known transfer protocols (e.g., hypertext transport protocol (HTTP)). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 1124 for execution by the machine, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Although specific example embodiments are described herein, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Some portions of the subject matter discussed herein may be presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). Such algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless specifically stated otherwise, the terms “a” and “an” are herein used, as is common in patent documents, to include one or more than one instance. Finally, as used herein, the conjunction “or” refers to a non-exclusive “or,” unless specifically stated otherwise.

	Number	Date	Country
Parent	17131716	Dec 2020	US
Child	17950826		US

REDUCING LATENCY OF HARDWARE TRUSTED EXECUTION ENVIRONMENTS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

PRIORITY APPLICATION

Continuations (1)