Providing isolation in virtualized systems using trust domains

Abstract

To provide devices for providing isolation in virtualized systems using trust domains.SOLUTION: In a virtualized system 100, a virtualization server 110 includes: a memory ownership table (MOT) that is access-controlled against software access; a core; a trust domain (TD); a trust domain resource manager (TDRM) to manage the TD; a trust domain control structure (TDCS); and trust domain thread control structures (TDTCSs). The core executes the TDRM, maintains the TDCS for managing global metadata for each TD, maintains an execution state of the TD in at least one of the TDTCSs that is access-controlled against software accesses, and refers to the MOT to obtain at least one key ID corresponding to an encryption key assigned to the TD. The key ID allows a device to decrypt memory pages assigned to the TD in response to the device executing in the context of the TD.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] The present disclosure relates to computer systems, and more particularly to providing isolation in virtualized systems using trust domains. [Background technology]

[0002] Modern processing devices use disk encryption to protect data at rest. However, data in memory is in plain text and vulnerable to attacks. Attackers can retrieve data from memory using a variety of techniques, including software- and hardware-based bus scans, memory scans, hardware probing, and more. This data from memory may include sensitive data, such as privacy-sensitive data, IP-sensitive data, and even keys used for file encryption or communication. The current trend of migrating data and enterprise workloads to the cloud using virtualization-based hosting services offered by cloud service providers further exacerbates data exposure. [Brief explanation of the drawings]

[0003] [Figure 1A] FIG. 1 is a block diagram illustrating an exemplary computing system that provides isolation in a virtualized system using trust domains, according to one embodiment.

[0004] [Figure 1B] FIG. 2 is a block diagram illustrating another exemplary computing system that provides isolation in a virtualized system using trust domains, according to one embodiment.

[0005] [Figure 2A] FIG. 1 is a block diagram of an example trust domain architecture, according to one embodiment.

[0006] [Figure 2B]FIG. 2 is a block diagram of another example of a trust domain architecture, according to one embodiment.

[0007] [Figure 3] FIG. 10 is a block diagram of a further example of a trust domain architecture, according to one embodiment.

[0008] [Figure 4] FIG. 1 is a flow diagram of an exemplary method for providing isolation in a virtualized system using trust domains, according to one embodiment.

[0009] [Figure 5] FIG. 1 is a flow diagram of an exemplary method for performing a trust domain termination routine while providing isolation in a virtualized system using trust domains, according to one embodiment.

[0010] [Figure 6] FIG. 1 is a flow diagram of an exemplary method for performing a trust domain entry routine while providing isolation in a virtualized system using trust domains, according to one embodiment.

[0011] [Figure 7A] FIG. 1 is a block diagram illustrating a microarchitecture for a processor in which an embodiment of the present disclosure may be used.

[0012] [Figure 7B] FIG. 2 is a block diagram illustrating an in-order pipeline and register renaming stage, an out-of-order issue / execution pipeline, implemented in accordance with at least one embodiment of the present disclosure.

[0013] [Figure 8] 1 illustrates a block diagram of a microarchitecture for a processing device including logic circuitry that provides isolation in a virtualized system using trust domains, according to one embodiment.

[0014] [Figure 9] FIG. 1 is a block diagram of a computer system according to one embodiment.

[0015] [Figure 10] FIG. 1 is a block diagram of a computer system according to another embodiment.

[0016] [Figure 11] FIG. 1 is a block diagram of a system-on-chip according to one embodiment.

[0017] [Figure 12] 1 illustrates another embodiment of a block diagram for a computing system.

[0018] [Figure 13] 1 illustrates another embodiment of a block diagram for a computing system. DETAILED DESCRIPTION OF THE INVENTION

[0019] An architecture for providing isolation in virtualized systems using Trust Domains (TDs) is described. A current trend in computing is to place data and enterprise workloads in the cloud using hosting services offered by Cloud Service Providers (CSPs). As a result of hosting data and enterprise workloads in the cloud, CSP customers (referred to herein as tenants) are demanding better security and isolation solutions for their workloads. Specifically, customers are seeking solutions that enable operation of CSP-provided software outside of the tenants' software Trusted Computing Base (TCB). A system's TCB refers to the set of hardware, firmware, and / or software components that have the ability to affect the trust of the system's overall operation.

[0020] In embodiments of the present disclosure, a TD architecture and an instruction set architecture (ISA) extension for the TD architecture (referred to herein as the TD extension (TDX)) are provided to provide confidentiality (and integrity) for customer (tenant) software running in an untrusted CSP infrastructure. The TD architecture, which may be a system-on-chip (SoC) feature, provides isolation between TD workloads and CSP software, such as the CSP's Virtual Machine Manager (VMM). Components of the TD architecture may include: 1) memory encryption via a MK-Total Memory Encryption (MK-TME) engine; 2) resource management functionality, referred to herein as a Trusted Domain Resource Manager (TDRM), which may be a software extension of the Virtual Machine Monitor (VMM); and 3) execution state and memory isolation functionality in the processor, provided via a CPU-managed Memory Ownership Table (MOT) and via CPU access control TD control structures. The TD architecture provides the processor's ability to deploy TDs that leverage the MK-TME engine, MOT, and access control TD control structures for secure operation of TD workloads.

[0021] In one embodiment, tenant software executes in an architectural concept known as a TD. A TD (also referred to as a tenant TD) refers to a tenant workload (e.g., it may comprise just an operating system (OS) with other ring 3 applications running on the OS, or it may comprise a virtual machine (VM) running on a VMM with other ring 3 applications). Each TD operates independently from other TDs in the system and uses logic processors, memory, and I / O allocated by the TDRM on the platform. Each TD is cryptographically isolated in memory using at least one dedicated encryption key from the MK-TME engine to encrypt memory (holding code and / or data) associated with the trust domain.

[0022] In an embodiment of the present disclosure, the TDRM in the TD architecture acts as a host for the TD and has complete control over the cores and other platform hardware. The TDRM assigns logic processors to software in the TD. However, the TDRM does not have access to the execution state of the TD on the assigned logic processor. Similarly, the TDRM assigns physical memory and I / O resources to the TD, but is not involved in accessing the memory state of the TD due to the use of separate encryption keys and other integrity and replay controls on memory enforced by the CPU for each TD. Software running in the TD operates with less privileges so that the TDRM can retain control of platform resources. However, the TDRM cannot affect the confidentiality or integrity of the TD state in memory or in the CPU structure under specified circumstances.

[0023] Conventional systems that provide isolation in virtualized systems do not completely extract CSP software from the tenant's TCB. Furthermore, conventional systems can significantly increase the TCB by using a separate chipset subsystem, which embodiments of the present disclosure avoid. The TD architecture of embodiments of the present disclosure provides isolation between customer (tenant) workloads and CSP software by explicitly reducing the TCB by removing CSP software from the TCB. Embodiments offer a technical improvement over conventional systems by providing secure isolation for CSP customer workloads (tenant TDs), enabling the removal of CSP software from the customer's TCB while meeting the CSP's security and functionality requirements. Additionally, the TD architecture is scalable to multiple TDs, which can support multiple tenant workloads. Furthermore, the TD architecture described herein is general-purpose and can be applied to any dynamic random access memory (DRAM) or storage class memory (SCM)-based memory, such as non-volatile dual in-line memory modules (NV-DIMMs). In this way, embodiments of the present disclosure enable software to take advantage of performance benefits, such as the direct access storage (DAS) mode of NVDIMM for SCM, without compromising platform security requirements.

[0024] 1A is a schematic block diagram of a computing system 100 that provides isolation in a virtualized system using TDs, according to an embodiment of the present disclosure. The virtualization system 100 includes a virtualization server 110 that supports several client devices 101A-101C. The virtualization server 110 includes at least one processor 112 (also referred to as a processing device) that executes a TDRM 180. The TDRM 180 may include a VMM (also referred to as a hypervisor) that may instantiate one or more TDs 190A-190C that are accessible by the client devices 101A-101C via a network interface 170. The client devices 101A-101C may include, but are not limited to, desktop computers, tablet computers, laptop computers, netbooks, notebook computers, personal digital assistants (PDAs), servers, workstations, mobile phones, mobile computing devices, smartphones, Internet appliances, or any other type of computing device.

[0025] A TD may refer to a tenant (e.g., customer) workload. A tenant workload may, for example, include only an OS with other ring 3 applications running on the OS, or may include a VM running on a VMM with other ring 3 applications. In embodiments of the present disclosure, each TD may be cryptographically isolated in memory using a separate, dedicated key to encrypt the memory (holding code and data) associated with the TD.

[0026] Processor 112 may include one or more cores 120 (also referred to as processing cores 120), range registers 130, a memory management unit (MMU) 140, and output ports 150. FIG. 1B is a schematic block diagram of a detailed view of processor core 120 executing TDRM 180, communicating with MOT 160 and one or more trust domain control structures (TDCS) 124 and trust domain thread control structures (TDTCS) 128, as shown in FIG. 1A. TDTCS and TD-TCS may be used interchangeably herein. Processor 112 may be used in systems including, but not limited to, desktop computers, tablet computers, laptop computers, netbooks, notebook computers, PDAs, servers, workstations, mobile phones, mobile computing devices, smartphones, Internet appliances, or any other type of computing device. In another embodiment, processor 112 may be used in an SoC system.

[0027] Computing system 100 represents a processing system based on PENTIUM III, PENTIUM 4, Xeon™, Itanium, XScale™, and / or StrongArm™ microprocessing devices available from Intel Corporation of Santa Clara, California, although other systems (including PCs with other microprocessing devices, engineering workstations, set-top boxes, etc.) may also be used. In one embodiment, sample system 100 runs a version of the Windows operating system available from Microsoft Corporation of Redmond, Washington, although other operating systems (e.g., UNIX and Linux), embedded software, and / or graphics user interfaces may also be used. Accordingly, embodiments of the present disclosure are not limited to any particular combination of hardware circuitry and software.

[0028] One or more processing cores 120 execute instructions for the system. Processing core 120 includes, but is not limited to, prefetch logic to fetch instructions, decode logic to decode instructions, execution logic to execute instructions, etc. In an embodiment, computing system 100 includes components such as processor 112 and uses execution units that include logic to execute algorithms to process data.

[0029] Virtualization server 110 includes main memory 114 and secondary storage 118 to store program binaries and OS driver events. Data in secondary storage 118 may be stored in blocks called pages, and each page may correspond to a set of physical memory addresses. Virtualization server 110 may use virtual memory management, in which applications executed by cores 120, such as TDs 190A-190C, use virtual memory addresses that are mapped to guest physical memory addresses, which are mapped to host / system physical addresses by MMU 140.

[0030] Core 120 may execute MMU 140, which loads pages from secondary storage 118 into main memory 114 (including volatile and / or non-volatile memory) for faster access by software executing on processor 112 (e.g., on the core). When one of TDs 190A-190C attempts to access a virtual memory address that corresponds to the physical memory address of a page loaded into main memory 114, MMU 140 returns the requested data. Core 120 may execute the VMM portion of TDRM 180, which translates guest physical addresses into host physical addresses in main memory and provides parameters for a protocol that allows core 120 to read, walk, and translate these mappings.

[0031] In one embodiment, processor 112 implements the TD architecture and an ISA extension for the TD architecture (TDX). The TD architecture provides isolation between TD workloads 190A-190C and from CSP software (e.g., TDRM 180 and / or CSP VMM (e.g., root VMM 180)) executing on processor 112. Components of the TD architecture may include: 1) memory encryption via MK-TME engine 145, 2) resource management functionality, referred to herein as TDRM 180, and 3) execution state and memory isolation functionality in processor 112 provided via MOT 160 and via access control TD control structures (i.e., TDCS 124 and TDTCS 128). The TDX architecture provides the processor 112 with the ability to deploy TDs 190A-190C that utilize the MK-TME engine 145, MOT 160, and access control TD control structures (i.e., TDCS 124 and TDTCS 128) for secure operation of the TD workloads 190A-190C.

[0032] In an embodiment of the present disclosure, the TDRM 180 functions as a host and has complete control over the cores 120 and other platform hardware. The TDRM 180 assigns logic processors to software in the TDs 190A-190C. However, the TDRM 180 does not have access to the execution state of the TDs 190A-190C on the assigned logic processors. Similarly, the TDRM 180 assigns physical memory and I / O resources to the TDs 190A-190C, but is not involved in accessing the memory state of the TD 190A due to separate encryption keys and other integrity and replay controls on the memory.

[0033] With separate encryption keys, the processor may utilize the MK-TME engine 145 to encrypt (and decrypt) memory used during execution. In total memory encryption (TME), any memory access by software running on the core 120 may be encrypted in memory with an encryption key. MK-TME is an extension of TME that allows the use of multiple encryption keys (the number of supported keys is implementation dependent). The processor 112 may utilize the MK-TME engine 145 to encrypt different pages with different MK-TME keys. The MK-TME engine 145 may be utilized in the TD architecture described herein to support one or more encryption keys for each TD 190A-190C, helping to achieve cryptographic isolation between different CSP customer workloads. For example, when the MK-TME engine 145 is utilized in the TD architecture, the CPU by default forces the TD (all pages) to be encrypted with a TD-specific key. Additionally, the TD may further select whether a particular TD page is plaintext or encrypted with a different ephemeral key that is opaque to the CSP software.

[0034] Each TD 190A-190C is a software environment supporting a software stack consisting of a VMM (e.g., using a virtual machine extension (VMX)), an OS, and / or application software (hosted by the OS). Each TD 190A-190C operates independently of the other TDs 190A-190C and uses logic processors, memory, and I / O allocated by the TDRM 180 on the platform. Software executing on the TDs 190A-190C operates with less privileges so that the TDRM 180 retains control of platform resources. However, the TDRM cannot affect the confidentiality or integrity of the TDs 190A-190C under specified circumstances. Further details of the TD architecture and the TDX are described in more detail below with reference to FIG. 1B.

[0035] Embodiments of the present disclosure are not limited to computer systems. Alternative embodiments of the present disclosure may be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include mobile phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications may include microcontrollers, digital signal processing devices (DSPs), systems-on-chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system capable of executing one or more instructions according to at least one embodiment.

[0036] While one embodiment may be described in the context of a single-processing device desktop or server system, alternative embodiments may be included in a multi-processing device system. Computing system 100 may be an example of a "hub" system architecture. Computing system 100 includes a processor 112 that processes data signals. As one illustrative example, processor 112 may include a complex instruction set computing (CISC) microprocessing device, a reduced instruction set computing (RISC) microprocessing device, a very long instruction word (VLIW) microprocessing device, a processing device implementing a combination of instruction sets, or any other processing device, such as a digital signal processing device. Processor 112 is coupled to a processing device bus that transmits data signals between processor 112 and other components in computing system 100, such as main memory 114 and / or secondary storage 118, which store instructions, data, or any combination thereof. Other components of computing system 100 may include a graphics accelerator, a memory controller hub, an I / O controller hub, a wireless transceiver, a flash BIOS, a network controller, an audio controller, a serial expansion port, an I / O controller, etc. These elements perform their conventional functions well known to those skilled in the art.

[0037] In one embodiment, processor 112 includes a level 1 (L1) internal cache memory. Depending on the architecture, processor 112 may have a single internal cache or multiple levels of internal cache. Other embodiments include a combination of both internal and external cache, depending on the particular embodiment and needs. The register file stores different types of data in various registers, including integer registers, floating-point registers, vector registers, banked registers, shadow registers, checkpoint registers, status registers, configuration registers, and an instruction pointer register.

[0038] Note that the execution units may or may not have floating point units. In one embodiment, processor 112 includes a microcode (ucode) ROM that stores microcode that, when executed, performs algorithms for specific macro-instructions or processes complex scenarios, where the microcode is potentially updatable to address logic bugs / fixes for processor 112.

[0039] Alternative embodiments of the execution unit may also be used in microcontrollers, embedded processing devices, graphics devices, DSPs, and other types of logic circuits. System 100 includes main memory 114 (which may also be referred to as memory 114). Main memory 114 may include DRAM devices, static random access memory (SRAM) devices, flash memory devices, or other memory devices. Main memory 114 stores instructions and / or data represented by data signals to be executed by processor 112. Processor 112 is coupled to main memory 114 via a processing device bus. A system logic chip, such as a memory controller hub (MCH), may be coupled to the processing device bus and main memory 114. The MCH may provide a high-bandwidth memory path to main memory 114 for instruction and data storage, as well as for storing graphics commands, data, and textures. The MCH may also be used, for example, to route data signals between processor 112, main memory 114, and other components in system 100, and to bridge data signals between the processing device bus, memory 114, and system I / O. The MCH may be coupled to memory 114 via a memory interface. In some embodiments, the system logic chip may provide a graphics port for coupling to a graphics controller via an Accelerated Graphics Port (AGP) interconnect.

[0040] Computing system 100 may also include an I / O controller hub (ICH). The ICH may provide direct connectivity to several I / O devices via a local I / O bus, which is a high-speed I / O bus for connecting peripherals to memory 114, the chipset, and the processor 112. Some examples are an audio controller, a firmware hub (flash BIOS), a wireless transceiver, data storage, legacy I / O controllers including user input and keyboard interfaces, serial expansion ports such as Universal Serial Bus (USB), and a network controller. Data storage devices may include hard disk drives, floppy disk drives, CD-ROM devices, flash memory devices, or other mass storage devices.

[0041] For another embodiment of the system, the instructions executed by the processing device core 120 described above may be used in conjunction with a system-on-chip. One embodiment of a system-on-chip is comprised of a processing device and memory. The memory for one such system is flash memory. The flash memory may be located on the same die as the processing device and other system components. Additionally, other logic blocks, such as a memory controller or a graphics controller, may also be located on the system-on-chip.

[0042] Referring to FIG. 1B, this figure shows a block diagram of the processor 112 of FIG. 1A according to one embodiment of the present disclosure. In one embodiment, the processor 112 may execute the application stack 101 via a single core 120 or across several cores 120. As described above, the processor 112 may provide the TD architecture and TDX to provide confidentiality (and integrity) for customer software running at the customer / tenant (i.e., TD 190A) in an untrusted cloud service provider (CSP) infrastructure. The TD architecture provides memory isolation via MOT 160, CPU state isolation incorporating CPU key management via TDCS 124 and / or TDTCS 128, and a CPU measurement infrastructure for the TD 190A software.

[0043] In one embodiment, the TD architecture provides an ISA extension (referred to as TDX) that supports secure operation of the OS and OS-managed applications (virtualized and non-virtualized). With TDX enabled, a platform such as one including processor 112 can function as multiple encrypted contexts, referred to as TDs. For ease of explanation, a single TD 190A is shown in FIG. 1B. Each TD 190A may run a VMM, a VM, an OS, and / or applications. For example, TD 190A is shown hosting VM 195A.

[0044] In one embodiment, TDRM 180 may be included as part of a VMM function (e.g., a root VMM). VMM may refer to software, firmware, or hardware that creates, runs, and manages virtual machines (VMs), such as VM 195A. Note that a VMM may create, run, and manage one or more VMs. As shown, VMM 180 is included as a component of one or more processing cores 120 of processing device 112. VMM 180 may create and run VM 195A and assign one or more virtual processors (e.g., vCPUs) to VM 195A. VM 195A may be referred to herein as guest 195A. The VMM may enable VM 195A to access the underlying hardware of a computing system, such as computing system 100 of FIG. 1A. VM 195A may run a guest operating system (OS). The VMM may manage the execution of the guest OS. The guest OS may function to control the access of the virtual processor of the VM 195A to the underlying hardware and software resources of the computing system 100. Note that if there are various VMs 195A running on the processing device 112, a VMM may manage each of the guest OSs running on the various guests. In some embodiments, a VMM may be implemented on the TD 190A and manages the VMs 195A. This VMM may be referred to as a tenant VMM and / or a non-root VMM and is discussed in more detail below.

[0045] The TDX also provides a programming interface for the TD management layer of the TD architecture, referred to as the TDRM 180. The TDRM may be implemented as part of the CSP / root VMM. The TDRM 180 manages the operation of the TD 190A. While the TDRM 180 may allocate and manage resources such as CPU, memory, and input / output (I / O) to the TD 190A, the TDRM 180 is designed to operate outside of the TCB of the TD 190A. The TCB of a system refers to the set of hardware, firmware, and / or software components that have the ability to affect trust for the overall operation of the system.

[0046] In one embodiment, the TD architecture is therefore a feature that protects software running in the TD 190A. As described above, components of the TD architecture may include: 1) memory encryption via a TME engine (e.g., the MK-TME engine 145 of FIG. 1A) with a multi-key extension to the TME, 2) a software resource management layer (TDRM 180), and 3) execution state and memory isolation features in the TD architecture.

[0047] FIG. 2A is a block diagram illustrating an exemplary computing system implementing TD architecture 200. TD architecture 200 supports two types of TDs. The first type is a TD where a tenant trusts a CSP to enforce confidentiality and does not implement the TD architecture of an embodiment of the present disclosure. This type of legacy TD is shown as TD1 210. TD1 210 is a CSP TD with a CSP VMM-managed TCB 202. TD1 210 may include a CSP VMM 212 that manages a CSP VM 214 and / or one or more tenant VMs 216A, 216B. In this case, tenant VMs 216A, 216B are managed by the CSP VMM 212, which resides within the TCB 202 of the VMs 216A, 216B. In an embodiment of the present disclosure, tenant VMs 216A, 216B may further utilize memory encryption via TME or MK-TME in this model (described further below).

[0048] Another type of TD is one in which the tenant does not trust a CSP to enforce confidentiality and therefore relies on a CPU with the TD architecture of an embodiment of the present disclosure. This type of TD is shown in two variations as TD2 220 and TD3 230. TD2 220 is shown with a virtualization mode (e.g., VMX) being utilized by the tenant VMM (non-root) 222 running on TD2 220 for managed tenant VMs 225A, 225B. TD3 230 does not include software that uses the virtualization mode, but instead runs an enlightened OS 235 directly on TD3 230. TD2 220 and TD3 230 are tenant TDs with a hardware-enforced TCB 204 as described in an embodiment of the present disclosure. In one embodiment, TD2 220 or TD3 230 may be the same as TD 190A described with reference to FIG. 1A and / or FIG. 1B.

[0049] The TDRM 180 manages the lifecycle of all three types of TDs 210, 220, 230, including resource allocation. However, the TDRM 180 is not in the TCB for TD types TD2 220 and TD3 230. The TD architecture 200 does not impose any architectural constraints on the number or combination of TDs active on the system. However, software and specific hardware limitations in a particular implementation may limit the number of TDs running simultaneously on the system due to other constraints.

[0050] FIG. 2B is a block diagram illustrating an example of a TD architecture 250 and the interaction between a TD 220 and a TDRM 180. In one embodiment, the TD 220 and the TDRM 180 are identical to their counterparts described with respect to FIG. 2A. The TD architecture 250 may be the same as the TD architecture provided by the computing device 100 of FIGS. 1A and 1B and / or the TD architecture 200 of FIG. 2A. The TD architecture 250 provides a layer that manages the lifecycle of TDs active on the system. Processor support for TDs is provided in the form of processor operations called TDX operations. There are two types of TDX operations: resource manager operations and tenant operations. Generally, the TDRM 180 executes with TDX resource manager operations, and TDs, such as TD2 220, execute with TDX tenant operations. The transition between resource manager operations and tenant operations is called a TDX transition.

[0051] There are two types of TDX transitions: TD entry 270 and TD exit 260. A transition from a TDX resource manager operation to a TDX tenant operation is called a TD entry 270. A transition from a TDX tenant operation to a TDX resource manager operation is called a TD exit 260.

[0052] Processor behavior in TDX resource manager operation is similar to when it is outside of TDX operation. The main differences are that a set of TDX operations (TDX instructions) is available, and the values ​​that can be loaded into certain control registers are limited, restricting the modes and capabilities of the TDRM 180.

[0053] Processor behavior in TDX tenant operations is similarly restricted to facilitate isolation. For example, instead of normal operation, certain events cause the TDRM 180 to perform a TD termination 260. These TD terminations 260 prevent the TDRM 180 from modifying the behavior or state of the TD 220. The TDRM 180 uses platform functions and retains control of platform resources. Software executing on the TD 220 can use software visible information to determine that it is running on the TD 220 and enforce local measurement policies on additional software loaded on the TD 220. However, verification of the security state of the TD 220 is performed by a remote attestation party to ensure confidentiality.

[0054] The TD architecture 250 is designed to minimize compatibility impacts to software that relies on virtualization when running on the TD 220, thus leaving most interactions unchanged between the VMs 225A, 225B running in tenant operation and the tenant VMM 222 running in tenant operation. In the absence of a VMM 222 on the TD 220, the VM OS can be modified to function with the TDRM 180 as the root VMM.

[0055] In one embodiment, the TDRM 180 may explicitly decide to have the TD termination 260, for example, terminate the TD 220 or manage memory resources (e.g., yield allocated memory resources, request free memory resources, etc.). The TD architecture 250 also provides the TDRM 180 the ability to force the TD termination 260 to preempt. Upon TD termination 260, the TD architecture forces the execution state of the TD 220 to be saved in CPU access control memory allocated to the TD 220 and encrypted using the TD 220's unique encryption key (discussed further below) that is invisible to the TDRM 180 or other TDs to protect the confidentiality of the TD state from the TDRM 180 or other TDs. The TD execution state may similarly be protected from spoofing, remapping, and / or replay via integrity controls on the memory.

[0056] TD input 270 is a complementary event to TD exit 260. For example, TD input 270 may occur when TDRM 180 schedules TD 220 to run on a logic processor and transfers execution to software running on TD 220. During TD input 270, TD architecture 250 forces the execution state of TDRM 180 to be saved to memory owned by the TDRM, encrypted using a unique encryption key assigned for the sole use of TDRM 180.

[0057] A TD, such as TD 220, may be set up by TDRM 180 using the TDCREATE (creates a TDCS), TDTCREATE (creates a TD-TCS), and TDADDPAGE instructions, which cause TDRM 180 to encrypt memory belonging to TD 220 with the TD's unique encryption key, which is not visible or accessible to TDRM 180 or other TDs. Prior to executing any instruction belonging to a TD, all TD memory is encrypted with the TD's unique key. While specific instruction names are referenced herein, other names for these instructions may be utilized in embodiments of the present disclosure and are not limited to the specific names provided herein.

[0058] In one embodiment, the TDRM 180 may boot each TD 220 with a small software image (similar to an IBB or initial boot block) after signature verification and record the IBB measurements (for subsequent attestation) using the platform root of trust. It is the IBB software running in the TD 220 that is responsible for completing the measured boot of the TD 220 and requesting additional resources from the TDRM 180. The TD 220 has the option of using a single encryption key for the entire TD 220 or additional encryption keys for different tenant VMs 225A, 225B (and / or different memory resources, such as containers or NVRAM) when running within the TD 220. Thus, when the TD 220 is initially set up, it uses a dedicated CPU-generated MK-TME key. Thereafter, the TD 220 may optionally set up additional MK-TME encryption keys for each tenant software management context (e.g., tenant VMs 225A, 225B, containers, or other memory types) running within the TD 220.

[0059] To minimize software compatibility impacts to both VMMs of a CSP (e.g., TDRM root VMM 180 and tenant VMM 222), virtualization (e.g., VMX) operations can remain unmodified within the TD 220 in the TD architecture 250. Similarly, operations of VMM software, such as extended page table (EPT) management, can remain under the control of the tenant VMM 222 (if it is active in the TD 220 and is not managed by the TDRM 180). Because the TDRM 180 allocates physical memory for each TD 220, the TD architecture 250 includes a MOT (i.e., the MOT 160 described with reference to FIGS. 1A and 1B). The processor 112 references the TDRM 180 manages the MOT and assigns memory allocations to the TD 220. This allows the TDRM 180 full capability to manage memory as a resource without having any visibility to the data residing in the allocated TD memory. In some embodiments, as described above, the platform (e.g., root) VMM and TDRM 180 may be within the same cryptographic key domain and therefore share memory management and scheduler functions (but still remain outside the tenant's TCB).

[0060] 3 is a block diagram illustrating another example of a TD architecture 300. The TD architecture 300 illustrates the I / O concepts for a TD. In one embodiment, the TD architecture 300 may allow all I / O devices (e.g., NIC 320, storage 330, single root input / output virtualization (SR-IOV) NIC 340, etc.) to be attached to a TD1 210 (e.g., legacy TD1 210) that trusts the CSP and TDRM. In one embodiment, the TD architecture 300 may not allow direct assignment of devices (including SR-IOV and extensible I / O) to a TD (e.g., tenant TD2 220) that does not trust the CSP software, such as tenant TD2 220. Instead, the TDRM 180 may share memory 310 between a CSP TD, such as TD1 210, and other TDs, such as tenant TD2 220, and may provide the ability to implement synthetic (“syn”) devices (e.g., syn NIC 325, syn storage 335) in a non-CSP TD (e.g., tenant TD2 220). In some embodiments, a tenant TD that does not trust the CSP software, such as tenant TD2 220, may be responsible for protecting I / O data. The TD architecture 300 may not protect I / O data exposed via shared memory 310. In some embodiments, the I / O data may be protected using existing security protocols between the communication endpoints.

[0061] 1B, MOT 160 (which may be referred to as TD-MOT) is a structure, such as a table, managed by processor 112 to enforce the allocation of physical memory pages to executing TDs, such as TD 190A. Processor 112 also uses MOT 160 to enforce that physical addresses referenced by software acting as tenant TD 190A or TDRM 180 cannot access memory that has not been explicitly assigned to it.

[0062] MOT 160 enforces the following properties: First, software external to TD 190A should not be able to access (read / write / execute) in plaintext any memory belonging to a different TD (this includes TDRM 180). Second, memory pages allocated to a particular TD, such as TD 190A, via MOT 160 should be accessible from any processor in the system (that is, the processor running the TD to which the memory is allocated).

[0063] The MOT160 structure is used to hold metadata attributes for each 4KB page of memory. Additional structures can be defined for additional page sizes (2MB, 1GB). The metadata for each 4KB page of memory is directly indexed by the physical page address. In other embodiments, other page sizes can be supported by a hierarchical structure (such as a page table).

[0064] A 4KB page referenced in the MOT 160 may belong to one executing instance of the TD 190A. A 4KB page referenced in the MOT 160 may be valid memory or may be marked as invalid (and thus may be an IO, for example). In one embodiment, each TD instance 190A contains one page that holds the TDCS 124 for that TD 190A.

[0065] In one embodiment, the MOT 160 is aligned on a 4KB boundary of memory and occupies a physically contiguous region of memory that is protected from access by software after platform initialization. In an embodiment, the MOT is a microarchitectural structure and cannot be directly accessed by software. Architecturally, the MOT 160 maintains the following security attributes for each 4KB page of host physical memory: - Page Status 162 - Valid / Invalid bit (Whether the page is valid memory or not) - Page Categories - DRAM, NVRAM, IO, Reservation -Page Status 163-(4-bit vector) Specifies if the page is: - bit 1 - free (pages not allocated to a TD and not in use by a TDRM) - bit 2 - Allocated (page allocated to TD or TDRM) - bit 3 - blocked (page blocked while in the process of being freed / (reallocated)) - bit 4 - Pending (dynamic page allocated to TD but not yet accepted by TD) - TDID164 (40 bits) TD identifier that assigns a page to a specific unique TD. Address of TDCS.

[0066] In some embodiments, extended MOT 160 entries may be supported, further including:

[0067] - Page Key ID 165 - (8 bits - size is implementation specific) Specifies the per-page encryption key that is expected to match the Key ID fetched during the processor page walk for the physical memory referenced by the TD. If the MOT 160 entry is not an extended entry, the Page Key ID is derived from the TDCS 124. One of the Key ID values ​​specified in the MOT can be used to share memory contents with the TDRM (or root VMM). Shared pages can hold I / O buffers to be sent to hardware devices managed by the TDRM. Similarly, shared pages can be used for emulation of virtual devices exposed by the TDRM to the TD.

[0068] - Guest Physical Address 166 - (52 bits) Specifies the expected guest physical address used by software running in the TD. (This field is used when expecting the TDRM 180 to perform memory remapping and implement the ability to swap memory.)

[0069] - Guest Permissions 167 - Assert on last page (read, write, execute for user and supervisor). There can be multiple sets of these permission bits to support VMMs running in the TD.

[0070] MOT 160 may be enabled when TDX is enabled in processor 112 (e.g., after CPUID-based enumeration, via the CR4 enable bit). Once MOT 160 is enabled, it may be used by processor 112 to enforce memory access control for all physical memory accesses initiated by software, including TDRM 180. In one embodiment, access control is enforced during page walks for memory accesses made by software. Physical memory accesses performed by processor 112 to memory not allocated to tenant TD 190A or TDRM 180 fail with Abort page semantics.

[0071] In an embodiment of the present disclosure, the TDRM 180 manages memory resources through the MOT 160 using a MOT operation instruction (TDMOTOP) with the following instruction leaf:

[0072] Add Page to MOT (TDMOTADDPAGE)—marks a free MOT 160 entry corresponding to a host physical address (HPA) as being allocated (exclusively) to the TD 190A specified by the TDID. Any other previous page state will cause a fault. This instruction forces a cross-thread TLB shootdown to ensure that no other TDs 190A are caching a mapping to this HPA. This instruction leaves the TDRM 180 to call. If the TDRM 180 has enabled the extended MOT, the instruction may then specify an initial guest physical address (GPA) that is mapped to the specified HPA. The processor 112 verifies that the GPA is mapped to the HPA by walking the EPT structure managed by the TDRM 180. A variant of add page may be implemented in which Allocate Page to TD (TDMOTAUGPAGE) does not capture measurements of the page.

[0073] Discard Page from MOT (TDMOTREVOKEPAGE) - Marks an allocated page as a free page. This instruction forces a cross-thread TLB shootdown, ensuring that subsequent TD 190A accesses check HPA ownership and that the page contents are cleared by the processor 112. A TD 190A access that experiences a MOT 160 page fault during a TLB fill causes the processor 112 to invalidate the TDCS 124, which prevents further TDs from entering the TD 190A. This instruction leaf can be called by the TDRM 180.

[0074] Block Page in MOT (TDMOTBLOCKPAGE) - Marks the free or allocated MOT 160 entry corresponding to the HPA as blocked for software use. Any other previous page state causes a TDRM 180 fault. This instruction forces a cross-thread TLB shootdown and ensures that subsequent TD 190A accesses check HPA ownership. This instruction leaf can be called by the TDRM 180.

[0075] Unblock Page in MOT (TDMOTUNBLOCKPAGE) - Marks the blocked MOT 160 entry corresponding to the HPA as valid for software use / allocation. Any other previous page state causes a fault. This instruction leaf can be called by the TDRM 180.

[0076] After the TD software clears any secrets in the memory, memory allocated to the TD 190A can be returned to the TDRM 180 via an explicit TDCALL. The MOT 160 extended operation is used when (1) the VMM in the TD 190A may have a remapped GPA in use within the TD and / or (2) the TDRM 180 wants to swap memory allocated to the TD 190A. In both of the above cases, a TDRM 180 EPT violation is generated with a mismatched GPA used during the page walk. The following extended MOT instruction leaf corresponds to the above cases:

[0077] Modify PGA in MOT (TDMOTMODPMA)—To handle the first case above, the TDRM 180 utilizes this extended MOT 160 instruction to update the MOT 160 security attributes for pages used by the TD 190A. The TDRM 180 provides the GPA used by the CPU to walk the TD VMM managed EPT structure to obtain the new GPA referenced by the TD VMM. The processor 112 then performs a walk of the TDRM 180 EPT to find the referenced HPA, and if the page is assigned to an active TD 190A, the expected GPA attributes are updated to match the mismatched GPA reported during the faulting walk. The TDRM 180 may then resume the TD 190A.

[0078] For the second case above, the TDRM 180 should already unmap the GPA from its EPT structure and use an instruction (TDMOTBLOCKPAGE) to block the page in the MOT during the fault, mark the page as unusable by software (with flush), and use the extended MOT 160 instruction. TDEXTRACT and TDINJECT create cryptographically protected, swappable versions of the page contents that can be restored relative to the newly allocated HPA. The TDEXTRACT (and TDINJECT) instructions capture (and respectively verify) cryptographically signed integrity information for the swapped TD page, allowing it to be verified when restored. The cryptographic information may include a counter that prevents a malicious TDRM from replaying the old page.

[0079] In one embodiment, TDRM 180 initialization begins by enabling TDX in processor 112, for example, by setting the CR4.TDXE bit or via a VMX MSR control bit during VMXON. TDX support can be enumerated via CPUID. Once TDX is enabled, TDRM 180 performs (i.e., executes) the TDX mode enable instruction (TDXON), enabling TDX mode for the processor. Alternatively, the mode can be enabled as part of VMXON. TDXON registers a naturally aligned 4-KB memory region that the logic processor uses for the TDRM 180 state region. In one embodiment, the TDRM 180 state region is stored in TDRM control structure (TDRCS) 182 as TDRM state 185. The TD-RCS can also be implemented as a new type of VMCS that contains only host state, control, and TD termination information. In one embodiment, the TDCS and TD-TCS are access controlled via the MOT 160 (e.g., an encryption key ID stored in the MOT 160 is used to enforce memory access control). In another embodiment, the TDCS and TD-TCS are access controlled via storage in a restricted range register, such as range register 130, of the processor 112 that is inaccessible to software access. The TDRM state 185 is described in more detail below. The physical address of the 4KB page used for the TDRCS 182 is provided in an operand to TDXON. The TDRM 180 makes this page inaccessible to all TDs 190A via the MOT 160. The TDRM 180 should initialize and access the TDRM state 185. The TDRM 180 should use a separate TDRM state 185 for each logic processor.

[0080] In one embodiment, exemplary TDRM states 185 initialized by TDRM 180 and loaded by processor 112 at TD exit may include, but are not limited to, the following states shown below in Table 1: [Table 1]

[0081] The following processor states are automatically set / fixed during TD termination (and therefore not specified in TD-RCS): -CR0, CR4 for 64-bit mode (may require additional CR4 mask value) -DR7, Scrub DR:Clear:The effect of the PDR bit must be considered. -IA32_DEBUGCTL, IA32_PERF_GLOBAL_CTRL, IA32_PAT, IA32_BNDCFGS -IA32_EFER (ensures 64-bit mode) -Segment register (base-only access): same as VM exit -RFLAGS: same as VM exit - set to 0x2 -LDTR: Same as VM termination - Null

[0082] The following processor state is automatically cleared during TD exit (and therefore is not specified in TD-RCS): -IA32_SYSENTER_CS / EIP / ESP -IA32_KERNEL_GS_BASE -IA32_STAR / FMASK / LSTAR -GPR (excluding RSP) -XSAVE state Extended state (x87 / SSE, CET, etc.) - can be treated as any and other conditional state.

[0083] The TD-RCS also holds a control field and a termination information structure (for reporting TD termination information), as provided below in Table 2. [Table 2]

[0084] Table 3 shown below details the termination information fields in the TD-RCS. [Table 3]

[0085] In one embodiment, the TD 190A may be created and activated by the TDRM 180. The TDRM 180 creates the TD 190A using the TD creation instructions (TDCREATE and TDTCREATE). The TDRM 180 selects a 4KB-aligned region of physical memory and provides it as a parameter to the TD creation instruction. This memory region is used as the TDCS 124 for the TD 190A. When executed, the TDCREATE instruction causes the processor 112 to verify that the destination 4KB page is allocated to the TD (using the MOT 160). The TDCREATE instruction also causes the processor 112 to generate an ephemeral memory encryption key and key ID for the TD 190A and store the key ID in the TDCS 124. The processor 112 then initializes the page contents on the destination page using the encryption key assigned to the TD. In one embodiment, initializing the page contents includes starting the TD state of the TD, which is described further below with respect to the TDTCS 128. The TDCREATE instruction then causes the processor 112 to initialize a hash for the TD measurement in the TDCS 124.

[0086] In one embodiment, the TDRM 180 sets up the IBB code / data for the TD 190A using the TDADDPAGE instruction (described above), specifying the address of the TDCS 124 page (in the TD 190A) as parameters, the address of the code / data page for the TD image in the TDRM address space, and the physical page assigned to the TD 190A. The processor 112 then verifies that the destination 4 KB page is assigned to the TD 190A. Once verified, the processor 112 expands the hash for the TD 190A in the TDCS 124. The processor then copies the page contents from the source to the destination page using the unique encryption key assigned to the TD 190A.

[0087] The TDRM 180 provides the TD boot configuration via data pages containing the physical memory map (and identifying page tables). The TDRM 180 initializes the physical memory, and the processor 112 verifies that pages are allocated to the TD 190A and identifies the page tables. The TDRM 180 then completes the measurement of the TD 190A using the TDINIT instruction. The TDRM 180 can then begin execution of the TD 190A using the TDENTER instruction (which uses the TDTCS 128, as described further below).

[0088] Referring now to the TDCS 124, this control structure specifies the controls that the processor 112 initializes when the TD 190A is successfully created. The TDCS 124 is available when the TD 190A is enabled. In one embodiment, the TDCS occupies a 4K naturally aligned memory region. A page identified as the TDCS 124 in the MOT 160 is blocked to software reads / writes after the TDCREATE instruction is successfully executed. In one embodiment, the TDCS 124 is access controlled via the MOT 160 (e.g., as described above, an assigned key ID for the TDCS 124 stored in the MOT 160 is used during processor 112 page walks to prevent unauthorized software reads / writes). In another embodiment, the TDCS 124 is access controlled via storage in a restricted range register of the processor 112 that is inaccessible to software access. The TDCS 124 may include, but is not limited to, the following fields shown below in Table 4: [Table 4]

[0089] The TDCS.ATTRIBUTES field has the following bit structure shown below in Table 5: [Table 5]

[0090] The TD 190A may request the TDRM 180 to allocate N logic processors (CPUs) to the TD 190A. For each requested CPU, the TDRM 180 allocates TDADDPAGE (parameter<op, TDCS, TD CPU index, HPA> ) to add the TDTCS 128 page to TD 190A. Processor 112 verifies that the destination 4 KB page is allocated to TD 190A. Processor 112 updates TCSList[index] 142 in TDCS 124 for TD 190A. TDTCS 128 may back-reference its parent TDCS 124 (specified in the TDADDPAGE instruction parameters).

[0091] TDRM180 sets TDENTER (parameter) to TD190A.<TDCS, CPU index> ) to the TDTCS 128. This activates the TDTCS 128 (and the referenced TDCS 124). The TDENTER instruction checks that the TDTCS 128 is not already active. At TDENTER, the processor 112 activates TD 190A key ID enforcement by the page miss handler (PMH) / TLB. The processor 112 then loads the TD state from the TDTCS 128 and begins TD 190A execution.

[0092] TDTCS 128 maintains execution state for logic processors assigned to TD 190A. If a TD exit condition occurs while processor 112 is in TD tenant mode, TD exit saves the tenant's execution state to TDTCS 128. In one embodiment, TDTCS 128 is access controlled via MOT 160 (e.g., as described above, a key ID is used during page walks of processor 112 to prevent unauthorized software reads / writes). In another embodiment, TDTCS 128 is access controlled via storage in restricted range registers of processor 112 that are inaccessible to software access.

[0093] If a TD exit occurs while processor 112 is operating in the context of a non-root VMM in TD 190A, the TD exit performs a VM exit (e.g., VM exit 280 in FIG. 2B) to the (not yet reported) TD VMM (e.g., TD VMM 222), saves the tenant VMM state to TDTCS 128, and performs a TD exit (toggles key ID enforcement). A subsequent TDENTER called by TDRM 180 performs the key-ID enforcement switch and restores the tenant state from TDTCS 128 (in TD 190A) to resume the tenant VMM or OS. Correspondingly, if processor 112 was operating in the context of a non-root VMM during the previous TD exit, TD Entry reports the VM exit (on a TD entry) to the tenant VMM.

[0094] As described above, the TDTCS 128 holds the execution state of the TD 190A. The execution state of the TD 190A is stored in the TDTCS 128. The TDTCS may be non-architectural and may hold the fields detailed below in Tables 6 through 9. [Table 6] [Table 7] [Table 8] [Table 9]

[0095] In one embodiment, the TD 190A can be destroyed by the TDRM 180. The TDRM 180 destroys the TD 190A using the TD destruction instructions (TDDESTROY and TDTDESTROY). The CPU verifies that all memory allocated to the TD has been discarded, and all TD-TCSs are destroyed before it allows the TDCS to be destroyed.

[0096] 4 is a flow diagram of an exemplary method 400 for providing isolation in a virtualized system using TD, according to one embodiment. Method 400 may be performed by processing logic, which may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., operations performed by an MCU), firmware, or a combination thereof. In one embodiment, method 400 is performed by processing device 112 of FIG. 1A or FIG. 1B. In another embodiment, method 400 is performed by any of the processing devices described with respect to FIGS. 7A-12. Alternatively, other components of computing system 100 (or software running on processing device 112) may perform some or all of the operations of method 400.

[0097] 4, method 400 begins at block 410 when processing logic executes a TDRM that manages a TD with a VM, the TD being executed by a processing device. At block 420, the processing logic maintains a TDCS for managing global metadata of one or more of the TD executed by the processing logic or other TDs. Next, at block 430, the processing logic maintains the execution state of the TD in the TD-TCS, which is access-controlled against software access from at least one of the TDRM, the VMM, or other TDs executed by the processing device.

[0098] Next, at block 440, processing logic references the MOT to obtain at least one key ID corresponding to an encryption key assigned to the TD. In one embodiment, the key ID enables processing logic to confidentially access memory pages assigned to the TD in response to a processing device executing in the context of the TD, where the memory pages assigned to the TD are encrypted with the encryption key. Finally, at block 450, processing logic references the MOT to obtain guest physical addresses corresponding to host-physical memory pages assigned to the TD. In one embodiment, a match of the guest physical address obtained from the MOT with the accessed guest physical address enables the processing device to access the memory pages assigned to the TD in response to a processing device executing in the context of the TD.

[0099] 5 is a flow diagram of an example method 500 for performing TD termination when using TD to provide isolation in a virtualized system, according to one embodiment. Method 500 may be performed by processing logic, which may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., operations performed by an MCU), firmware, or a combination thereof. In one embodiment, method 500 is performed by processing device 112 of FIG. 1A or FIG. 1B. In another embodiment, method 500 is performed by any of the processing devices described with respect to FIGS. 7A-12. Alternatively, other components of computing system 100 (or software running on processing device 112) may perform some or all of the operations of method 500.

[0100] 5, method 500 begins at block 510 when processing logic identifies a TD end event. In one embodiment, a TDRM manages a TD associated with the TD end event, where processing logic is executing in the context of the TD when the TD end event is identified.

[0101] At block 520, in response to identifying the TD termination event, processing logic stores the TD supervisor execution state and user execution state of the TD in a TD-TCS corresponding to the TD using a first key identifier (ID) corresponding to a first encryption key assigned to the TD. In one embodiment, the execution state is encrypted with the first encryption key, and the TD-TCS is access-controlled for software access from at least one of a TDRM, a VMM, or another TD executed by the processing device.

[0102] Next, processing logic modifies the processing device's Key ID state from the first Key ID to a second Key ID corresponding to at least one of the TDRM or the VMM at block 530. Finally, processing logic loads the TDRM execution and control state and termination information for the TDRM, causing the processing device to operate in the context of the TDRM at block 540.

[0103] 6 is a flow diagram of an example method 600 for performing TD input when using TD to provide isolation in a virtualized system, according to one embodiment. Method 600 may be performed by processing logic, which may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., operations performed by an MCU), firmware, or a combination thereof. In one embodiment, method 600 is performed by processing device 112 of FIG. 1A or FIG. 1B. In another embodiment, method 600 is performed by any of the processing devices described with respect to FIGS. 7A-12. Alternatively, other components of computing system 100 (or software running on processing device 112) may perform some or all of the operations of method 600.

[0104] 6, method 600 begins at block 610 when processing logic identifies a TD input event while executing in the context of a TDRM. In one embodiment, processing logic executes that TDRM that manages the TD.

[0105] At block 620, in response to identifying the TD input event, processing logic loads the TDRM control state of the TDRM from the TDRCS corresponding to the TDRM using a first key ID corresponding to a first encryption key assigned to the TDRM. In one embodiment, the execution state is encrypted with the first encryption key. Furthermore, the TDRCS may be access-controlled against software access from at least one of a TD executed by the processing device or another TD.

[0106] Subsequently, at block 630, processing logic modifies the Key ID state of the processing device from the first Key ID to a second Key ID corresponding to the second encryption key assigned to the TD. Finally, at block 640, processing logic loads the TD user execution state and supervisor execution state of the TD from the TD-TCS and causes the processing device to operate in the context of the TD. In one embodiment, the TD-TCS is access controlled against software access from at least one of a TDRM or another TD executed by the processing device.

[0107] 7A is a block diagram illustrating an in-order pipeline, a register renaming stage, and an out-of-order issue / execution pipeline of a processor for monitoring performance of a processing device that provides isolation in a virtualized system using trust domains, according to at least one embodiment of the present disclosure. FIG. 7B is a block diagram illustrating an in-order architecture core, register renaming logic, and out-of-order issue / execution logic included in a processor, according to at least one embodiment of the present disclosure. The solid lined boxes in FIG. 7A indicate the in-order pipeline, while the dashed lined boxes indicate the register renaming and out-of-order issue / execution pipelines. Similarly, the solid lined boxes in FIG. 7B indicate the in-order architecture logic, while the dashed lined boxes indicate the register renaming logic and out-of-order issue / execution logic.

[0108] 7A , a processor pipeline 700 includes a fetch stage 702, a length decode stage 704, a decode stage 706, an allocation stage 708, a renaming stage 710, a scheduling (also known as dispatch or issue) stage 712, a register read / memory read stage 714, an execution stage 716, a writeback / memory write stage 718, an exception handling stage 722, and a commit stage 724. In some embodiments, the stages are provided in a different order, and different stages may be considered in-order and out-of-order.

[0109] In Figure 7B, arrows indicate connections between two or more units, and the direction of the arrows indicates the direction of data flow between those units. Figure 7B shows a processor core (core) 790 that includes a front-end unit 730 coupled to an execution engine unit 750, both of which are coupled to a memory unit 770.

[0110] Core 790 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, core 790 may be a special-purpose core such as, for example, a network or communications core, a compression engine, a graphics core, etc.

[0111] The front-end unit 730 includes a branch prediction unit 732 coupled to an instruction cache unit 734, which is coupled to an instruction translation lookaside buffer (TLB) 736, which is coupled to an instruction fetch unit 738, which is coupled to a decode unit 740. The decode unit or decoder may decode instructions and generate as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from or otherwise reflect or are derived from the original instruction. The decoder may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, a lookup table, a hardware implementation, a programmable logic array (PLA), a microcode read-only memory (ROM), etc. The instruction cache unit 734 is further coupled to a level 2 (L2) cache unit 776 within the memory unit 770. The decode unit 740 is coupled to a rename / allocator unit 752 within the execution engine unit 750 .

[0112] Execution engine unit 750 includes a rename / allocator unit 752 coupled to a retirement unit 754 and a set of one or more scheduler units 756. Scheduler units 756 represent any number of different schedulers, including reservation stations, central instruction windows, etc. Scheduler units 756 are coupled to physical register file units 758. Each of physical register file units 758 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, etc., status (e.g., an instruction pointer, which is the address of the next instruction to be executed), etc. The physical register files unit 758 overlaps with the retirement unit 754 and illustrates the various ways in which register renaming and out-of-order execution can be implemented (e.g., using a reorder buffer and retirement register file; using a future file, history buffer, and retirement register file; using a register map and pool of registers; etc.).

[0113] In general, architectural registers are visible from outside the processor, or from a programmer's perspective. Registers are not limited to any known particular type of circuit. A variety of different types of registers are suitable so long as they are capable of storing and providing the data described herein. Examples of suitable registers include, but are not limited to, dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated physical registers and dynamically allocated physical registers, etc. Retirement unit 754 and physical register file unit 758 are coupled to execution clusters 760. Execution clusters 760 include a set of one or more execution units 762 and a set of one or more memory access units 764. Execution units 762 may perform various operations (e.g., shift, add, subtract, multiply) and operate on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point).

[0114] Some embodiments may include several execution units dedicated to a particular function or set of functions, while other embodiments may include one execution unit or multiple execution units, all of which execute every function. Scheduler unit 756, Physical Register File Unit 758, and Execution Clusters 760 are sometimes shown as multiple because particular embodiments create separate pipelines for particular types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with their own scheduler unit, Physical Register File Unit, and / or execution cluster; in the case of a separate memory access pipeline, the execution cluster of this pipeline is implemented in particular embodiments with memory access unit 764). It should also be understood that if separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, and the rest in-order.

[0115] The set of memory access units 764 is coupled to a memory unit 770, which includes a data TLB unit 772 coupled to a data cache unit 774 coupled to a level 2 (L2) cache unit 776. In one example embodiment, the memory access units 764 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 772 within the memory unit 770. The L2 cache unit 776 is coupled to one or more other levels of cache and ultimately to main memory.

[0116] By way of example, an exemplary register renaming, out-of-order issue / execution core architecture may implement pipeline 700 of Figure 7A as follows: 1) instruction fetch unit 738 performs fetch stage 702 and length decode stage 704, respectively; 2) decode unit 740 performs decode stage 706; 3) rename / allocator unit 752 performs allocation stage 708 and renaming stage 710; 4) scheduler unit 756 performs scheduling stage 712; 5) physical register file unit 758 and memory unit 770 perform register read / memory read stage 714; execution cluster 760 performs execution stage 716; 6) memory unit 770 and physical register file unit 758 perform writeback / memory write stage 718; 7) various units may be involved in exception handling stage 722; and 8) retirement unit 754 and physical register file unit 758 perform commit stage 724.

[0117] Core 790 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added for newer versions), the MIPS instruction set from MIPS Technologies, Inc. of Sunnyvale, California, or the ARM instruction set (with additional extensions such as NEON) from ARM Holdings, Inc. of Sunnyvale, California).

[0118] It should be understood that a core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of ways, including time-sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that the physical core is simultaneously multithreading), or a combination thereof (e.g., time-sliced ​​fetch and decode followed by simultaneous multithreading such as Intel® Hyper-Threading Technology).

[0119] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in in-order architectures. Also, while the illustrated embodiment of the processor includes separate instruction and data cache units 734 / 774 and a shared L2 cache unit 776, alternative embodiments may have a single internal cache for both instructions and data, such as a level 1 (L1) internal cache or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or processor. Alternatively, all of the caches may be external to the core and / or processor.

[0120] 8 shows a block diagram of a microarchitecture for a processing device 800 including logic circuitry for providing isolation in a virtualized system using trust domains, according to one embodiment. In some embodiments, instructions may be implemented to operate on data elements having sizes such as bytes, words, double words, quad words, etc., and data types such as single- and double-precision integer and floating-point data types. In one embodiment, an in-order front end 801 is the part of processing device 800 that fetches instructions to be executed and prepares them for later use in the processing device pipeline. An embodiment for providing isolation in a virtualized system using trust domains may be implemented in processing device 800.

[0121] Front end 801 may include several units. In one embodiment, instruction prefetcher 826 fetches instructions from memory and provides them to instruction decoder 828, which then decodes or translates them. For example, in one embodiment, the decoder decodes received instructions into one or more operations, called "microinstructions" or "micro-operations" (also called micro-ops or uops), that the machine can execute. In another embodiment, the decoder parses the instruction into an opcode and corresponding data and control fields used by the microarchitecture to perform the operation according to one embodiment. In one embodiment, trace cache 830 receives the decoded uops and assembles them into a program-ordered sequence or traces them in uop queue 834 for execution. When trace cache 830 encounters a compound instruction, microcode ROM 832 provides the uops needed to complete the operation.

[0122] Some instructions are converted to a single micro-op, while others require several micro-ops to complete the entire operation. In one embodiment, if more than four micro-ops are required to complete an instruction, decoder 828 accesses microcode ROM 832 to execute the instruction. For one embodiment, an instruction may be decoded into a small number of micro-ops for processing in instruction decoder 828. In another embodiment, if several micro-ops are required to implement an operation, the instruction may be stored in microcode ROM 832. Trace cache 830 refers to an entry point programmable logic array (PLA) that reads microcode sequences and determines the correct microinstruction pointers to complete one or more instructions in microcode ROM 832 according to one embodiment. After microcode ROM 832 has completed sequencing the micro-ops of an instruction, machine front end 801 resumes fetching micro-ops from trace cache 830.

[0123] The out-of-order execution engine 803 is where instructions are prepared for execution. The out-of-order execution logic has several buffers that smooth and reorder the flow of instructions to optimize performance as they progress through the pipeline and are scheduled for execution. The allocator logic allocates the machine buffers and resources each uop needs to execute. The register renaming logic renames logic registers into entries in the register file. The allocator also allocates entries for each uop in one of two uop queues, one for memory operations and one for non-memory operations, before instruction schedulers such as the memory scheduler, fast scheduler 802, slow / general floating-point scheduler 804, and simple floating-point scheduler 806. Based on the readiness of dependent input register operand sources and the availability of execution resources that a uop needs to complete its operation, uop schedulers 802, 804, 806 determine when a uop is ready to execute. Fast scheduler 802 of one embodiment may schedule every half of the main clock cycle, while other schedulers may schedule only once per clock cycle of the main processing device. The schedulers arbitrate for the dispatch port that schedules the uop for execution.

[0124] Register files 808, 810 are between schedulers 802, 804, 806 and execution units 812, 814, 816, 818, 820, 822, 824 in execution block 811. Separate register files 808, 810 exist for integer and floating-point operations, respectively. In one embodiment, each register file 808, 810 also includes a bypass network that can bypass or forward just-completed results that have not yet been written to the register file to new dependent uops. The integer register file 808 and the floating-point register file 810 can also communicate data with each other. For one embodiment, the integer register file 808 is split into two separate register files, one for the lower 32 bits of data and a second for the upper 32 bits of data. Floating point instructions typically have operands that are 64 to 128 bits wide, so floating point register file 810 in one embodiment has entries that are 128 bits wide.

[0125] Execution block 811 includes execution units 812, 814, 816, 818, 820, 822, and 824, where instructions are actually executed. This section includes register files 808 and 810, which store integer and floating-point data operand values ​​required to execute microinstructions. In one embodiment, processing device 800 is comprised of several execution units: address generation unit (AGU) 812, AGU 814, fast ALU 816, fast ALU 818, slow ALU 820, floating-point ALU 822, and floating-point move unit 824. For one embodiment, floating-point execution blocks 822 and 824 perform floating-point, MMX, SIMD, and SSE, or other operations. In one embodiment, floating-point ALU 822 includes a 64-bit by 64-bit floating-point divider that performs divide, square root, and remainder micro-ops. For embodiments of the present disclosure, instructions involving floating-point values ​​may be handled by floating-point hardware.

[0126] In one embodiment, ALU operations are directed to fast ALU execution units 816, 818. In one embodiment, the fast ALUs 816, 818 can execute fast operations with an effective latency of half a clock cycle. For one embodiment, the majority of complex integer operations are directed to the slow ALU 820 because the slow ALU 820 contains integer execution hardware for long-latency type operations such as multipliers, shifts, flag logic, and branching. Memory load / store operations are performed by AGUs 812, 814. For one embodiment, the integer ALUs 816, 818, 820 are described in the context of performing integer operations on 64-bit data operands. In alternative embodiments, the ALUs 816, 818, 820 may be implemented to support various data bit depths, including 16, 32, 128, 256, etc. Similarly, the floating-point units 822, 824 may be implemented to support a range of operands having various bit widths. For one embodiment, floating point units 822, 824 can operate on 128-bit wide packed data operands with SIMD and multimedia instructions.

[0127] In one embodiment, uop schedulers 802, 804, 806 dispatch dependent operations before the parent load finishes execution. Because uops are speculatively scheduled and executed in processing device 800, processing device 800 also includes logic to handle memory misses. If a data load misses in the data cache, dependent operations that left the scheduler with temporarily incorrect data may be in-flight in the pipeline. A replay mechanism tracks and re-executes instructions that use the incorrect data. Only dependent operations need to be replayed; independent ones are allowed to complete. The scheduler and replay mechanism of one embodiment of the processing device are also designed to catch instruction sequences for text string comparison operations.

[0128] Processing device 800 also includes logic for providing isolation in a virtualized system using trust domains, according to one embodiment. In one embodiment, execution block 811 of processing device 800 may include TDRM 180, MOT 160, TDCS 124, and TDTCS 128, which provide isolation in a virtualized system using trust domains, according to the description herein.

[0129] The term "register" may refer to an on-board processing device storage location used as part of an instruction to identify an operand. In other words, a register may be externally available (from a programmer's perspective) to the processing device. However, registers of embodiments should not be limited in meaning to a particular type of circuit. Rather, registers of embodiments may store and provide data and perform the functions described herein. The registers described herein may be implemented by circuits within the processing device using any number of different techniques, such as dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated and dynamically allocated physical registers, etc. In one embodiment, integer registers store 32-bit integer data. Additionally, the register file of one embodiment includes eight multimedia SIMD registers for packed data.

[0130] For purposes of this discussion, registers are understood to be data registers designed to hold packed data, such as the 64-bit wide MMX™ registers (also referred to in some instances as “mm” registers) in microprocessing devices enabled by Intel Corporation’s MMX technology of Santa Clara, California. These MMX registers are available in both integer and floating-point formats and can operate on packed data elements with SIMD and SSE instructions. Similarly, the 128-bit wide XMM registers associated with SSE2, SSE3, SSE4, or later (commonly referred to as “SSEx”) technology can also be used to hold such packed data operands. In one embodiment, when storing packed data and integer data, registers need not distinguish between the two data types. In one embodiment, integers and floating-points are contained in either the same register file or different register files. Furthermore, in one embodiment, floating-point and integer data can be stored in different registers or the same register.

[0131] Embodiments may be implemented in many different system types. Referring now to FIG. 9 , a block diagram of a multiprocessing device system 900 according to an embodiment is shown. As shown in FIG. 9 , the multiprocessing device system 900 is a point-to-point interconnect system and includes a first processing device 970 and a second processing device 980 coupled via a point-to-point interconnect 950. As shown in FIG. 9 , each of the processing devices 970 and 980 may be a multi-core processing device including first and second processing device cores (not shown), although potentially more cores may be present in the processing devices. Each of the processing devices may include hybrid write mode logic according to an embodiment of the present invention. An embodiment of providing isolation in a virtualized system using trust domains may be implemented in the processing device 970, the processing device 980, or both.

[0132] Although shown with two processing devices 970, 980, it should be understood that the scope of the present disclosure is not so limited. In other embodiments, one or more additional processing devices may be present within a given processing device.

[0133] Processing devices 970 and 980 are shown to include integrated memory controller units 972 and 982, respectively. Processing device 970 also includes point-to-point (PP) interfaces 976 and 978 as part of its bus controller unit. Similarly, a second processing device 980 includes PP interfaces 986 and 988. Processing devices 970, 980 may exchange information over point-to-point (PP) interface 950 using PP interface circuits 978, 988. As shown in FIG. 9 , IMCs 972 and 982 couple the processing devices to their respective memories, namely memory 932 and memory 934, which may be part of main memory locally attached to the respective processing devices.

[0134] Processing devices 970, 980 may each exchange information with chipset 990 via respective PP interfaces 952, 954 using point-to-point interface circuits 976, 994, 986, 998. Chipset 990 may also exchange information with high-performance graphics circuit 938 via high-performance graphics interface 939.

[0135] A shared cache (not shown) may be included within either processing device or outside of both processing devices, but may still be connected to the processing devices via the PP interconnect, so that when the processing devices are placed in a low power mode, local cache information of either or both processing devices may be stored in the shared cache.

[0136] Chipset 990 may be coupled to a first bus 916 via an interface 996. In one embodiment, first bus 916 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or another third generation I / O interconnect bus, although the scope of the present disclosure is not so limited.

[0137] As shown in FIG. 9 , various I / O devices 914 may be coupled to a first bus 916, along with a bus bridge 918 that couples the first bus 916 to a second bus 920. In one embodiment, the second bus 920 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 920, including, for example, a keyboard and / or mouse 922, a communication device 927, and a storage unit 928, such as a disk drive or other mass storage device, that may contain instructions / code and data 930. Additionally, audio I / O 924 may be coupled to the second bus 920. Note that other architectures are possible. For example, instead of the point-to-point architecture of FIG. 9 , a system may implement a multi-drop bus or other such architecture.

[0138] Referring now to Figure 10, a block diagram of a third system 1000 according to an embodiment of the present disclosure is shown. Like elements in Figures 9 and 10 have like reference numerals, and certain aspects of Figure 9 have been omitted in Figure 10 so as not to obscure other aspects of Figure 10.

[0139] FIG. 10 shows that processing devices 970, 980 may include integrated memory and I / O control logic (“CL”) 972, 982, respectively. For at least one embodiment, CL 972, 982 may include an integrated memory controller unit, such as those described herein. Additionally, CL 972, 982 may also include I / O control logic. FIG. 10 shows that memory 932, 934 is coupled to CL 972, 982, and that I / O device 1014 is also coupled to control logic 972, 982. Legacy I / O device 1015 is coupled to chipset 990. Embodiments of providing isolation in a virtualized system using trust domains may be implemented in processing device 970, processing device 980, or both.

[0140] 11 is an exemplary system-on-chip (SoC) that may include one or more of the cores 1102. Other system designs and configurations are also suitable for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processing devices, digital signal processing devices (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices known in the art. In general, a wide variety of systems or electronic devices that may incorporate the processing devices and / or other execution logic disclosed herein are generally suitable.

[0141] 11, a block diagram of an SoC 1100 according to an embodiment of the present disclosure is shown. Also, dashed boxes indicate functionality in a more advanced SoC. In FIG. 11, an interconnect unit 1102 is coupled to an application processing device 1110 including a set of one or more cores 1102A-N and a shared cache unit 1106, a system agent unit 1112, a bus controller unit 1116, an integrated memory controller unit 1114, integrated graphics logic 1108, a set or one or more media processing devices 1120, which may include an image processing device 1124 for providing still and / or video camera functionality, an audio processing device 1126 for providing hardware audio acceleration, and a video processing device 1128 for providing video encoding / decoding acceleration, a static random access memory (SRAM) unit 1130, a direct memory access (DMA) unit 1132, and a display unit 1140 for coupling to one or more external displays. An embodiment of providing isolation in a virtualized system using trust domains may be implemented in SoC 1100.

[0142] Referring now to FIG. 12 , an example SoC design is shown, in accordance with an embodiment of the present disclosure. As an illustrative example, SoC 1200 is included in user equipment (UE). In one embodiment, UE refers to any device used by an end user for communication purposes, such as a mobile phone, smartphone, tablet, ultra-thin notebook, notebook with broadband adapter, or any other similar communication device. The UE may connect to a base station or node, which in nature may correspond to a mobile station (MS) in a GSM network. An embodiment of providing isolation in a virtualized system using trust domains may be implemented in SoC 1200.

[0143] Here, SoC 1220 includes two cores 1206 and 1207. Similar to the discussion above, cores 1206 and 1207 may conform to an instruction set architecture, such as a processing device having an Intel® architecture Core®, an Advanced Micro Devices, Inc. (AMD) processing device, a MIPS-based processing device, an ARM-based processing device design, or customers thereof, and patent owners or adopters thereof. Cores 1206 and 1207 are coupled to a bus interface unit 1209 and a cache control 1208 associated with an L2 cache 1210 and in communication with other parts of system 1200. Interconnect 1211 may include an on-chip interconnect, such as IOSF, AMBA, or other interconnects described above, which may implement one or more aspects of the present disclosure as described.

[0144] Interconnect 1211 provides communication channels to other components, such as subscriber identity module (SIM) 1230 that interfaces to a SIM card, boot ROM 1235 that holds boot code executed by cores 1206 and 1207 to initialize and boot SoC 1200, SDRAM controller 1240 that interfaces with external memory (e.g., DRAM 1260), flash controller 1245 that interfaces with non-volatile memory (e.g., flash 1265), peripheral controller 1250 (e.g., serial peripheral interface) that interfaces with peripherals, video codec 1220 and video interface 1225 that display and receive input (e.g., touch-enabled input), GPU 1215 that performs graphics-related calculations, etc. Any of these interfaces may incorporate aspects of the embodiments described herein.

[0145] Additionally, the system shows communication peripherals such as a Bluetooth module 1270, a 3G modem 1275, a GPS 1280, and a Wi-Fi module 1285. Note that, as noted above, the UE includes a communication radio. As a result, these peripheral communication modules may not all be included. However, some form of external communication radio should be provided in the UE.

[0146] FIG. 13 illustrates a diagrammatic representation of a machine in an exemplary form of computing system 1300, within which a set of instructions may be executed that causes the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine may be connected (e.g., networked) to other machines within a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or client device in a client-server 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 mobile phone, a web appliance, a server, a network router, switch, or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine. Furthermore, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or collectively execute a set (or sets) of instructions that perform any one or more of the methodologies discussed herein. An embodiment of the conversion pages and sections may be implemented in the computing system 1300 .

[0147] The computing system 1300 includes a processing device 1302, a main memory 1304 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or DRAM (RDRAM)), etc.), a static memory 1306 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1318, which communicate with each other via a bus 1330.

[0148] Processing device 1302 represents one or more general-purpose processing devices, such as a microprocessing device, a central processing unit, or the like. More specifically, processing device may be a complex instruction set computing (CISC) microprocessing device, a reduced instruction set computer (RISC) microprocessing device, a very long instruction word (VLIW) microprocessing device, or a processing device implementing other instruction sets or a processing device implementing a combination of instruction sets. Processing device 1302 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processing device (DSP), a network processing device, or the like. In one embodiment, processing device 1302 may include one or more processing device cores. Processing device 1302 is configured to execute processing logic 1326 to perform the operations discussed herein. In one embodiment, processing device 1302 may be part of computing system 100 of FIG. 1A. Alternatively, computing system 1300 may include other components described herein. It should be understood that a core may support multithreading (executing two or more parallel sets of operations or threads) and may do so in a variety of ways, including time-sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that the physical core is simultaneously multithreading), or a combination thereof (e.g., time-sliced ​​fetch and decode followed by simultaneous multithreading such as Intel® Hyper-Threading Technology).

[0149] Computing system 1300 may further include a network interface device 1308 communicatively coupled to a network 1320. Computing system 1300 may also include a video display unit 1310 (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)), an alphanumeric input device 1312 (e.g., a keyboard), a cursor control device 1314 (e.g., a mouse), a signal generation device 1316 (e.g., a speaker), or other peripheral devices. Additionally, computing system 1300 may include a graphics processing unit 1322, a video processing unit 1328, and an audio processing unit 1332. In another example, computing system 1300 may include a chipset (not shown), which refers to a group of integrated circuits or chips designed to function with processing device 1302 and control communications between processing device 1302 and external devices. For example, a chipset may be a set of chips on a motherboard that links the processing device 1302 to very high speed devices such as main memory 1304 and a graphics controller, as well as linking the processing device 1302 to a slower peripheral bus for peripherals such as a USB, PCI, or ISA bus.

[0150] The data storage device 1318 may include a computer-readable storage medium 1324 having stored thereon software 1326 that implements any one or more of the functional methodologies described herein. The software 1326 may also reside, completely or at least partially, in the main memory 1304 as instructions 1326 and / or within the processing device 1302 as processing logic 1326 during execution by the computing system 1300. The main memory 1304 and the processing device 1302 also constitute computer-readable storage media.

[0151] Additionally, computer-readable storage medium 1324 may be used to store instructions 1326 for use with processing device 1302, such as that described with respect to FIG. 1A, and / or a software library containing methods for invoking such applications. While computer-readable storage medium 1324 is shown as a single medium in the exemplary embodiment, the term "computer-readable storage medium" should be interpreted to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more sets of instructions. The term "computer-readable storage medium" should also be interpreted to include any medium that can store, encode, or carry a set of instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present embodiments. Accordingly, the term "computer-readable storage medium" should be interpreted to include, but is not limited to, solid-state memory, and optical and magnetic media.

[0152] The following examples relate to further embodiments. Example 1 is a processing device for providing isolation in a virtualized system using trust domains. Example 1 further includes a processing device having a memory ownership table (MOT) that is access controlled for software access; Processing core and Equipped with. In addition to Example 1, the processing core is Executes a Trust Domain (TD) and a Trust Domain Resource Manager (TDRM) that manages the TD; maintaining a Trust Domain Control Structure (TDCS) for managing global metadata of one or more TDs or other TDs executed by the processing device; maintaining the execution state of the TD in one or more Trust Domain Thread Control Structures (TD-TCS) referenced by the TDCS and access-controlled for software access from at least one of the TDRM, a Virtual Machine Manager (VMM), or another TD; referencing the MOT to obtain at least one key identifier (ID) corresponding to an encryption key assigned to the TD, the key ID enabling the processing device to decrypt memory pages assigned to the TD in response to the processing device executing in the context of the TD, the memory pages assigned to the TD being encrypted with the encryption key; Refer to the MOT to obtain the guest physical address corresponding to the host physical memory page assigned to the TD. Matching the guest physical address obtained from the MOT with the accessed guest physical address enables the processing device to access memory pages assigned to the TD in response to the processing device executing in the context of the TD.

[0153] In Example 2, the subject of Example 1 is the VMM includes a TDRM component that provides memory management for at least one of the TD, other TDs, or one or more virtual machines (VMs) via an Extended Page Table (EPT); In Example 3, the subject matter of any one of Examples 1 and 2 may optionally include: The TD-TCS references the TDCS, and the TDCS maintains a count of one or more TD-TCSs corresponding to the logic processors of the TD, and the TD-TCS stores the supervisor execution state and user execution state of the TD. In Example 4, the subject matter of any one of Examples 1 to 3 may optionally include: The encryption key is generated by the processing device's Multi-Key Total Memory Encryption (MK-TME) engine. may optionally include.

[0154] In Example 5, the subject matter of any one of Examples 1 to 4 is the MK-TME engine generates multiple encryption keys accessed via a key ID assigned to the TD for use in encrypting and decrypting memory pages of the TD and memory pages corresponding to the persistent memory assigned to the TD, and the MOT tracks the multiple key IDs via one key ID associated with each entry in the MOT; In Example 6, the subject matter of any one of Examples 1 to 5 may optionally include: The processing core references the MOT for a host-physical memory page accessed as part of a page walk operation to access a guest-physical memory page mapped by the EPT. In Example 7, the subject matter of any one of Examples 1 to 6 may optionally include: The TD comprises at least one of an operating system (OS) that manages one or more applications, or a VMM that manages one or more virtual machines (VMs), and a TD input operation transitions the operating context of a processing core from at least one of the VMMs to the OS of the TD, or from the TDRM to the VMM of the TD; may optionally include.

[0155] In Example 8, the subject matter of any one of Examples 1 to 7 is The TDRM is not included in the TD's Trusted Computing Base (TCB), In Example 9, the subject matter of any one of Examples 1 to 8 may optionally include: The TDCS comprises a signature structure that captures cryptographic measurements of the TD, the cryptographic measurements are signed by a hardware root of trust for the processing device, and the signature structure is provided to a certification body for validation of the cryptographic measurements; may optionally include.

[0156] In Example 10, the subject matter of any one of Examples 1 to 9 is The processing core further maintains a measurement state of the TD in the TDCS that is access controlled against software access from software comprising at least the TDRM, the VMM, or other TDs executed by the processing device. In Example 11, the subject matter of any one of Examples 1 to 10 may optionally include: The TDRM manages the TD and other TDs. Any optional feature of the above apparatus may also be implemented in relation to the methods or processes described herein.

[0157] Example 12 is a method for providing isolation in a virtualized system using trust domains, comprising: a processing device executing a Trust Domain Resource Manager (TDRM) that manages a Trust Domain (TD) executing on the processing device, identifying a TD termination event; in response to identifying a TD termination event, storing a TD supervisor execution state and a user execution state of the TD in a Trust Domain Thread Control Structure (TD-TCS) corresponding to a logic processor assigned to the TD using a first key identifier (ID) corresponding to a first encryption key assigned to the TD, wherein the execution state is encrypted with the first encryption key and the TD-TCS is access controlled against software access from at least one of a TDRM, a Virtual Machine Manager (VMM), or another TD executed by the processing device; modifying a key ID state of the processing device from a first key ID to a second key ID corresponding to at least one of a TDRM or a VMM; loading TDRM execution and control state and termination information for the TDRM and causing the processing device to operate in the context of the TDRM; Equipped with method.

[0158] In Example 13, the subject of Example 12 is Executing a TD input event in the context of a TDRM; loading TDRM execution control specified by the TDRM from a Trust Domain Resource Manager Control Structure (TD-RCS) corresponding to a logic processor assigned to the TD using a second key identifier (ID) corresponding to a second encryption key assigned to the TDRM, wherein the execution state is encrypted with the second encryption key and the TD-RCS is access controlled using an Extended Page Table (EPT) from at least one of the TD or another VM executed by the processing device; modifying the key ID state of the processing device from the second key ID to the first key ID corresponding to the TD; loading the user execution state and the supervisor execution state from the TD-TCS and causing the processing device to operate in the context of the TD; In Example 14, the subject matter of any one of Examples 12 to 13 may optionally include: The TDCS and TD-TCS are secured and access controlled via a Memory Ownership Table (MOT) of the processing device, the MOT comprising a first entry for the TDCS associating a first key ID with the TD, the MOT enforcing memory confidentiality for memory accesses to memory pages corresponding to the TD using the first key ID; may optionally include

[0159] In Example 15, the subject matter of any one of Examples 12 to 14 is The MOT is accessed via a range register. In Example 16, the subject matter of any one of Examples 12 to 15 may optionally include: The TDRM execution and control state is loaded from a TD-RCS structure that is access-controlled via the EPT and the MOT, the MOT comprising a second entry for the TD-RCS structure that associates a second key ID with the physical memory page that contains the TD-RCS, the MOT utilizing the second key ID to enforce memory confidentiality for memory accesses to the memory page corresponding to the TDRM; In Example 17, the subject matter of any one of Examples 12 to 16 may optionally include: The VMM is a root VMM with a TDRM that manages one or more TDs, and the TDs are non-root VMMs that manage one or more virtual machines (VMs), and a TD exit transitions the operating context of a processing core from the non-root VMM or one or more VMs of the TD to the root VMM and TDRM. may optionally include

[0160] In Example 18, the subject matter of any one of Examples 12 to 17 is The encryption keys are generated by a Multi-Key Total Memory Encryption (MK-TME) engine of the processing device, the MK-TME engine generates multiple encryption keys assigned to the TD via Key IDs for use in encrypting ephemeral or persistent memory pages of the TD, and the MOT tracks multiple encryption Key IDs, one Key ID per host physical page referenced in the MOT. may optionally include

[0161] Example 19 is a system for providing isolation in a virtualized system using trust domains. In Example 19, the system includes: a memory device for storing instructions; a processing device operably coupled to the memory device; In accordance with example 19, the processing device further comprises: instructions to execute a Trust Domain Resource Manager (TDRM) that manages a Trust Domain (TD), the TDRM not being included in a Trusted Computing Base (TCB) of the TD; instructions to maintain a user execution state and a supervisor execution state of the TD in a Trust Domain Thread Control Structure (TD-TCS) that is access-controlled against software accesses from at least one of a TDRM, a Virtual Machine Manager (VMM), or another TD executed by the processing device; instructions for referencing the MOT and obtaining at least one encryption key identifier (ID) corresponding to an encryption key assigned to the TD, the key ID enabling a processing device to decrypt memory pages assigned to the TD in response to the processing device executing in the context of the TD, the memory pages assigned to the TD being encrypted with the encryption key identified via the encryption key ID; instructions for referencing the MOT and obtaining a guest physical address corresponding to a host physical memory page assigned to the TD, wherein matching the guest physical address with an accessed guest physical address enables the processing device to access the memory page assigned to the TD in response to the processing device executing in the context of the TD; Execute.

[0162] In Example 20, the subject of Example 19 is the VMM includes a TDRM component that provides memory management for one or more of the TD, other TDs, or one or more virtual machines (VMs) via an Extended Page Table (EPT); In Example 21, the subject matter of any one of Examples 19-20 may optionally include: The TD-TCS corresponds to the logic processor of the TD, the TD-TCS stores the user execution state and supervisor execution state of the TD on the TD exit operation, and loads the user and supervisor execution state of the TD on the TD enter operation, and the TD-TCS is access-controlled against software access from at least one of the TDRM, the VMM, or other TDs executed by the processing device; In Example 22, the subject matter of any one of Examples 19 to 21 may optionally include: The encryption keys are generated by a Multi-Key Total Memory Encryption (MK-TME) engine of the processing device, the MK-TME engine generates multiple encryption keys assigned to the TD via Key IDs for use in encrypting ephemeral or persistent memory pages of the TD, and the MOT tracks the multiple encryption Key IDs via one Key ID associated with each entry in the MOT. may optionally include

[0163] In Example 23, the subject matter of any one of Examples 19 to 22 is: The VMM comprises a TDRM that manages the TD, the TD comprises an operating system (OS) or a non-root VMM that manages one or more virtual machines (VMs), and a TD enter operation transitions the operating context of a processing core from the TDRM to the non-root VMM of the TD; Any optional feature of the above system may also be implemented in relation to a method or process described herein.

[0164] Example 24 is a non-transitory computer-readable medium for providing isolation in a virtualized system using trust domains. In Example 24, the non-transitory computer-readable medium comprises: When accessed by a processing device, a processing device executing a Trust Domain Resource Manager (TDRM) that manages a Trust Domain (TD), identifying a TD input event while the processing device is executing in the context of the TDRM; In response to identifying a TD input event, loading a TDRM control state for the TDRM from a Trust Domain Resource Manager Control Structure (TDRCS) corresponding to the TDRM using a first key identifier (ID) corresponding to a first encryption key assigned to the TDRM, wherein the TDRM control state is encrypted with the first encryption key and the TDRCS is access controlled against software access from at least one of the TD or another TD executed by the processing device; modifying a Key ID state of the processing device from the first Key ID to a second Key ID corresponding to a second encryption key assigned to the TD; loading a TD user execution state and a supervisor execution state of the TD from a Trust Domain Thread Control Structure (TD-TCS) and causing the processing device to operate in the context of the TD, the TD-TCS being access controlled against software access from at least one of a TDRM or other TDs executed by the processing device; The data includes data that causes an operation to be performed.

[0165] In Example 25, the subject of Example 24 is Executing a TD input event in the context of a TDRM; loading TDRM execution control specified by the TDRM from a Trust Domain Resource Manager Control Structure (TD-RCS) corresponding to a logic processor assigned to the TD using a second key identifier (ID) corresponding to a second encryption key assigned to the TDRM, wherein the execution state is encrypted with the second encryption key and the TD-RCS is access controlled using an Extended Page Table (EPT) from at least one of the TD or another VM executed by the processing device; modifying the key ID state of the processing device from the second key ID to the first key ID corresponding to the TD; loading the user execution state and the supervisor execution state from the TD-TCS and causing the processing device to operate in the context of the TD; may optionally include.

[0166] In Example 26, the subject of Examples 30-31 is The TDCS and TD-TCS are secured and access controlled via a memory ownership table (MOT) of the processing device, the MOT comprising a first entry for the TDCS associating a first key ID with the TD, the MOT enforcing memory confidentiality for memory accesses to memory pages corresponding to the TD using the first key ID; In Example 27, the subject matter of Examples 30-32 may optionally include: The MOT is accessed via a range register. may optionally include

[0167] In Example 28, the subject of Examples 30-33 is The TDRM execution and control state is loaded from a TD-RCS structure that is access-controlled via the EPT and the MOT, the MOT comprising a second entry for the TD-RCS structure that associates a second key ID with the physical memory page that contains the TD-RCS, the MOT utilizing the second key ID to enforce memory confidentiality for memory accesses to the memory page corresponding to the TDRM; may optionally include

[0168] In Example 29, the subject of Examples 30-34 is The VMM is a root VMM with a TDRM that manages one or more TDs, and the TDs are non-root VMMs that manage one or more virtual machines (VMs), and a TD exit transitions the operating context of a processing core from the non-root VMM or one or more VMs of the TD to the root VMM and TDRM. In Example 30, the subject matter of Examples 30-35 may optionally include: The encryption keys are generated by a Multi-Key Total Memory Encryption (MK-TME) engine of the processing device, the MK-TME engine generates multiple encryption keys assigned to the TD via Key IDs for use in encrypting ephemeral or persistent memory pages of the TD, and the MOT tracks multiple encryption Key IDs, one Key ID per host physical page referenced in the MOT. may optionally include

[0169] Example 31 is an apparatus for providing isolation in a virtualized system using trust domains, the apparatus comprising: means for a processing device to execute a Trust Domain Resource Manager (TDRM) that manages a Trust Domain (TD), the TD being executed by the processing device; means for maintaining a Trust Domain Control Structure (TDCS) for managing global metadata of one or more TDs or other TDs executed by the processing device; means for maintaining the execution state of the TD in one or more Trust Domain Thread Control Structures (TD-TCS), which are access-controlled against software access from at least one of a TDRM, a Virtual Machine Manager (VMM), or another TD; means for referencing the MOT and obtaining at least one key identifier (ID) corresponding to an encryption key assigned to the TD, the key ID enabling a processing device to confidentially access memory pages assigned to the TD in response to the processing device executing in the context of the TD, the memory pages assigned to the TD being encrypted with the encryption key; means for referencing the MOT and obtaining a guest physical address corresponding to a host physical memory page allocated to the TD, wherein matching the guest physical address obtained from the MOT with an accessed guest physical address is responsive to the processing device executing in the context of the TD, enabling the processing device to access the memory page allocated to the TD; In Example 32, the subject matter of Example 31 may optionally include an apparatus further configured to include the subject matter of any one of Examples 2 to 11.

[0170] Example 33 is a system for providing isolation in a virtualized system using trust domains, the system comprising: a memory device that stores instructions; and a processing core operably coupled to the memory device. Executing a Trust Domain Resource Manager (TDRM) that manages a Trust Domain (TD) executing on the processing device; Identifying the TD end event, In response to identifying a TD termination event, utilizing a first key identifier (ID) corresponding to a first encryption key assigned to the TD, storing a TD supervisor execution state and a user execution state of the TD in a Trust Domain Thread Control Structure (TD-TCS) corresponding to a logic processor assigned to the TD, wherein the execution state is encrypted with the first encryption key, and the TD-TCS is access-controlled against software access from at least one of a TDRM, a Virtual Machine Manager (VMM), or another TD executed by the processing device. Modifying a key ID state of the processing device from the first key ID to a second key ID corresponding to at least one of the TDRM or the VMM; and In Example 34, the subject matter of Example 33 may optionally include the subject matter of any one of Examples 13 to 18.

[0171] Example 35 is an apparatus for implementing providing isolation in a virtualized system using trust domains, comprising a memory and a processing device coupled to the memory, wherein the processing device executes the method of any one of Examples 12-18. Example 36 is an apparatus for implementing providing isolation in a virtualized system using trust domains, comprising means for executing the method of any one of Examples 12-18. Example 37 is at least one machine-readable medium comprising a plurality of instructions that, when executed on a computing device, cause the computing device to execute the method of any one of Examples 12-18. Specific details in the examples may be used anywhere in one or more embodiments.

[0172] While the present disclosure has been described with respect to a limited number of embodiments, those skilled in the art will appreciate various modifications and variations therefrom, and it is intended that the appended claims cover all such modifications and variations that fall within the true spirit and scope of the present disclosure.

[0173] In the description herein, various specific details are set forth, such as particular types of processing devices and system configurations, particular hardware structures, particular architectural and microarchitectural details, particular register configurations, particular instruction types, particular system components, particular dimensions / heights, particular processing device pipeline stages, and example operations, to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that these specific details need not be used to practice the present disclosure. In other instances, well-known components or methods, such as particular alternative processing device architectures, particular logic circuits / code of described algorithms, particular firmware code, particular interconnect operations, particular logic configurations, particular manufacturing techniques and materials, particular compiler implementations, particular algorithmic expressions in code, particular power-down and gating techniques / logic, and other particular computer system operational details, are not described in detail to avoid unnecessarily obscuring the present disclosure.

[0174] The embodiments are described with reference to providing isolation in a virtualized system using trust domains for specific integrated circuits, such as in a computing platform or microprocessing device. The embodiments may also be applicable to other types of integrated circuits and programmable logic devices. For example, the disclosed embodiments are not limited to desktop computer systems or portable computers, such as Intel® Ultrabook™ computers. They may also be used in other devices, such as handheld devices, tablets, other thin notebooks, system-on-a-chip (SoC) devices, and embedded applications. Some examples of handheld devices include mobile phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications typically include microcontrollers, digital signal processing devices (DSPs), system-on-a-chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system capable of performing the functions and operations taught below. It is noted that the system may be any type of computer or embedded system. The disclosed embodiments may be used in particular in low-end devices such as wearable devices (e.g., watches), electronic implants, sensory and control infrastructure devices, controllers, supervisory and control data acquisition (SCADA) systems, and the like. Additionally, the apparatus, methods, and systems described herein are not limited to physical computing devices, but may also relate to software optimization for energy management and efficiency. As will become readily apparent from the following discussion, the method, apparatus, and system embodiments described herein (whether referring to hardware, firmware, software, or a combination thereof) are essential to the future of "green technology" balanced with performance considerations.

[0175] Although embodiments herein are described with reference to processing devices, other embodiments are applicable to other types of integrated circuits and logic devices. Similar techniques and teachings of embodiments of the present disclosure may be applied to other types of circuits or semiconductor devices that may benefit from higher pipeline throughput and improved performance. The teachings of embodiments of the present disclosure are applicable to any processing device or machine that performs data manipulation. However, the present disclosure is not limited to processing devices or machines that perform operations on 512-bit, 256-bit, 128-bit, 64-bit, 32-bit, or 16-bit data, but may be applied to any processing device or machine in which data manipulation or management is performed. Furthermore, the description herein provides examples, and the accompanying drawings show various examples for illustrative purposes. However, these examples should not be construed in a limiting sense, as they are intended merely to provide examples of embodiments of the present disclosure, as well as to provide a comprehensive list of all possible embodiments of the present disclosure.

[0176] Although the following examples describe instruction processing and distribution in the context of execution units and logic circuits, other embodiments of the present disclosure may be achieved by data or instructions stored on a machine-readable tangible medium that, when executed by a machine, causes the machine to perform functions consistent with at least one embodiment of the present disclosure. In one embodiment, functions associated with embodiments of the present disclosure are embodied in machine-executable instructions. The instructions may be used to cause a general-purpose or special-purpose processing device programmed with the instructions to perform steps of the present disclosure. Embodiments of the present disclosure may be provided as a computer program product or software, which may include a machine or computer-readable medium having instructions stored thereon that can be used to program a computer (or other electronic device) to perform one or more operations according to embodiments of the present disclosure. Alternatively, the operations of embodiments of the present disclosure may be performed by specific hardware components containing fixed-function logic to perform those operations, or by any combination of programmed computer components and fixed-function hardware components.

[0177] The instructions used to program the logic that implements embodiments of the present disclosure may be stored in a system's memory, such as DRAM, cache, flash memory, or other storage. Additionally, these instructions may be distributed over a network or other computer-readable medium. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy diskettes, optical disks, compact disk read-only memories (CD-ROMs), and magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or tangible machine-readable storage used to transmit information over the Internet by electrical, optical, acoustic, or other form of propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.). Thus, a computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0178] A design may progress through various stages from creation through simulation to fabrication. Data representing the design may represent the design in several ways. First, hardware may be represented using a hardware description language or another functional description language, as useful in simulation. Furthermore, a circuit-level model using logic and / or transistor gates may be generated at some stages of the design process. Furthermore, at some stages, most of the design reaches a level of data representing the physical placement of various devices in the hardware model. If conventional semiconductor fabrication techniques are used, the data representing the hardware model may specify the presence or absence of various functions in different mask layers for the masks used to fabricate the integrated circuit. In any representation of the design, the data may be stored in any form on a machine-readable medium. Memory or magnetic or optical storage, such as a disk, may be a machine-readable medium that stores information transmitted via modulated optical or electrical waves, or information otherwise generated to transmit such information. When an electrical carrier wave representing or carrying code or a design is transmitted, a new copy is created to the extent that copying, buffering, or retransmission of the electrical signal is performed. Thus, a communications provider or network provider may at least temporarily store an article implementing techniques in embodiments of the present disclosure, such as information encoded onto a carrier wave, on a tangible, machine-readable medium.

[0179] As used herein, a module refers to any combination of hardware, software, and / or firmware. By way of example, a module includes hardware such as a microcontroller associated with a non-transitory medium storing code adapted to be executed by the microcontroller. Thus, in one embodiment, a module refers to hardware, specifically hardware configured to recognize and / or execute code to be held on the non-transitory medium. Furthermore, in another embodiment, a module refers to a non-transitory medium containing code, specifically code adapted to be executed by a microcontroller to perform predetermined operations. In yet another embodiment, as may be inferred, the term module (in this example) may refer to a combination of a microcontroller and a non-transitory medium. In many cases, the boundaries of modules illustrated separately typically differ and potentially overlap. For example, a first and second module may share hardware, software, firmware, or a combination thereof, but potentially retain some independent hardware, software, or firmware. In one embodiment, the term logic includes hardware such as transistors, registers, or other hardware such as programmable logic devices.

[0180] In one embodiment, the phrase "configured to" refers to arranging, assembling, manufacturing, offering for sale, importing, and / or designing a device, hardware, logic, or element to perform a specified or determined task. In this example, a device or element thereof that is not in operation is still "configured to" perform a specified task if it is designed, coupled, and / or interconnected to perform that specified task. As a purely illustrative example, a logic gate may provide a 0 or a 1 during operation. However, a logic gate that is "configured to" provide an enable signal to a clock does not include all potential logic gates that can provide a 1 or a 0. Instead, the logic gate is coupled in some manner such that a 1 or 0 output enables the clock during operation. Note again that the use of the term "configured to" does not require operation, but instead focuses on the hidden state of the device, hardware, and / or element in which the device, hardware, and / or element is designed to perform a particular task when the device, hardware, and / or element is in operation.

[0181] Furthermore, when the terms "to do," "able to," and / or "operable" are used, it refers to some device, logic, hardware, and / or element being designed in a manner that enables the device, logic, hardware, and / or element to be used in a specified manner, in one embodiment. As noted above, when "to do," "able to," or "operable" are used in one embodiment, it refers to the hidden state of the device, logic, hardware, and / or element, and the device, logic, hardware, and / or element is not operating, but is designed to enable the device to be used in a specified manner.

[0182] As used herein, a value may include any known representation of a number, a state, a logic state, or a binary logic state. Often, the use of logic levels, logic values, or logical values ​​is also referred to as "ones" and "zeros," which simply represent binary logic states. For example, a one refers to a high logic level and a zero refers to a low logic level. In one embodiment, a storage cell, such as a transistor or flash cell, may be capable of holding a single logic value or multiple logic values. However, other representations of values ​​have been used in computer systems. For example, the decimal number 10 may also be represented as the binary value 1010 or the letter A in hexadecimal. Thus, a value includes any representation of information capable of being held in a computer system.

[0183] Furthermore, a state may be represented by a value or portion of a value. By way of example, a first value, such as a logic one, may represent a default or initial state, while a second value, such as a logic zero, may represent a non-default state. Furthermore, in one embodiment, the terms reset and set refer to default and updated values ​​or states, respectively. For example, a default value potentially includes a high logic value, i.e., reset, while an updated value potentially includes a low logic value, i.e., set. Note that any combination of values ​​may be utilized to represent any number of states.

[0184] The above-described method, hardware, software, firmware, or code embodiments may be implemented by instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium and executable by a processing element. Non-transitory machine-accessible / readable media includes any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine, such as a computer or electronic system. For example, non-transitory machine-accessible media include random access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM), ROM, magnetic or optical storage media, flash memory devices, electrical storage devices, optical storage devices, acoustic storage devices, other forms of storage devices that retain information received from transitory (propagated) signals (e.g., carrier waves, infrared signals, digital signals), etc., as distinguished from non-transitory media that can receive information from themselves. Instructions used to program logic to implement embodiments of the present disclosure may be stored in a system's memory, such as DRAM, cache, flash memory, or other storage. Furthermore, these instructions may be distributed over a network or by other computer-readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy diskettes, optical disks, compact disk read-only memories (CD-ROMs), and magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or tangible machine-readable storage used to transmit information over the Internet by electrical, optical, acoustic, or other form of propagated signal (e.g., carrier waves, infrared signals, digital signals, etc.). Thus, a computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0185] References throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0186] In the foregoing description, detailed descriptions are provided with reference to specific exemplary embodiments. However, it will be apparent that various modifications and changes can be made therein without departing from the broader spirit and scope of the present disclosure as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative, rather than a restrictive, sense. Furthermore, use of examples, embodiments, and / or other exemplary language above does not necessarily refer to the same embodiment or identical example, but may refer to different, distinct, and potentially identical, embodiments.

[0187] Some portions of the detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. The blocks described herein may be hardware, software, firmware, or a combination thereof.

[0188] It should be kept in mind, however, that all of these and similar terms relate to the appropriate physical quantities and are merely convenient labels applied to these quantities. As is evident from the above discussion, unless specifically stated otherwise, when discussed throughout this specification using terms such as "define," "receive," "determine," "issue," "link," "associate," "obtain," "authenticate," "block," "execute," "request," "communicate," and the like, it should be understood to refer to actions or processes in a computing system or similar electronic computing device that manipulate and transform data represented as physical (e.g., electronic) quantities in the registers and memory of the computing system into other data similarly represented as physical quantities in the computing system memory or registers, or other such information storage, transmission, or display device.

[0189] As used herein, the words "example" or "exemplary" are meant to serve as an example, instance, or illustration. Any aspect or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the words "example" or "exemplary" is intended to present the concept in a specific manner. As used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or clear from the context, "X includes A or B" is intended to mean any of the natural inclusive permutations. That is, "X includes A or B" is satisfied under any of the above examples when X includes A, or X includes B, or X includes both A and B. Furthermore, the articles "a" and "an," as used in this application and the appended claims, are generally construed to mean "one or more" unless otherwise specified or clear from the context that the singular form is intended. Furthermore, use of the terms "embodiment" or "one embodiment," or "example" or "one example" throughout is not intended to refer to the same embodiment or example unless so described. Also, the terms "first," "second," "third," "fourth," etc., as used herein, are intended as indicators to distinguish between different elements and may not necessarily have an ordinal meaning according to their numerical designations.

Claims

1. a memory encryption engine that uses encryption to protect memory; a processor that executes one or more instructions to enable a Virtual Machine Manager (VMM) to manage a Trust Domain (TD); The processor supports a first instruction for adding a memory page to the TD, execution of the first instruction being to verify that the destination page is allocated to the TD using an address of a TD control structure, an address of a source page, and an address of a destination page, and to copy the source page to the destination page using an encryption key identified in the TD control structure. Device.

2. The TD control structure stores the encryption key identifier for the TD.

10. The apparatus of claim 1.

3. The encryption key identifier of the TD is assigned to the TD during the creation of the TD.

3. The apparatus of claim 2.

4. The encryption key is an ephemeral key associated with the TD.

10. The apparatus of claim 1.

5. The execution of the first instruction is further for updating a data structure to indicate the addition of the memory page to the TD.

10. The apparatus of claim 1.

6. The processor supports a second instruction, execution of which is for initializing the TD control structure of a TD and generating the encryption key.

10. The apparatus of claim 1.

7. The processor supports a third instruction, execution of which is to enter the TD and load a saved state of the TD from a data structure.

10. The apparatus of claim 1.

8. a memory encryption engine that uses encryption to protect memory; a processor that executes one or more instructions to enable a Virtual Machine Manager (VMM) to manage a Trust Domain (TD); The processor: Supporting a first instruction for adding a memory page to the TD, execution of the first instruction using an address of a TD control structure, an address of a source page, and an address of a destination page, the first instruction, when executed, verifying that the destination page is allocated to the TD, copying the source page to the destination page using an encryption key identified in the TD control structure, and causing encryption of the destination page; Device.

9. Further comprising a memory including a state saving area for the TD; The state storage area is protected by the encryption key assigned to the TD, and in the event of termination of the TD, the execution state of the TD is saved in the state storage area of ​​the TD.

9. The apparatus of claim 8.

Images