Abstract: Detailed herein are examples of determining when to allow access to a trusted execution environment (TEE). For example, using TEE logic associated with software to at least in part: determine that a TEE feature is supported based at least on a value of a bit position in a data structure; and not allow a TEE entry instruction to access to a TEE when the bit position of the data structure is reserved.

Abstract: A processor includes a decode unit to decode an instruction that is to indicate a page of a protected container memory, and a storage location outside of the protected container memory. An execution unit, in response to the instruction, is to ensure that there are no writable references to the page of the protected container memory while it has a write protected state. The execution unit is to encrypt a copy of the page of the protected container memory. The execution unit is to store the encrypted copy of the page to the storage location outside of the protected container memory, after it has been ensured that there are no writable references. The execution unit is to leave the page of the protected container memory in the write protected state, which is also valid and readable, after the encrypted copy has been stored to the storage location.

Abstract: Systems, methods, and apparatuses relating efficient exception handling in trusted execution environments are described. In an embodiment, a hardware processor includes a register, a decoder, and execution circuitry. The register has a field to be set to enable an architecturally protected execution environment at one of a plurality of contexts for code in an architecturally protected enclave in memory. The decoder is to decode an instruction having a format including a field for an opcode, the opcode to indicate that the execution circuitry is to perform a context change. The execution circuitry is to perform one or more operations corresponding to the instruction, the one or more operations including changing, within the architecturally protected enclave, from a first context to a second context.

Abstract: Methods, apparatus, systems and articles of manufacture to determine provenance for data supply chains are disclosed. Example instructions cause a machine to at least, in response to data being generated, generate a local data object and object metadata corresponding to the data; hash the local data object; generate a hash of a label of the local data object; generate a hierarchical data structure for the data including the hash of the local data object and the hash of the label of the local data object; generate a data supply chain object including the hierarchical data structure; and transmit the data and the data supply chain object to a device that requested access to the data.

Abstract: Example methods and systems are directed to reducing latency in providing trusted execution environments (TEEs). Initializing a TEE includes multiple steps before the TEE starts executing. Besides workload-specific initialization, workload-independent initialization is performed, such as adding memory to the TEE. 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. Certain steps performed during TEE initialization are identical for certain classes of workloads. Thus, the common parts of the TEE initialization sequence may be performed before the TEE is requested. When a TEE is requested for a workload in the class and the parts to specialize the TEE for its particular purpose are known, the final steps to initialize the TEE are performed.

Abstract: Examples described herein relate to dynamically composing an application as a monolithic implementation or two or more microservices based on telemetry data. In some examples, based on composition of an application as two or more microservices, at least one connection between microservices based on telemetry data is adjusted. In some examples, a switch can be configured to perform forwarding of communications between microservices based on the adjusted at least one connection between microservices.

Abstract: Various approaches for memory encryption management within an edge computing system are described. In an edge computing system deployment, a computing device includes capabilities to store and manage encrypted data in memory, through processing circuitry configured to: allocate memory encryption keys according to a data isolation policy for a microservice domain, with respective keys used for encryption of respective sets of data within the memory (e.g., among different tenants or tenant groups); and, share data associated with a first microservice to a second microservice of the domain. Such sharing may be based on the communication of an encryption key, used to encrypt the data in memory, from a proxy (such as a sidecar) associated with the first microservice to a proxy associated with the second microservice; and maintaining the encrypted data within the memory, for use with the second microservice, as accessible with the communicated encryption key.

Abstract: Scalable cloning and replication for trusted execution environments is described. An example of a computer-readable storage medium includes instructions for receiving a selection of a point to capture a snapshot of a baseline trust domain (TD) or secure enclave, the TD or secure enclave being associated with a trusted execution environment (TEE) of a processor utilized for processing of a workload; initiating cloning of the TD or secure enclave from a source platform to an escrow platform; generating an escrow key to export the snapshot to the escrow platform; and exporting a state of the TD or secure enclave to the escrow platform, the state being sealed with a sealing key.

Abstract: Systems, methods, and apparatuses relating to an instruction that allows a trusted execution environment to react to an asynchronous exit are described. In one embodiment, a hardware processor includes a register comprising a field, that when set, is to enable an architecturally protected execution environment for code in an architecturally protected enclave in memory, a decoder circuit to decode a single instruction comprising an opcode into a decoded instruction, the opcode to indicate an execution circuit is to invoke a handler to handle an asynchronous exit from execution of the code in the architecturally protected enclave and then resume execution of the code in the architecturally protected enclave from where the asynchronous exit occurred, and the execution circuit to respond to the decoded instruction as specified by the opcode.

Abstract: In one embodiment, metadata associated with deployment of a container within an orchestration environment includes information indicating security preferences for deployment of the container within the orchestration environment, information indicating a level of communications between the container and other containers, and/or information indicating effects of execution of the container with respect to other containers. The metadata is used to select a particular node of a plurality of nodes within the orchestration environment on which to deploy the container based on the metadata.

Abstract: A computing node includes network interface circuitry and processing circuitry. The processing circuitry assigns available computing resources to a plurality of slice contexts. Each slice context of the plurality includes resource allocations of the available computing resources associated with multiple communication networks. A first portion of the resource allocations is designated as dedicated resources and a second, remaining portion is designated as shared resources. A FAFO event associated with a workload is detected. The workload executes on a network slice instance (NSI) associated with a slice context of a subset of slice contexts. The configuration of the NSI is restored to a pre-FAFO event state based on reconfiguring one or both of the dedicated resources or the shared resources of the slice context based on the resource allocations of at least a second slice context in the subset of slice contexts.

Abstract: Various approaches for memory encryption management within an edge computing system are described. In an edge computing system deployment, a computing device includes capabilities to store and manage encrypted data in memory, through processing circuitry configured to: allocate memory encryption keys according to a data isolation policy for a microservice domain, with respective keys used for encryption of respective sets of data within the memory (e.g., among different tenants or tenant groups); and, share data associated with a first microservice to a second microservice of the domain. Such sharing may be based on the communication of an encryption key, used to encrypt the data in memory, from a proxy (such as a sidecar) associated with the first microservice to a proxy associated with the second microservice; and maintaining the encrypted data within the memory, for use with the second microservice, as accessible with the communicated encryption key.

Abstract: In one embodiment, an apparatus comprises a processing circuitry to detect an occurrence of at least one of a single-stepping event or a zero-stepping event in an execution thread on an architecturally protected enclave and in response to the occurrence, implement at least one mitigation process to inhibit further occurrences of the at least one of a single-stepping event or a zero-stepping event in the architecturally protected enclave.

Abstract: A processor includes a decode unit to decode an instruction that is to indicate a page of a protected container memory, and a storage location outside of the protected container memory. An execution unit, in response to the instruction, is to ensure that there are no writable references to the page of the protected container memory while it has a write protected state. The execution unit is to encrypt a copy of the page of the protected container memory. The execution unit is to store the encrypted copy of the page to the storage location outside of the protected container memory, after it has been ensured that there are no writable references. The execution unit is to leave the page of the protected container memory in the write protected state, which is also valid and readable, after the encrypted copy has been stored to the storage location.

Abstract: A processor includes a decode unit to decode an instruction that is to indicate a page of a protected container memory, and a storage location outside of the protected container memory. An execution unit, in response to the instruction, is to ensure that there are no writable references to the page of the protected container memory while it has a write protected state. The execution unit is to encrypt a copy of the page of the protected container memory. The execution unit is to store the encrypted copy of the page to the storage location outside of the protected container memory, after it has been ensured that there are no writable references. The execution unit is to leave the page of the protected container memory in the write protected state, which is also valid and readable, after the encrypted copy has been stored to the storage location.

Abstract: A method performed by a processor of an aspect includes accessing an encrypted copy of a protected container page stored in a regular memory. A determination is made whether the protected container page was live stored out, while able to remain useable in, protected container memory. The method also includes either performing a given security check, before determining to store the protected container page to a destination page in a first protected container memory, if it was determined that the protected container page was live stored out, or not performing the given security check, if it was determined that the protected container page was not live stored out. Other methods, as well as processors, computer systems, and machine-readable medium providing instructions are also disclosed.

Abstract: A computer system for executing one or more software applications includes a host computer device configured to execute the one or more software applications. The computer system further includes one or more memory devices configured to cryptographically protect volatile memory of the one or more memory devices. The one or more memory devices are configured to provide access to the cryptographically protected volatile memory for the one or more software applications. The host computer device is configured to execute the one or more software applications by executing a portion of the one or more software applications associated with the cryptographically protected volatile memory using a processor of the one or more memory devices.

Abstract: Example methods and systems are directed to reducing latency in providing trusted execution environments (TEES). Initializing a TEE includes multiple steps before the TEE starts executing. Besides workload-specific initialization, workload-independent initialization is performed, such as adding memory to the TEE. 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. Certain steps performed during TEE initialization are identical for certain classes of workloads. Thus, the common parts of the TEE initialization sequence may be performed before the TEE is requested. When a TEE is requested for a workload in the class and the parts to specialize the TEE for its particular purpose are known, the final steps to initialize the TEE are performed.

Abstract: In function-as-a-service (FaaS) environments, a client makes use of a function executing within a trusted execution environment (TEE) on a FaaS server. Multiple tenants of the FaaS platform may provide functions to be executed by the FaaS platform via a gateway. Each tenant may provide code and data for any number of functions to be executed within any number of TEEs on the FaaS platform and accessed via the gateway. Additionally, each tenant may provide code and data for a single surrogate attester TEE. The client devices of the tenant use the surrogate attester TEE to attest each of the other TEEs of the tenant and establish trust with the functions in those TEEs. Once the functions have been attested, the client devices have confidence that the other TEEs of the tenant are running on the same platform as the gateway.

Abstract: Example methods and systems are directed to isolating memory in trusted execution environments (TEEs). In function-as-a-service (FaaS) environments, a client makes use of a function executing within a TEE on a FaaS server. To minimize the trusted code base (TCB) for each function, each function may be placed in a separate TEE. However, this causes the overhead of creating a TEE to be incurred for each function. As discussed herein, multiple functions may be placed in a single TEE without compromising the data integrity of each function. For example, by using a different extended page table (EPT) for each function, the virtual address spaces of the functions are kept separate and map to different, non-overlapping physical address spaces. Partial overlap may be permitted to allow functions to share some data while protecting other data. Memory for each function may be encrypted using a different encryption key.