Secure arbitration mode to construct and operate within trust domain extension

Abstract

The disclosure relates to a secure arbitration mode that constructs and operates within a trust domain extension. A processor includes a range register to store information identifying a reserved range of a memory associated with a secure arbitration mode (SEAM) and a core coupled to the range register. The core includes security logic to unlock the range register on a logical processor of the processor core to initiate the SEAM. The logic processor stores a SEAM module and a manifest associated with the SEAM module in a reserved range via execution of the security logic, wherein the SEAM module is to support execution of one or more trust domains; initializing a SEAM virtual machine control structure (VMCS) within a reserved range of the memory, the SEAM VMCS to control a state transition between a virtual machine monitor (VMM) and a SEAM module; and authenticating the SEAM module with a manifest signature of the manifest.

Description

[0001] Divisional Application Instructions

[0002] This application is a divisional application of the Chinese invention patent application with application date of March 16, 2020, application number 202010179935.6, and titled “Secure arbitration mode for building trust domain extension and operating within trust domain extension”. Technical Field

[0003] The present disclosure relates to computer systems, and more particularly, to a secure arbitration mode of computing devices building and operating within trust domain extensions. Background Art

[0004] Modern processing devices use disk encryption to protect static data. However, the data in the memory is in plain text and vulnerable to attack. An attacker can use a variety of techniques to retrieve data from the memory, including software-based and hardware-based bus scans, memory scans, hardware detection, etc. This data from the memory may include sensitive data, such as privacy-sensitive data, IP-sensitive data, and also includes keys for file encryption or communication. With the current trend of moving data and enterprise workloads to the cloud using virtualization-based hosting services provided by cloud service providers, the exposure of data has further deteriorated. Summary of the invention

[0005] According to an embodiment of the present disclosure, a processor is provided, comprising: a range register for storing information, the information identifying a reserved range of a memory associated with a secure arbitration mode (SEAM) of the processor; and a processor core coupled to the range register, wherein the processor core comprises security logic for unlocking the range register on a logical processor of the processor core for initiating the SEAM; and wherein the logical processor is used, via execution of the security logic, to: store a SEAM module and a manifest associated with the SEAM module in a reserved range of the memory identified by the information stored in the range register, wherein the SEAM module is used to support execution of one or more trust domains; initialize a SEAM virtual machine control structure (VMCS) within the reserved range of the memory, the SEAM VMCS being used to control state transitions between a virtual machine monitor (VMM) and the SEAM module; and authenticate the SEAM module using a manifest signature of the manifest.

[0006] According to an embodiment of the present disclosure, a system is provided, comprising: a memory device, comprising a reserved range for storing a secure arbitration mode (SEAM) module, the SEAM module supporting one or more trust domains (TDs); and a processor coupled to the memory device and comprising a memory controller, wherein the processor is used to execute the SEAM module to perform the following operations: creating a TD virtual machine structure (VMCS) in the memory device, the TD VMCS being associated with a first TD; storing a first pointer to a shared extended page table (EPT) in the TD VMCS, the shared EPT being shared with a virtual machine monitor (VMM) for accessing a shared memory of the memory device; storing a second pointer to a secure EPT in the TD VMCS, wherein the secure EPT is accessible to the SEAM module for accessing a private memory of the memory device; and converting a guest physical address of the first TD into a host physical address of the memory device via a walk of the secure EPT pointed to by the first pointer.

[0007] According to an embodiment of the present disclosure, a method is provided, comprising: booting a secure arbitration mode (SEAM) module from a reserved range of memory within a memory device coupled to the processor into operation by starting an authentication code module through a processor; calling a SEAM call (SEAMCALL) instruction by a virtual machine monitor (VMM) executed by the processor; executing the SEAMCALL instruction by the processor, comprising: saving the VMM state of the processor to a guest area of ​​a SEAM virtual machine control structure (VMCS) stored in a reserved range of the memory; loading and imposing the SEAM module state into the processor from a host state area of ​​the SEAM VMCS; transitioning the processor to a SEAM virtual root operation mode; and executing instructions in the SEAM module starting from an instruction address programmed into the SEAM VMCS; and initializing a trust domain (TD) virtual machine control structure (VMCS) in the memory via the operation of the SEAM module, the TDVMCS supporting the operation of a first TD.

[0008] According to an embodiment of the present disclosure, a device is provided, including a device for executing the above method.

[0009] According to an embodiment of the present disclosure, a device is provided, including a processor configured to execute the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1Ais a block diagram illustrating an example computing system including a processor 112 supporting a secure arbitration mode (SEAM) instruction set architecture (ISA) extension in which a trust domain extension (TDX) operates.

[0011] Figure 1B According to an implementation method, Figure 1A A block diagram of an example processor core of a processor of a computing system.

[0012] Figure 2 is a block diagram illustrating an example computing system implementing virtual machine monitor (VMM) management of a trust control boundary with TDX access control, according to an implementation.

[0013] Figure 3 is a block diagram illustrating components of a TDX implemented with a processor supported by a SEAM module according to one implementation.

[0014] Figure 4 is a flow chart illustrating virtual machine extension (VMX) and SEAM-based TDX transitions according to an implementation.

[0015] Figure 5 is a flow chart of a method of deploying SEAM modules and manifests associated with SEAM modules to enter SEAM according to an implementation.

[0016] Fig. 6A is a block diagram illustrating a reserved range of memory after successful completion of loading a SEAM module and related data by an authentication code module, according to one implementation.

[0017] Figure 6B is a block diagram of a portion of a SEAM configuration for a reserved range of memory for partially storing virtual machine control structures (VMCS), one for each logical processor, according to an implementation.

[0018] Fig. 7A is a block diagram illustrating translation of guest virtual addresses to guest physical addresses and translation of guest physical addresses to host physical addresses, according to an implementation.

[0019] Figure 7B is a block diagram illustrating the use of an extended page table (EPT) to translate a guest physical address into a host physical address according to one implementation.

[0020] Fig. 8A is a block diagram of a Trust Domain (TD) VMCS set up by a SEAM module according to one implementation.

[0021] Figure 8BAn encryption key ID space partitioned into TDX and Multi-Key Total Memory Encryption (MK-TME) key identifiers (IDs) in one implementation is illustrated.

[0022] Figure 8C is a block diagram illustrating how the TD OS may specify whether the TD OS wishes to access shared memory or private memory, and how this is translated using a shared EPT or a secure EPT, respectively, depending on the implementation.

[0023] Fig.9A is a flow chart illustrating deployment of a VMCS to store VMM state and load SEAM state during execution of a SEAMCALL instruction according to one implementation.

[0024] Fig. 9B A flow chart illustrating execution of a SEAMEXIT instruction according to one implementation.

[0025] Fig.10 is a flow chart of a method for using a boot operation from a reserved range of memory to boot a SEAM module to which virtual root mode operation control is transferred when a SEAMCALL instruction is called, according to one implementation.

[0026] Fig.11A is a block diagram illustrating the micro-architecture of a processor or integrated circuit that can implement hardware support for SEAM of computing devices building and operating within a TDX according to implementations of the present disclosure.

[0027] Fig. 11B is a block diagram illustrating an in-order pipeline and a register renaming stage, an out-of-order issue / execution pipeline according to one implementation.

[0028] Fig.12 A block diagram of a microarchitecture of a processing device including logic circuitry to provide secure arbitration mode (SEAM) capability for TDX operations is illustrated according to one implementation.

[0029] Fig.13 is a block diagram of a computer system according to one implementation.

[0030] Fig.14 is a block diagram of a computer system according to another implementation.

[0031] Fig.15 is a block diagram of a system on a chip according to one implementation.

[0032] Fig.16 Another implementation of a block diagram of a computing system is illustrated.

[0033] Fig.17is a block diagram of processing components for executing instructions to implement a secure arbitration mode (SEAM) for TDX operations according to an implementation.

[0034] Fig.18 is a flow chart of an example method to be executed by a processor to execute a SEAMCALL instruction to cause the processor to enter a trust domain (TD) according to an implementation.

[0035] Fig.19 is a flow chart of an example method to be executed by a processor to execute a SAMEXIT instruction to cause the processor to exit from a trust domain (TD) according to an implementation.

[0036] Fig. 20 is a block diagram illustrating an example format of instructions disclosed herein to implement a secure arbitration mode (SEAM) for TDX operations, according to an implementation.

[0037] Fig.21 A block diagram of a computing system is illustrated according to another implementation. DETAILED DESCRIPTION

[0038] Processor architectures that provide isolation in virtualized systems using trust domains (TDs) are described. A current trend in computing is to place data and enterprise workloads in the cloud by leveraging managed services provided 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 requesting better security and isolation solutions for their workloads. In particular, tenants seek solutions to enable the operation of CSP-provided software outside of the tenant's software's trusted computing base (TCB). A system's TCB refers to a set of hardware, firmware, and / or software components that have the ability to affect trust in the overall operation of the system.

[0039] To provide these protections, the disclosed CSP system can remove the virtual machine monitor (VMM) (also known as the hypervisor) and remove other untrusted firmware, software, and devices from the TCB of the virtual machine (VM) managed by the VMM. VM is the workload of each tenant of the CSP. From the perspective of both the CSP and the cloud tenant, both want confidentiality for the VM workload. In order to achieve this confidential VM execution, the memory and runtime processor state of the VM must be kept confidential, integrity protected, and replay protected to prevent data leakage or tampering-based attacks. The CSP system can deploy trust domain extensions (TDX) to meet these security goals via the use of memory encryption and integrity provided by the memory controller, where the memory controller is adapted to include a multi-key total memory encryption (MK-TME) engine. MK-TME technology refers to providing the operating system or VMM with the ability to use different unique encryption keys to encrypt pages of physical memory associated with different workloads (e.g., different tenants, different applications, different devices, etc.). To support TDX, the MK-TME engine can use a specific key that is only used for TDX.

[0040] In some implementations, TDX includes technology that extends virtual machine extensions (VMX) with a new virtual machine guest, called a trust domain (TD). TD runs in a processor mode that protects the confidentiality of the TD's memory contents and its processor state relative to other software, including the managed VMM, unless explicitly shared by the TD itself. In order to coordinate the protections described above, a trust domain resource manager (TDRM) is a VMM software extension that can be deployed to manage and support TDX operations. A VMM operating as a TDRM can start and manage both TDs and "legacy" VMs. Therefore, a VMM operating as a TDRM is a full VMM from the perspective of a legacy VM. In an implementation, as will be explained, a TDRM is restricted only to the TD managed by the TDRM.

[0041] The secure arbitration mode (SEAM) is an instruction set architecture (ISA) extension that implements TDX. This mode of the processor (e.g., SEAM) can host resource arbitration software (e.g., a "SEAM module") that acts as a trust arbitrator between the TDRM and the TD. The SEAM module, which can call a SEAM-specific library to execute SEAM, can manage resource assignments to the TD. The SEAM module can have access to certain privileged instructions, which SEAM can use to build a TDX from which the TD is launched. The SEAM module can also manage the creation, deletion, entry / exit of the TD, and the secure use of resources assigned to the TD (e.g., memory or input / output (I / O) devices). Therefore, by trusting SEAM instead of the VMM (or TDRM), the TD can be guaranteed and protected. For example, the TD can determine whether a portion of a program is valid and is running inside the SEAM, rather than outside the SEAM.

[0042] In one implementation, the processor deploys a SEAM module to enter a SEAM operation, from which a TD can be started to implement secure execution of a tenant workload. In an implementation, the SEAM module calls a SEAM specific library to support resource management of the TD and becomes a trusted arbitrator between the TDRM / VMM and the TD. The processor includes a hardware register to store information identifying a reserved range of memory. The reserved range of the memory stores code and data of the SEAM module, including a SEAM specific library. The processor also includes a processor core coupled to the hardware register.

[0043] The processor may execute a GetSecure (GETSEC) leaf function referred to as a GETSEC[ENTERACCS] instruction to boot the SEAM VMX root mode software (SEAM module) into operation via the launch of an authenticated code module (ACM) referred to herein as a SEAM loader (SEAMLDR). When executing the GETSEC[ENTERACCS] instruction, the processor unlocks the hardware registers on the logical processor from which the ACM is launched, which unlocks a reserved range of memory in which the SEAM module is loaded. The ACM is a processor authentication firmware module that is executed from a protected environment created in a processor core cache. In an implementation, the SEAMLDR stores the SEAM module and the manifest in a reserved range of memory. The manifest that may be located in the header of the SEAMLDR may be generated via a hash algorithm running on specific information associated with the SEAM, such as a combination of the SEAM module, the security version number (SVN) of the SEAM, and the SEAM identifier.

[0044] In an implementation, SEAMLDR creates a SEAM virtual machine control structure (VMCS) in a reserved range of memory so that the state of the VMM can be stored in the SEAM VMCS when the logical processor transitions to SEAM mode. The SEAM VMCS also stores the SEAM state, which can be provided to be loaded into the logical processor for execution in SEAM. Similarly, when exiting SEAM, the logical processor uses the data in the SEAM VMCS to restore the VMM state to the processor core. In an implementation, SEAMLDR is executed in an authentication code (AC) mode and is authenticated by a checklist signature of a checklist. The key for verifying the checklist signature can be embedded in the hardware of the processor core. SEAMLDR also uses the checklist signature to authenticate the SEAM module loaded into the reserved range of memory. SEAMLDR can then record the measurement and identity of the SEAM module in a set of hardware measurement registers. In an implementation, these measurement registers can only be written by SEAMLDR, thereby generating a measured environment to ensure tamper-free execution. Once the SEAM has been deployed to and set within the reserved range of memory, the processor core may further restore the lock to the reserved range of memory by restoring the lock to the hardware registers.

[0045] Once SEAM has been deployed by the loading process just discussed, the SEAM module enters the SEAM VMX root mode from which TDX is operated. The SEAM module can call the SEAM specific library to execute certain privileged instructions for building a TDX from which TD is launched. In this way, the SEAM module can create a TD virtual machine (or just "TD" for simplicity). For each TD created by the SEAM module, the SEAM module can program at least two additional pieces of information in a new field of the TD VMCS created by the SEAM module for the TD. These two additional pieces of information include a TD host key identifier (TD host key identifier, TD-HKID) and a security extended page table (extended page table, EPT) pointer (or SEC_EPTP), which is in addition to the EPT (referred to as shared EPT herein). In an implementation, outside SEAM, the VM entry does not refer to these two pieces of information, which are specially reserved for TDX and TD creation, so the TDRM / VMM is unaware of this additional information.

[0046] When the SEAM module executes the VM entry, the processor uses these two additional information to enter the TD. The processor (e.g., the memory controller of the processor) can also utilize the EPT pointed to by SEC_EPTP to convert the guest physical address of the first trust domain into the host physical address of the memory. The reserved range of the memory and the additional use of the SEAM module will be discussed in more detail with reference to TDX execution. Once the SEAM module is loaded in the reserved range of the memory and is operable as a SEAM, the processor can hand over the virtual root mode operation control to SEAM as a virtual machine exit in response to the execution of the SEAMCALL instruction by the VMM (or TDRM). In other words, the legacy VMX root mode can pass control to the SEAM VMX root mode. In the SEAM VMX root mode, the SEAM module can manage entry and exit TD.

[0047] Through the TD VMCS, the SEAM module can request the processor to cause a TD VM exit when certain instructions are executed or when certain events and conditions occur, which will be discussed in more detail. If an event triggers an unconditional exit, the VM exit transfers control from the SEAM VMX non-root mode to the SEAM VMX root mode. In some cases, such as in response to a system interrupt, the VM exit also triggers a SEAM exit, so control is further transferred to the legacy VMX root mode.

[0048] There are many advantages to using SEAM modules and associated supporting hardware technologies to build and operate TDX from SEAM. For example, CSPs can implement SEAM and differentiate software functions in SEAM, which can be built and evolved at the speed of business needs. In addition, CSPs can generate open source code for review, obtain certification, implement SEAM in the software language of their choice, etc. Using SEAM can also enable new usage models, such as using secure enclaves from TD, using VMMs within TD, which would require several additional ISA instructions without SEAM.

[0049] In addition to operating in SEAM-VMX root mode, the SEAM module that is also loaded in the reserved range of memory can also use the software and hardware protection mechanisms provided by the processor to further strengthen the SEAM module. These mechanisms include, for example, execute / disable (XD), virtual memory (e.g., paging), control flow enforcement technology (CET), protection key (PK), etc. Similarly, the TD managed and called by the SEAM module from the SEAM VMX root mode can also use these hardware protection technologies. The SEAM module ensures that the VMM / TDRM cannot hide / virtualize or prevent the TD from using these technologies in any other way.

[0050] Using SEAM moves further away from hard partitioning of platform resources in favor of flexible sharing of platform resources. Furthermore, the size of resources and partitioning can be based on scaling requirements, such as maximum number of TDs, maximum size of TDs, etc. Furthermore, implementing SEAM-based TDX as software reduces the complexity of the ISA compared to building SEAM functionality into processor microcode (where hardware is also evolving at a slower rate).

[0051] Figure 1A1 is a block diagram illustrating an example computing system 100, which includes a processor 112 that supports a secure arbitration mode (SEAM) instruction set architecture (ISA) extension from which a trust domain extension (TDX) is operated. The computing system 100 may provide software and hardware that support operations in SEAM. SEAM in turn provides functionality to support TDX operations on a virtualized server 110 that supports multiple client devices 102A, 102B, and 102C. The computing system 100 may also include a network interface 104 and shared hardware devices 160A and 160B. The virtualized server 110 may include, but is not limited to, a processor 112 and a memory device 130, such as a memory. The processor 112 may execute a virtual machine monitor (VMM) 140, which may be extended using a TD resource manager (TDRM) 142. The VMM 140 may control one or more virtual machines (VMs) 155. The TDRM 142 may provide resource assignments to the VM 155 and, via the SEAM, to one or more TDs 150A, 150B, and 150C.

[0052] The memory device 130 may store, among other data and information, a guest page table 132, an extended page table (EPT), a VMCS 138A associated with one or more VMs 155, and a TD VMCS associated with one or more TDs 150A, 150B, and 150C. The memory device 130 may also include a reserved range 136 into which a SEAM module 137 may be loaded by a SEAMLDR, as described herein. The SEAM module 137 may include SEAM-specific libraries, manifests, and other code and data associated with SEAM for building and operating a TD. The one or more range registers 116 may include a SEAM range register (SEAMRR) configured with a reserved range 136 of the memory device 130, such as a base address and mask, or a start address and an end address of the reserved range 136, which will be referred to as Fig. 6A The memory device 130 may include a dynamic random access memory (DRAM), a synchronous DRAM (SDRAM), a static memory (e.g., a static random access memory (SRAM)), a flash memory, a data storage device, or other types of memory devices. For simplicity, the memory device 130 may be referred to as a "memory" herein.

[0053] In various implementations, the processor 112 includes one or more processor cores 114, one or more range registers 116, measurement registers 117, cache 118, security version number (SVN) register 121, memory controller 120, write machine specific register (WRMSR) microcode 160, and memory check (MCHECK) firmware 162. The memory controller 120 may also include an MK-TME engine 126 (or other memory encryption engine) and a translation lookaside buffer (TLB) 128, which uses a TD mode bit 129 to distinguish SEAM buffered pages from other pages, as will be explained.

[0054] In an implementation, the MK-TME engine 126 encrypts the data stored in the memory device 130 and decrypts the data retrieved from the memory device 130 using an appropriate encryption key, such as a unique key assigned to the VM or TD that stores data in the forward memory device 130. Internally, the MK-TME engine 126 maintains an internal table that is used to store the key and encryption mode associated with each key ID (e.g., a key designated as KeyID 0 (TME) and not encrypted). The attributes of the table can be programmed using a processor configuration (PCONFIG) instruction. In various implementations, the SEAM module 137 can configure TD-specific encryption keys once it operates in the SEAM VMX root mode, and the MK-TME engine 126 can then use these keys for secure memory operations performed by the TD operated from the SEAM. Therefore, although the MK-TME engine 126 can access TD-specific encryption keys, once created, they are inaccessible to the TDRM 142 / VMM 140 in non-SEAM operations.

[0055] In an implementation, the MK-TME engine 126 may also provide integrity and replay protection. The strength of the integrity protection and whether the memory or processor state can be replay protected may be processor implementation dependent. Additionally, to support TDX, the MK-TME technology may provide specific keys that are only used for TD. Alternatively, the MK-TME technology may provide a mechanism to partition the keys so that a subset of the keys may be reserved for use only by the TDX technology ( Figure 8B ).

[0056] The physical pages of memory 130 may be encrypted with one of the encryption keys managed by the MK-TME engine 126. In one implementation, each encryption key is associated with a key identifier (ID) that may be appended to the physical memory address of the physical page of memory, such as the physical memory of a host server. In the case where the key ID is appended to the physical memory address, a software-requested memory transaction may fail unless the memory transaction request (e.g., a request to read or write to memory) includes both the physical memory address of the page and the correct key ID of the encryption key used to encrypt / decrypt the physical page of memory.

[0057] Each client device can be a remote desktop computer, a tablet device, a smart phone, another server, a thin / thin client, etc. Each client device can execute applications on the virtualization server 110 in one or more of the TD 150A, 150B and 150C and one or more of the VM 155, wherein the VM runs outside the TCB of each TD. Usually, other software other than the SEAM module 137 will also run outside the TCB of the TD. The VMM 140 can execute a virtual machine environment that will utilize the hardware capabilities of the host and execute one or more guest operating systems that support client applications running from the client devices 102A, 102B and 102C, respectively.

[0058] In an implementation, a single TD (e.g., TD 150A) provides a secure execution environment to a single client 102A and supports a single guest OS. In other implementations, a TD supports multiple tenants, each tenant running in a separate virtual machine and assisted by a tenant VMM running inside the TD. The TDRM 142 can then control the use of system resources by the TD, such as the use of memory 130, processor 112, and shared hardware device 160B. The TDRM 142 can act as a host and have control over the processor 112 and other platform hardware. The TDRM 142 can assign (one or more) logical processors to the software in the TD (e.g., TD 150A), but may not access the execution state of the TD on the assigned (one or more) logical processors. Similarly, the TDRM 142 can assign physical memory and I / O resources to the TD, but does not secretly participate in accessing / cheating the memory state of the TD, due to separate encryption keys, and other integrity / replay controls on the memory.

[0059] TD 150A represents a software environment that can support a software stack including a VMM, a guest operating system, and various application software hosted by (one or more) guest OS. TD 150A can operate independently of other TDs and use (one or more) logical processors, memories, and I / Os that are verified by the SEAM module 137 and assigned by the TDRM 142 for SEAM. The software executed in TD 150A can operate with reduced privileges so that the TDRM 142 can maintain control of platform resources. On the other hand, the TDRM 142 cannot access data associated with the TD or affect the confidentiality or integrity of the TD in some other way or replay data into the TD.

[0060] More specifically, TDRM 142 (which includes VMM 140) can manage key IDs associated with encryption keys. TDRM 142 can allocate key IDs, and SEAM module 137 assigns keys to TDs and programs the associated key IDs of these keys into the secure VMCS, which will refer to Figure 6B 140 . The key ID that can be assigned for use by TD is called private key ID. The key that processor hardware implements as private key ID is not configured by VMM 140. In the implementation, TDRM 142 acts as a host for TD and has full control over the core and other platform hardware. TDRM 142 assigns (one or more) logical processors to the software in TD. However, TDRM 142 may not have access to the execution state of TD on the assigned (one or more) logical processors. Similarly, TDRM 142 can assign physical memory and I / O resources to TD, but may not secretly participate in accessing the memory state of TD, which is due to the use of a unique private encryption key configured for each TD by SEAM module 137. The software executed in TD operates with reduced privileges, so that TDRM 142 can maintain control of platform resources. However, as TDRM 142 allocates resources, SEAM module 137 can ensure that the policies associated with TDX execution are implemented, and in this way act as a policy implementer.

[0061] VMM 140 may also assign logical processors, physical memory, encryption key IDs, I / O devices, etc. to TD, but may not access the execution state of TD and / or the data stored in the physical memory assigned to TD. For example, MK-TME engine 126 may encrypt data and generate integrity check values ​​before moving it from one or more range registers 116 or cache 118 to memory 130 when executing the "write" code. Some implementations may also include anti-replay measures as part of generating integrity check values. On the contrary, when data is moved from memory 130 to processor 112 following a read or write command, MK-TME engine 126 may decrypt the data (and verify its integrity using the associated integrity check value). Some implementations may also check the anti-replay measures in the integrity check value.

[0062] Figure 1B According to one implementation method, Figure 1A A block diagram of an example processor core of a processor of a computing system of FIG. Figure 1B In the implementation shown in , each processor core 114 includes a cache 118A (e.g., one or more levels of cache), a page miss handler (PMH) 122, a PMH control register 123, a hardware virtualization support circuit 180, and a hardware register 115. The hardware register 115 may include, for example, a number of model-specific registers 115A (model-specific registers or MSRs) and control registers 115B (e.g., CR1, CR2, CR3, etc.). In an implementation, when cache 118 and range registers 116 are mentioned herein, the reference may be understood to include cache 118A and hardware registers 116 of one or more processor cores 114 in addition or in lieu thereof.

[0063] In various implementations, the cache 118A is loaded with an authenticated code module (ACM) 170 via execution of a GETSEC[INTERACCS] instruction. This ACM 170 may be a SEAMLDR that can direct the loading of the SEAM module 137 and associated data into a reserved range 136 of a memory device 130 (e.g., memory). In other implementations, for example, to perform the SEAMLDR function, the ACM 170 is security logic (e.g., logic embedded in hardware) of the processor core 114, microcode or logic called by the SEAM module 137, or a security controller embedded in the processor 112 that uses security logic. Additionally or alternatively, the SEAM module 137 may call authenticated firmware in a security microcontroller to start the ACM 170.

[0064] In an implementation, the processor core 114 executes instructions to run a number of hardware threads, also referred to as logical processors, including a first logical processor 119A, a second logical processor 119B, and so on, up to an Nth logical processor 119N. In one implementation, the first logical processor 119A is the VMM 140. A number of VMs 155 may be executed and controlled by the VMM 140, as previously described.

[0065] In some implementations, the TDRM 142 may schedule the TD to execute on a logical processor of one of the processor cores 114. In addition to the TDX-based implementation of client virtual machines, the virtualization server 110 may also execute one or more VMs 155 outside the TD for one or more client devices 102A-C. Given that software external to the trusted computing base of the TD (e.g., the TDRM 142 and the VMM 140) may not be able to access the physical memory pages allocated to the TD and / or the execution state of the TD, the access of the VM operating outside the TD to the VMM 140 may not be secure.

[0066] In some implementations, the MK-TME engine 126 prevents such access by encrypting data moving between the processor 112 and the memory 130 with one or more shared encryption keys using the MK-TME engine 126. The term "shared" is intended to refer to a key accessible to the VMM 140, and is different from a private key ID associated with a key assigned to the TD by the SEAM module 137. In an implementation, the PMH 122 imposes restrictions on the use of the private key ID by the VMM / TDRM or VM in the core 114. For example, the PMH 122 may implement that a private key ID may be associated with a read and write request sent to the MK-TME engine 126 only when the logical processor is executed in SEAM mode (root or non-root mode). If such a restricted key ID is used outside the SEAM mode, they cause a fault and the read or write transaction is aborted. The TD cannot specify which private key ID it gets to use as the key ID configured in the VMCS by the SEAM module and the hardware uses the programmed TD-HKID when generating accesses to the TD private memory.

[0067] Processor 112 may also restrict the PCONFIG instruction so that the private key ID is only programmed with the key when operating from SEAM module 137 .

[0068] In addition, in at least some implementations, one or more of the unrestricted keys are shared. The shared key can be accessed by two or more entities, such as TD and VM running outside the TDX environment. The shared key can be used to access one or more shared structures, such as shared hardware devices 160A and 160B, which can be printers, keyboards, mice, monitors, network adapters, routers, etc. In an implementation, the MK-TME engine 126 uses the shared key associated with the shared key ID to encrypt the data stored in the memory. The shared key ID can be used by the system software including the software in the SEAM and by the device to perform direct memory access (direct memory access, DMA) to the memory. Thus, TD can use the shared key ID to communicate with VMM or other VM or equipment. In some cases, TD may wish to protect the confidentiality of the data sent to the device, such as data stored on a hard disk drive. Since the data stored in the shared memory is accessible to all software, the TD software can first encrypt such data using a specific key (e.g., a disk encryption key) before storing the data in the memory using the shared key ID. Thus, when the VMM reads this data, the data is decrypted using the shared key; however, what is decrypted is what was encrypted by the disk encryption key, so that the VMM cannot access the actual data. The TD may also associate an integrity check value with this encrypted data so that subsequent attempts to tamper with the data can be detected. In one implementation, the shared hardware device 160A is connected to the virtualization server 110 via the network interface 104. In another implementation, the shared hardware device is local to the virtualization server 110, such as shown in the shared hardware device 160B.

[0069] The hardware virtualization support circuit 180 can support the virtualized execution of operating systems, applications, and other software by the computing device 100. The hardware virtualization support circuit 180 can include virtual machine extension (VMX) support by providing two execution modes: VMX root mode and VMX non-root mode. VMX root mode allows the execution software to have extensive control over the computing device 100 and its hardware resources. In contrast, the VMM 140 or host operating system (OS) can be executed in VMX root mode. VMX non-root mode restricts access to certain hardware instructions while still implementing the normal ring / privileged system of the processor core 114. One or more guest OS (e.g., VM's) can be executed in VMX non-root mode. These guest OS's can be executed in zero ring, similar to being executed in the absence of virtualization. The hardware virtualization support circuit 180 can also support EPT 134, which can be implemented as a hardware-assisted second-level page address translation. The hardware virtualization support circuit 180 can be implemented as, for example VT-x technology. In the implementation, as will be referred to Figure 4 As discussed, the SEAM VMX root mode is designed to support TDX operations, which are entered using the SEAMCALL and SEAMEXIT instructions for a given TD, as will be discussed.

[0070] The implementation of the present disclosure is not limited to computer systems. Alternative implementations of the present disclosure can be used in other devices, such as handheld devices and embedded applications. Some examples of handheld devices include cellular 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 networks (WANs), or any other system capable of executing one or more instructions according to at least one implementation.

[0071] One implementation may be described in the context of a single processing device desktop or server system, but alternative implementations 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 processor 112 to process data signals. Processor 112 includes, as an illustrative example, a complex instruction set computer (CISC) microprocessor device, a reduced instruction set computing (RISC) microprocessor device, a very long instruction word (VLIW) microprocessor device, a processing device that implements 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 memory devices 130 and / or secondary storage devices 118, which store instructions, data, or any combination of these. 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 basic input / output system (BIOS), a network controller, an audio controller, a serial expansion port, an I / O controller, and the like.

[0072] Figure 22 is a block diagram illustrating an example computing system 200 that implements virtual machine monitoring (VMM) management of a trust control boundary with TDX access control according to an implementation. In an implementation, the TDRM 142 (which includes the VMM 140) executed on the computing system 200 can support legacy VMs 210 (e.g., CSP VM 255A), first tenant VM 255B, and second tenant VM 255C. These legacy VMs can still utilize memory encryption via TME or MK-TME in this model.

[0073] TDRM 142, as verified and implemented by SEAM module 137, may further support two types of TDs, TD1 220 and TD2 230, both of which may be implemented in the case where the TD is a tenant that does not trust the CSP (e.g., virtualization server 110) to enforce confidentiality. Thus, TD1 and TD2 rely on SEAM execution from a reserved range 136 of memory to implement TDX, which provides confidentiality and protection of the TD. TD1 220 is shown as a virtualization mode (e.g., VMX) being utilized by a tenant VMM (non-root) 222 running in TD1 220 to manage tenant VMs 250A, 250B. TD2 230 does not include software that utilizes the virtualization mode, but rather directly runs an enlightened OS 250C in TD2 230. TD1 220 and TD2 230 are tenant TDs with a SEAM managed TCB with TDX access control 204 as described in the implementation of the present disclosure. In one implementation, TD1 220 or TD2 230 may be connected to a reference Figure 1A Any of the described TDs 150A, 150B, or 150C are identical.

[0074] TDRM 142 and SEAM module 137 manage the life cycle of VMs and TDs, including the allocation of resources. However, TDRM 142 is not in the TCB for TD types TD1 220 and TD1 230. Processor 112 does not impose any architectural restrictions on the number or mix of TDs active on the system. However, software and certain hardware limitations in a specific implementation may limit the number of TDs running on the system at the same time due to other constraints.

[0075] Figure 3is a block diagram illustrating components of TDX implemented by a processor supported by a SEAM module 137 according to one implementation. In this implementation, the VMM 140 implements access control between VMs 155A, 155B, and 155C. In order to enter a secure arbitration mode (SEAM) to implement TDX, the SEAM module 137 and other supporting data and information may be stored (e.g., loaded into) a reserved range 136 of memory, which will be discussed in detail. Before the SEAM module 137 is loaded into the reserved range 136 of memory, the processor may set memory encryption for the reserved range using a platform reserved encryption key for encrypting the SEAM reserved memory range. Before the SEAM module 137 is stored in the reserved range 136 of memory, the memory controller 120 may encrypt the SEAM module using the platform reserved encryption key. The memory controller 120 may also utilize the platform reserved encryption key to encrypt and integrity protect data stored in and retrieved from the reserved range of memory 136, such as other data associated with the SEAM, such as page tables, VMCS for each logical processor, etc., which will be referred to in detail below. Figure 6A-6B Let's discuss this further.

[0076] In an implementation, the SEAM module 137 facilitates the implementation of TDX to start and control access to one or more TDs 150A, 150B, and 150C. The SEAM module 137 can be instantiated into many TDs for which the TDRM and SEAM modules have resources to support. The VMM 140 can call the SEAMCALL instruction to request entry into the SEAM. The SEAM module 137 can then call the SEAMCALL instruction to exit the SEAM and transfer root mode operation control back to the VMM 140. The details of the SEAMCALL and SEAMCALL instructions will be referred to in detail. Figure 4 , Figures 9A-9B and Figure 19-20 Let’s discuss this in more detail.

[0077] Figure 4is a flow chart illustrating a virtual machine extension (VMX) and a SEAM-based TDX transition 400 according to an implementation. As previously described, SEAM is an extension to the virtual machine extension architecture that defines a new VMX root mode referred to as the SEAM VMX root mode to distinguish it from the legacy VMX root mode. This SEAM VMX root mode is used to host processor-certified modules (e.g., SEAM module 137) to create a virtual machine (VM) guest referred to as a TD. More specifically, a VM started or restored from the SEAM VMX root mode is a TD, while a VM started or restored from the legacy VMX root mode is a legacy VM. The startup or restoration of a VM or TD is performed using a VM entry, and the exit from a VM or TD is performed using a VM exit. One of the reasons for exiting a TD to a SEAM VMX root mode may be in response to the detection of a system management interrupt (SMI). The division between TDs (see Figure 3 ) can be implemented by SEAM using VMX hardware extensions like EPT.

[0078] In an implementation, the TD runs in the processor SEAM VMX non-root mode to protect the confidentiality of the TD's memory contents and processor state from other software including the managed VMM (other software than the SEAM module 137 executed from the reserved range 136 of memory), unless explicitly shared by the TD itself. The software executed in the SEAM VMX root mode provides arbitration of resources between the TD and the VMM / TDRM. In many implementations, the code size of the software (SEAM library) in the SEAM VMX root mode is significantly smaller than the code size of the untrusted VMM.

[0079] In one implementation, continue to refer to Figure 1A , the SEAM module 137 executes from a reserved range 136 of memory specified by one of the range registers 116, such as a SEAM range register (SEAMRR) configured by the CSP. The reserved range 136 may be configured by the BIOS ( Figure 1AThe BIOS is not shown in the figure) to be programmed and verified by the MCHECK firmware 162. Since the BIOS is not trusted to correctly configure the SEAMRR, in an implementation, the processor 112 provides a processor-authenticated firmware module called MCHECK. In an implementation, the BIOS calls the MCHECK firmware 162 to activate the SEAMRR ranges configured in the SEAMRR range registers. The processor executes the MCHECK firmware 162 from a protected environment created in the cache 118A of (one or more) processor cores 114 so that the MCHECK execution cannot be tampered with by untrusted software and other devices in the platform. Extending the MCHECK function to cover this verification ensures that the range registers 116 have been programmed identically on the processor core 114, and ensures that the value of the reserved range 136 of the memory stored in the range register 116 is not configured to overlap with specific memory reserved for the device or other special memory such as the Trusted Execution Technology (TXT) memory range (because this special memory range is not protected by MK-TME). The MCHECK firmware 162 may also configure the MK-TME engine 126 with a platform-reserved encryption key, which is used to encrypt and integrity- and replay-protect data stored to a reserved range of memory.

[0080] The SEAM module 137 may be software stored in a reserved range 136 programmed in the range register 116. In one implementation, the authentication code module (ACM) 170 ( Figure 1B ) or other security logic is executed to load the SEAM module 137 into the reserved range 136 of memory. Thus, the ACM 170 may act as and be referred to as a SEAM loader ACM (or "SEAMLDR"). The ACM is a processor authentication firmware module that is executed from a protected environment created in the cache 118A of the processor core(s) 114. ACM technology is used as The MCHECK firmware 162 may inform the hardware that the reserved range 136 of memory has been verified and can be used by the ACM 170 and the SEAM module 137. In one implementation, the ACM 170 copies the SEAM module 137 and the manifest into the reserved range 136 of memory. The ACM 170 may then verify the manifest associated with the SEAM module (e.g., message digests of the SEAM module and loadable components, security version numbers (SVNs), and other such information). The functionality of the ACM 170 will refer to Figure 5 Let’s discuss this in more detail.

[0081] In various implementations, the processor transitions from legacy VMX root mode to SEAM VMX root mode in response to a SEAMCALL instruction invoked by an untrusted VMM (or TDRM). This transition is similar to a parallel VM exit to perform companion monitoring in response to a VMCALL from the VMM. The processor transitions from SEAM VMX root mode to legacy VMX root mode in response to a SEAMCALL instruction from the VMM. This transition is similar to a parallel VM entry from a companion monitor to legacy VMX root mode in response to a VMRESUME from a companion monitor. The companion monitor is referred to as an SMM transfer monitor (STM) and is Part of VTx.

[0082] Additional References Figure 4 , keeping execution within legacy VMX root mode separate from execution within SEAM VMX root mode ensures that sensitive data and measurements generated in SEAM operations are not visible and accessible to the VMM or other legacy VMs. The system management mode (SMM) of processor 112 may allow selection, such as opt-in and opt-out options to the VMX architecture and access to hardware registers of processor 112.

[0083] In one implementation, it is assumed that the first logical processor operates in the SEAM VMX non-root mode in the first TD. It is assumed that the first TD detects a system management interrupt (SMI). In this case, the first TD can execute VM to exit to the SEAM VMX root mode. The SEAM VMX root mode can then safely store the secrets and confidential data of the first TD back to the memory device 130 from the hardware registers of the processor 112, for example in an encrypted form utilizing a host key ID (HKID). The actual encryption and storage to the memory can be performed by MK-TME 126. The SEAM module 137 then removes the secrets preserved from the processor register state so that no TD state leaks out. The VMX root mode can then execute the SAMEXIT instruction to exit from the SEAM VMX root mode and transfer the virtual root operation control (for example, VMX root mode control) of the logical processor back to the legacy VMX root mode, for example in VM 155.

[0084] In implementation, SMI is masked when in SEAM VMX root mode, so that even if the pending SMI in SEAM VMX non-root mode causes VM exit, SMI itself also remains pending because it is masked in SEAM VMX root mode. Once in legacy VMX root mode, SMI can be actually processed and cause a transition to system management mode (SMM) or cause an SMI VM exit to SMM. Once in SMM, SMM can read the register contents of the processor. However, SMM cannot see any TD or SEAM module secrets, because such secrets have been removed by the SEAM module before executing SAMEXIT of legacy VMX root mode. Thereby, SMM sees the state of the processor present in legacy VMX root mode.

[0085] Continue to refer Figure 1A and Figure 4 , the reserved range 236 of the memory device 130 for the SEAM library can be allocated by the BIOS and programmed into the range register 116 (e.g., SEAMRR) using MSR. Access to the reserved range 136 of memory when not in SEAM can trigger abort page redirection. When in SEAM VMX root mode, the reserved range 136 provides access with a memory type of write back (WB) when register CR0.CD=0, and provides a memory type of uncacheable (UC) when register CR0.CD=1. Since the memory type of the SEAM reserved range cannot be tampered with by the VMM, the memory type can protect the SEAM module 137 from attacks by the VMM by configuring an unexpected memory type for this range (such as configuring this range as write combining).

[0086] In an implementation, the WRMSR microcode 160 implements that the reserved range 136 of memory is configured as a contiguous range and is not programmed to overlap with a memory range reserved for a specific use or special device, such as a system management range register (SMRR), SMRR2, a processor reserved memory range register (PRMRR), or IA32_APIC_BASE. An attempt to write to the reserved range base address or mask will cause such an overlap, thereby causing a general protection fault (#GP(0) fault). Similarly, an attempt to program PRMRR, SMRR, SMRR2, or IA32_APIC_BAS to overlap with the reserved range 136 area will cause a general protection fault. The protected range is defined by the base address plus the mask added to the base address. The reserved range 136 of memory can also be specified by a start address and an end address.

[0087] In implementation, the BIOS allocates a base address and mask defining a reserved range 136 of memory and sets a lock bit on a range register 116 of each processor core 114 associated with this reserved range 136 of memory. An uncore copy is maintained for the range register 116 and is updated by the WRMSR microcode 160.

[0088] In various implementations, MCHECK firmware 162 is a trusted module that is embedded in a microcode patch and is started by loading the microcode patch to verify the range registers and their configurations protected by the processor. This module is currently used to verify the security guard extension (SGX) memory configuration. MCHECK firmware 162 can be extended to verify SEAM range registers 116. MCHECK firmware verifies the configuration of the reserved range 136 stored in the SEAM range register 116 (e.g., SEAMRR), which is the same as what it does for PRMRR (implementing the same rules for configurations such as overlaps with memory-mapped I / O (memory-mapped I / O, MMIO) and the like. MCHECK firmware 162 can also require that the MK-TME engine 126 on the platform is configured with enabled integrity as a prerequisite for marking SEAMRR as valid. MCHECK firmware can make PRMRR valid as a prerequisite for marking SEAMRR as valid.

[0089] In an implementation, the physical memory range programmed into the SEAM range register 116 (e.g., SEAMRR) will have a key ID of zero ("0"), which can be implemented by the MCHECK firmware 162. The temporary key used for SEAMRR access is different from the key that the VMM addresses for legacy VMs by key ID zero. Instead, access to the reserved range 136 of memory is encrypted and integrity protected using the platform reserved encryption key, which is also used for encryption and integrity protection of the reserved range stored in the PRMRR. This platform reserved encryption key can be programmed into the MK-TME engine 126 by the MCHECK firmware 126. This platform key can be randomly regenerated at each boot. Therefore, even if an attacker wants to capture the encrypted memory of the computing system 100, the attacker will not be able to inject into the range at subsequent power-ups.

[0090] Figure 5 is a flow chart of a method 500 for entering SEAM according to an implementation of deploying SEAM modules and manifests associated with SEAM modules. The method 500 may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one implementation, the method 500 is performed by Figure 1A In another implementation, the method 500 is performed by the processor 112 of the reference FIG. 11A to FIG. 21 Alternatively, other components of computing system 100 (or software executing on processor 112 ) may perform some or all of the operations of method 500 .

[0091] refer to Figure 5 , method 500 may begin by processing logic launching ACM 170 via execution of a get security leaf function referred to as a GETSEC[ENTERACCS] instruction (503). Specifically, ACM 170 (SEAMLDR) of processor 112 may execute method 500 to, for example, boot SEAM VMX root mode software. ACM 170 may be launched using the GETSEC[ENTERACCS] instruction. Method 500 may continue by processing logic unlocking range registers 116 (SEAMRR) on the logical processor in which the ACM is launched to enable the logical processor to write to a reserved range 136 of memory (505). Additionally, the GETSEC[ENTERACCS] instruction may cause processor 112 to enable processor core 114 ( Figure 1B) is set in a specific mode so that the cache 118A does not behave like a cache, but rather behaves like a RAM, such as an authentication code RAM. Because it is set in a cache, this authentication code RAM cannot be snooped by non-core agents. The processor core 114 can then copy the ACM 170 to this RAM set in the cache 118A. Once the ACM 170 is executed in this manner, the method 500 can continue. Other implementations of the ACM 170 are contemplated as previously described.

[0092] Continue to refer Figure 5 , method 500 may continue by processing logic storing the SEAM module 137 and the manifest in a reserved range 136 of memory, wherein the manifest includes a manifest signature (510). This memory copy of the SEAM module 137 may initialize memory integrity for SEAM loadable assets, wherein the SEAM loadable assets are copied using the platform encryption key reserved for SEAM during MCHECK. Method 500 may continue by processing logic creating a page table (e.g., a four-level or five-level page table) for mapping the reserved range of memory (515). This creation of the page table may also include creating a page table pointer to the page table. Method 500 may continue by processing logic creating a configurable number of SEAM software-writable page directory pointer (PDP) structures that the first logical processor uses to map additional memory in which data for the first trust domain is stored (520). Method 500 may continue by processing logic storing the page table and the software-writable PDP structure in the reserved range 136 of memory (525).

[0093] Continue to refer Figure 5, method 500 may continue by processing logic initializing a configuration area within a reserved range 136 of memory using a data array of a SEAM for controlling the VMCS (530). The configuration area may be referred to as a SEAM configuration (SEAMCFG). Method 500 may continue by processing logic initializing a plurality of SEAM VMCSs within the data array, wherein each SEAM VMCS is assigned to a different logical processor of processor core 114 (535). Initialization of each SEAM VMCS may include initialization of various fields of the SEAM VMCS, including but not limited to entry control, exit control, an address from which the SEAM module is executed when the SEAMCALL instruction is executed, a stack pointer, a page table pointer, and other state values ​​for the SEAM module to establish execution of the SEAMCALL instruction. In this way, each SEAM VMCS may be used to establish a SEAM state for use during subsequent execution of the SEAMCALL instruction. More specifically, the SEAM module 137 is capable of storing a VMM state and a SEAM state in the SEAM VMCS to facilitate transitions back and forth between the VMM and the SEAM modules. Reference Figure 4 and Figures 9A-9B Let's discuss these transformations in more detail.

[0094] Method 500 may continue by processing logic (e.g., SEAMLDR) authenticating SEAM module 137 using the manifest signature (540). In various implementations, the manifest includes at least two of the following: (i) a manifest signer public key; (ii) a first digest of the manifest signer public key; (iii) a second digest of the SEAM module and associated loadable components; (iv) a security virtual number (SVN) of the SEAM module; and (v) properties of the SEAM module, for example, whether the SEAM module 137 is a debug module or a production module. The manifest is signed (to generate the manifest signature) using a manifest signer private key, which may be a secret key stored in secure signature facility hardware of processor 112. To authenticate the manifest signature, processing logic may verify the manifest signature using the manifest signer public key recorded in the manifest. If the signature fails to verify, verification fails. Processing logic may also generate a digest of the SEAM module and loadable components and compare the digest to the digest recorded in the manifest. If the digest does not match, authentication fails.

[0095] Method 500 may continue by processing logic recording 545 the SVN, attributes, identity, measurements, and digest of the manifest signer public key of SEAM module 137 into measurement register 117. In an implementation, measurement register 117 is a module specific register (MSR) that may be located in an internal microcode-only memory or other internal secure memory.

[0096] In various implementations, the identity and measurement of the SEAM module are each created by using a cryptographic hash algorithm on specific data to create a specific digest. More specifically, the identity of the SEAM module can be a first digest of the manifest signer's public key. In addition, the measurement of SEAM can be determined by generating a third digest of the following combination: (i) the SEAM module and the associated loadable component; and (ii) the manifest signature. Other subcomponents are contemplated, but this measurement provides a complete and detailed measurement of the SEAM module, including various attributes and SVN of the SEAM module. It is this third digest that can be recorded in the measurement register as the measurement of the SEAM module 137.

[0097] Continue to refer Figure 5 , method 500 may continue by processing logic (e.g., SEAMLDR) verifying the SVN of the manifest signature against a previously recorded SVN value stored in SVN register 121 (550). Thus, SEAMLDR may be implemented such that the SVN associated with SEAM module 137 is a certain minimum value. When a security issue is fixed in a SEAM module, such as via an upgrade of the SEAM module, the SVN is incremented. SEAMLDR may verify the SVN in this manner to ensure that an older (defective) SEAM module is not loaded in place of an upgraded SEAM module.

[0098] The method 500 may continue with the processing logic exiting execution of the ACM 170 software (555). The method 500 may continue with the processing logic restoring the lock on the reserved range 136 of memory (560). For example, execution of GETSEC[EXITAC] may restore the lock and valid bit states to the range register 116 (SEAMRR) to reassert the lock on the reserved range 136 of memory. In another embodiment, the processor may allow the SEAMLDR ACM to explicitly lock and unlock the SEAM range register using the WRMSR microcode 160.

[0099] Fig. 6A 1 is a block diagram illustrating the reserved range 136 of memory after successful completion of loading the SEAM module 137 and related data by the authentication code module (ACM) 170, according to one implementation. According to an implementation, the reserved range 136 includes a SEAM configuration portion (SEAMCFG) 605 (see Figure 6B), page table 610, code area 620, stack area 630 and data area 640. Page table 610 can be used to map virtual memory and can be set by SEAMLDR. SEAM module 137 can then use some of the virtual address ranges in this page table to map additional memory outside the SEAM range, such as the memory of the TD guest. Stack area 630 may include two types of stacks, including: (1) a data stack that stores return addresses and data; and (2) a shadow stack that only stores return addresses, such as an instruction stack. The shadow stack can determine whether any damage has occurred to the return address on the data stack and prevent returning to the damaged address. Using these two types of stacks can facilitate the use of control flow information enforcement techniques by SEAM module 137.

[0100] In various implementations, SEAMCFG 605 is unmapped, while page tables 610 are mostly unmapped, and code area 620 is mapped as read (R) and execute (X). Stack area 630 may include a data stack mapped as read / write (R / W) plus dirty (dirty) and non-executable (NX). Stack area 630 may also include a shadow stack as read (R), dirty, and non-executable (NX). Data area 640 may be mapped as read / write (R / W) and non-executable (NX). Other mappings are contemplated.

[0101] Figure 6B 6 is a block diagram of a SEAM configuration portion (SEAMCFG) 605 of a reserved range of memory 136 storing a virtual machine control structure (VMCS) according to one implementation, wherein one virtual machine control structure is stored for each logical processor. The SEAMCFG portion 605 may include a system information table 645 and a data array 650, which are arranged according to the logical processors (in the processor core 114) of the processor core 114. Figure 6B Indicated as LP0, LP1 to LP N-1 ) stores the SEAM VMCS in data array 650, which is the control VMCS that controls the transition into SEAM. Each logical processor of processor core 114 may, for example, support a different set of workloads for different tenants. Therefore, SEAM may be entered simultaneously on multiple logical processors. System information table 645 may be populated by MCHECK firmware 162 and ACM 170, such as SEAMLDR. System information table 645 may store information such as the number of sockets in the platform of virtualized server 110, the number of DRAM (or other memory) regions that may be used to host TD private pages, and may define additional table entries as the transition into TDX operation proceeds.

[0102] In an implementation, SEAMLDR may configure data array 650 using multiple SEAM VMCSs. In various implementations, SEAMLDR may use system information table 645 to pass certain information to SEAM module 137, such as how much memory is available for mapping virtual pages. In addition, for illustrative purposes, after a SEAMCALL instruction is executed by a first logical processor (e.g., LP0), SEAMLDR sets a first SEAM VMCS in data array 650 for the first logical processor by partially configuring the first SEAM VMCS using information such as an instruction pointer address from which instructions are executed when entering SEAM mode, a data stack pointer, and a shadow stack pointer, etc. In addition, the VMM state of the first logical processor is saved to the first SEAM VMCS in preparation for exiting the legacy VMX root mode. In another implementation, the SEAM VMCS of the first logical processor is located at the index of the initial x2 advanced programmable interrupt controller (APIC) ID (non-software modifiable) of the first logical processor.

[0103] Fig. 7A 7 is a block diagram 700 illustrating the translation of a guest virtual address (GVA) to a guest physical address (GPA) and the translation of a GPA to a host physical address (HPA) according to one implementation. In one implementation, in order to emulate instructions on behalf of a VM, the VMM 140 may need to translate a linear address (e.g., GVA) used by the instruction into a physical memory address so that the VMM can access the data at the physical address. As previously described, the VMM may also gain access to additional key IDs without the protection measures implemented as discussed in the present disclosure.

[0104] To perform this translation, the VMM may need to first determine paging and segmentation, including examining the segmentation state of virtual machine (VM) 155. The VMM may also determine the paging mode of VM 155 at instruction invocation, including examining the page tables set up by the VM and examining control registers 134 and MSRs programmed by VM 155. After discovering the paging and segmentation mode, the VMM may generate a GVA for the logical address and detect any segmentation faults.

[0105] Assuming that no segmentation fault is detected, the VMM may translate the GVA to GPA and the GPA to HPA, including performing a page table walk in software. To perform these translations in software, the VMM may load several paging structure entries and EPT structure entries originally set by VM 155 into general registers or memory. Once these paging and EPT structure entries are loaded, PMH 122 may perform the translation by modeling the translation circuitry as follows.

[0106] More specifically, refer to Fig. 7A , when the VMM executes a VMRESUME using a VMCS, the PMH 122 may be programmed with a guest page table pointer and an EPT pointer from the VMCS. The PMH 122 may load a plurality of guest page table entries 132A from a guest page table 132 and a plurality of extended page table entries from an EPT 134, which are established by the VM. The PMH 122 may then perform the translation by walking (e.g., sequentially searching) through the guest page table entries 132A to generate a GPA from a GVA. The PMH may then use the GPA to walk (e.g., sequentially search) the EPT 134 to generate an HPA associated with the GPA. The use of the EPT 134 is a feature that may be used to support virtualization of physical memory. When the EPT is in use, certain addresses that are typically considered physical addresses (and used to access memory) are instead considered guest physical addresses. The guest physical addresses are translated by traversing a set of EPT paging structures to generate physical addresses for accessing physical memory.

[0107] Figure 7B 7 is a block diagram 750 illustrating the use of an extended page table (EPT) to convert a guest physical address (GPA) to a host physical address (HPA), according to one implementation. For example, according to one implementation, a VMM 140 or PMH 122 may walk an extended page table entry 134A to convert a GPA to an HPA. For example, a guest physical address (GPA) may be decomposed into a series of offsets, each to an index within a hierarchical table structure of EPT entries 134A. In this example, the EPT from which the EPT entries are derived includes a four-level hierarchy of tables of entries, including a page mapping level 4 table, a page directory pointer table, a page directory entry table, and a page table entry table. (In other embodiments, a different number of levels of hierarchy may exist within the EPT, and thus, the disclosed embodiments are not limited by a particular implementation of the EPT.) The result of each index at one level of the EPT hierarchy may be added to the offset to the next table to locate the next result of the next level of the table in the EPT hierarchy. The results of the fourth (page table entry) table can be combined with the page offset to locate a 4Kb page in physical memory (for example), which is the host physical address.

[0108] Fig. 8A 1 is a block diagram of a trust domain (TD) VMCS 138B set by the SEAM module 137 according to one implementation. In various implementations, after the SEAM module 137 is loaded and operable to support TDX, the SEAM module 137 sets the VMCS 138B for the created TD, one of which is illustrated for illustration. In an implementation, the TD VMCS 138B of the TD includes a shared EPT pointer 802, a secure EPT pointer (SEC_EPTP) 804, and a TD host key ID (HKID) 806. The shared EPT pointer 802 is used to point to a shared EPT 803, which is used to map shared memory and is constructed and managed by the VMM 140. The VMM 140 specifies the pointer as part of the TD construction. The secure EPT pointer 804 is constructed and managed by the SEAM module 137, and a pointer to the secure EPT 805 is programmed into the secure EPT pointer 804. The SEAM module 137 may configure the secure EPT pointer 804 and the TD-HKID 806 in the TD VMCS 138B when constructing a TD VMCS that may support multiple VM entries and subsequent VM exits.

[0109] In an implementation, secure EPT 803 maps TD private memory, such as TD's code and data, and is encrypted using a private memory encryption key corresponding to TD-HKID 806. These private keys are keys that can only be used by SEAM module 137 and TD 150A, 150B, 150C, etc. PMH 122 can be implemented as a private key ID that is not used for memory access (load / store / code acquisition) when not in SEAM. SEAM module 137 builds and manages secure EPT 805 for TD and also assigns private TD-HKID 806 to the TD virtual machine. By building secure EPT 805 and making the associated encryption key private, SEAM module 137 ensures protection against tampering (e.g., tampering by VMM or other non-SEAM agents) with memory mapping performed by secure EPT 805. The SEAM module 137 specifies these to the hardware as part of the VM entry into the TD using the following two new fields in the TD VMCS: (1) Secure EPT Pointer 804; and (2) TD-HKID 806.

[0110] In one implementation, the secure EPT pointer 804 is a new 64-bit control field that specifies the secure EPT 805. In an implementation, the first bit (e.g., bit 7) of the secure EPT pointer 804 is defined as an "S position" bit, where "S" means "shared" between the SEAM module 137 and the VMM 140. When this S position bit is zero ("0"), the indicator bit (e.g., "S" bit) is in the first position (e.g., position 47) of the GPA, and when the S position bit is one ("1"), the indicator bit is located in the second position (e.g., position 51) of the GPA. In another implementation, the S bit position is specified by another field of the TDVMCS 138B. The TD OS may set the S bit position in the GPA to indicate to the PMH 122 the position of the indicator (or "S") bit within the GPA, where the indicator bit indicates whether the TD OS is performing private or shared memory access. When the S bit is set to indicate that the TD OS wishes to perform shared memory access, the PMH will use the shared EPT 803 to convert the GPA into a physical address, otherwise the secure EPT 805 will be used to convert the GPA into a physical address.

[0111] In implementation, TD-HKID 806 is a new 32-bit control field for specifying a temporary key ID of a TD, which corresponds to a private encryption key of a TD. An array of HKIDs assigned by multiple TDs may be specified to allow TD to use more than one key ID, such as to allow different private memory areas of a given TD to be encrypted and integrity protected using one of the HKIDs assigned by TD. TD-HKID may be carried to MK-TME126 in a read or write transaction together with the physical address, and may be used by MK-TME 126 to select the corresponding key for performing memory encryption. Security EPT 804 may be, for example, a 4-level or 5-level EPT (same as that configured by VMM for a shared EPT). Processor 112 may be implemented as the same number of levels in two EPTs.

[0112] Figure 8B The diagram illustrates the partitioning (800) of the encryption key ID space into TDX and MK-TME key IDs using a boundary separating private key IDs from shared key IDs in one implementation. At boot time, the BIOS may store a bit range of the key ID encoding in the MSR. The bit range may support K key IDs to identify K encryption keys. The processor 112 may also identify the partitioning (800) of the key ID space in the MSR. In one implementation, the K key IDs may be partitioned into K MK A shared key ID and K TD private key ID, such that K MK +K TD= K. A key ID of zero ("0") specifies the TME key ID used as the platform reserved key. The shared key ID can be Figure 1A 140 (e.g., for assignment to shared devices). The MK-TME key ID may also be assigned to the operating system (or TDRM 142) in a non-virtualized implementation. The PCONFIG instruction called to program the encryption key to the key ID may implement the TDX reserved key ID (e.g., K TD 140) are used to program keys for private key IDs, which are more specifically referred to herein as TD host key IDs (TD-HKIDs). For example, if VMM 140 or other privileged software outside of SEAM uses a PCONFIG instruction to attempt to program keys for any private key ID, the PCONFIG instruction will reject and cause a fault. The PCONFIG instruction can be used within SEAM, for example, by SEAM module 137 to program keys for private key IDs.

[0113] The private key ID may only be used by the TD and SEAM modules 137 and may be partitioned and configuration locked by the MCHECK firmware 162. Access using the private key ID may be performed using WB semantics (CR0.CD is zero) or UC (CR0.CD is 1). Thus, the processor core 114 may also execute the memory check firmware to: partition the key identifier (ID) space according to the partition set by the basic input / output system (BIOS) firmware at boot time between at least a first range of values ​​identifying the private key ID and a second range of values ​​identifying the shared key ID; and configure lock the key ID space by setting a lock on a configuration register for configuring the partitioning of the key ID space.

[0114] Figure 8C 850 is a block diagram illustrating how the TD OS may specify whether the TD OS wishes to access shared or private memory, and how this is translated using a shared EPT or a secure EPT, respectively, depending on the implementation. A first TD 150 is depicted, which may access a guest physical address (GPA) and send the GPA to the PMH 122. In an implementation, both the TD-HKID 806 and the EPT pointer (both the shared EPT pointer 802 and the secure EPT pointer 804) are configured from the VMCS 138B into the PMH control registers 123 as part of the VMRESUME microcode resuming execution of the start TD. The PMH 122 may access the TD-HKID 806 and the EPT pointer in these PMH control registers 123.

[0115] In an implementation, PMH 122 may also determine whether an indicator bit (e.g., a shared or "S" bit) within the GPA is set. If the shared bit is set, PMH 122 may retrieve shared EPT pointer 802 from PMH control register 123, link to shared EPT 803, and walk the extended page table entry to determine the physical address (PA). PMH 122 may then append a shared HKID to the PA. In an implementation, the shared HKID is received from a field in VMCS or a field in shared EPT. PMH 122 may then cache this conversion in TLB 128 along with the shared HKID. PMH 122 may then send the read (or write) transaction performed by the instruction called by TD OS to memory controller 120 along with the PA and shared HKID. Subsequent accesses to the page may hit TLB 128 and thereby use the cached HKID and PA.

[0116] In another implementation, if the indicator bit in the GPA is not set, the PMH 122 may retrieve the secure EPT pointer 804 from the PMH control register 123, link to the secure EPT 805, and walk the extended page table entries of the secure EPT 805 to determine the PA. The PMH 122 may then send the PA and the TD-HKID 870 (which is determined to be the private HKID associated with the first TD 150A) to the first TD. The first TD may then retrieve the private code and / or data 814A and / or 814B from the PA and decrypt the private code and / or data using the private HKID. The PMH 122 may then cache this conversion in the TLB 128 along with the TD-HKID. The PMH 122 may then send the read (or write) transaction performed by the instruction called by the TD OS to the memory controller 120 along with the PA and the TD-HKID. Subsequent accesses to the page may hit the TLB 128 and thereby use the cached TD-HKID and PA.

[0117] Fig.9A900 is a flowchart illustrating the deployment of VMCS to store VMM state and load SEAM state during the execution of SEAMCALL instruction according to an implementation. In an implementation, VMM 140 is provided with SEAMCALL instruction to transform the logical processor into a secure arbitration mode (SEAM) and transfer control to SEAM module 137. SEAM functions that can be called by VMM 140 via SEAMCALL instruction include the creation of TD, adding pages to TD and entering TD. For example, SEAM module 137 can be understood as a VMX root mode library, so SEAMCALL can provide entry to SEAM VMX root operating mode. The call generated by SEAMCALL instruction is reported to SEAM module 137 as VM exit. SEAMCALL instruction can register the exit reason as SEAMCALL.

[0118] More specifically, refer to Fig.9A , the VMM 140 may reference a working VMCS pointer associated with the VM guest (labeled "working" to distinguish from the SEAM's "controlling" VMCS). In an implementation, the VMM 140, upon invoking the SEAMCALL instruction, may cause the processor core 114 to store the current working VMCS pointer into the SEAM controlling VMCS 936, illustrated by a first arrow 902 pointing from the working VMCS pointer to the VMCS field. The SEAMCALL then causes the VMM state to be saved into the guest state area of ​​the SEAM controlling VMCS 936, illustrated by a second arrow 904 from the VMM 140 to the VMM state field. The SEAMCALL may then load / impose state from the VMCS host state area to set that state for the SEAM module 137, illustrated by a third arrow 906 pointing from the host state area of ​​the SEAM controlling VMCS 936 to the SEAM module 137. Finally, the pointers are adjusted so that at the end of the SEAMCALL instruction, the working VMCS is the SEAM VMCS itself, e.g., the controlling VMCS becomes the working VMCS. Additionally, the control VMCS is pointed to the VMXON VMCS, such as the default VMCS established in VMXON.

[0119] In addition, during the execution of the SEAMCALL instruction, system management interrupts (SMI) and non-maskable interrupts (NMI) and other events may also be disabled. The controlling VMCS exit reason may be recorded as SEAMCALL, the controlling VMCS pointer may be linked to the working VMCS, and the working VMCS may be replaced by the controlling VMCS. In some implementations, while in SEAM VMX root mode, attempts to execute VMCALL, VMXOFF, GETSEC, or other instructions that may cause an illegal transition out of SEAM or compromise SEAM will cause general protection.

[0120] Fig. 9B Flowchart 950 illustrates the execution of a SEAMEXIT instruction according to one implementation. The SEAMEXIT instruction may be called by the SEAM module 137, which allows SEAM VMX root mode software to exit from SEAM VMX root mode and continue execution of the untrusted VMM 140 in legacy VMX root operation. Thus, the SEAMEXIT instruction execution reference Fig.9A Execution of VMM 140 then continues from the point at which the SEAMCALL instruction caused a previous successful entry into SEAM VMX root mode (e.g., Fig.9A Activation of the SEAM module 137 described in ).

[0121] For example, in one implementation, the state of the VMM is loaded from the guest state area of ​​the working VMCS based on the entry control (in the legacy VMX root mode). Note that for the SEAMCALL / SEAMEXIT instructions, the VMM 140 is the "guest" and the SEAM module 137 is the "host". In addition, the VMM 140 can restore event prohibition (NMI, SMI) from the guest interruptibility status field of the SEAM control VMCS 936. The pointers are adjusted again so that at the end of the SEAMCALL / SEAMEXIT instruction, the working VMCS becomes the VMCS for the VM guest and the control VMCS is pointed to the VMXON VMCS, such as the default VMCS established on VMXON. The secure arbitration mode (SEAM) can then be successfully exited.

[0122] Fig.10is a flow chart of a method 1000 for booting a SEAM module to which virtual root mode operation control is transferred when a SEAMCALL instruction is called, according to one implementation. The method 1000 may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software, firmware, or a combination thereof. In one implementation, the method 1000 is performed by Figure 1A In another implementation, the method 1000 is performed by the processor 112 of the reference FIG. 11A to FIG. 21 Alternatively, other components of computing system 100 (or software executing on processor 112 ) may perform some or all of the operations of method 1000 .

[0123] refer to Fig.10 , method 1000 may begin with processing logic directing a secure arbitration mode (SEAM) module into operation from a reserved range of memory within a memory device coupled to a processor by starting an authentication code module (1010). Method 1000 may continue with processing logic invoking a SEAM call (SEAMCALL) instruction through a VMM of the processor (1020). Method 1000 may continue with processing logic executing the SEAMCALL instruction according to the following steps (1030). For example, execution may begin with processing logic saving a VMM state of the processor to a guest region of a SEAM virtual machine control structure (VMCS) stored in a reserved range of memory (1034), loading and forcing a SEAM module state into the processor from a host state region of the SEAM VMCS (1036), causing the processor to transition to a SEAM virtual root operating mode (1042), and executing instructions in the SEAM module starting from an instruction address programmed into the SEAM VMCS (1046). The method 1000 may continue by processing logic initializing, via operation of the SEAM module, a Trust Domain (TD) Virtual Machine Control Structure (VMCS) in memory, the TD VMCS supporting operation of the first TD ( 1050 ).

[0124] Additional References Fig.10 , method 1000 may continue as follows: processing logic programs a first pointer to a shared extended page table (EPT) into the TD VMCS, the shared EPT being shared with the VMM and used to access the shared memory of the memory device; a second pointer to a secure EPT, wherein the secure EPT is accessible to the SEAM module and is used to access the private memory of the memory device; and a trusted domain host key identifier (TD-HKID) to correspond to a private memory encryption key, wherein the private memory encryption key programmed for the TD-HKID is unknown to the VMM (1060).

[0125] In operation, when the processor 112 operates in SEAM, the SEAM module 137 may execute privileged instructions and operations that are inaccessible to the processor 112 when operating outside of SEAM. For example, the processor 112 may allow the SEAM module 137 to call second instructions that are inaccessible to the processor in operations outside of SEAM. These second instructions may include several operations, such as programming a private memory encryption key to correspond to a processor configuration (PCONFIG) operation of the TD-HKID of the TD; disabling the system management interrupt (SMI) and non-maskable interrupt (NMI) of the processor in response to the execution of the SEAMCALL instruction; programming the TD-HKID of the TD into the TD VMCS; and programming the secure EPT pointer of the TD into the TD VMCS, as well as many other operations disclosed herein that may be performed by the SEAM module 137.

[0126] In various implementations, the SEAM module 170 calls a VMRESUME or VMLAUNCH instruction in the SEAM VMX root mode to enter TD. More specifically, the VMRESUME instruction may cause the SEAM module state of the processor to be stored in the host state area of ​​the TD VMCS, the TD state of the TD to be loaded into the processor from the guest area of ​​the TD VMCS, and the transition to the SEAM VMX non-root mode to continue the execution of the instructions in the TD. When exiting from the VM of the TD later, the processor 112 may save the TD state of the processor to the TD VMCS guest state area that was used to continue the TD. After the TD state is saved in the VMCS, the processor 112 may load the SEAM module state back into the processor from the TD VMCS host state area. The saving of the TD state and the loading of the SEAM module state may be controlled by the exit control field in the TD VMCS. After loading the processor state from the host state area of ​​the TD VMCS, the processor transitions to the SEAM VMX root mode and begins to execute instructions in the SEAM module.

[0127] Additional References Figure 1A and 1B, the VMRESUME and VMLAUNCH instructions in SEAM VMX root mode may perform the following additional actions. If the Enable EPT VM Execution Control bit of the TD VMCS is zero ("0"), these instructions may cause a VM entry failure due to an invalid control field. However, if the Enable EPT VM Execution Control bit is one ("1"), the Secure EPT Pointer VM Execution Control field must meet the following predetermined criteria: (a) the EPT memory type (bits 2:0) will be a value supported by the processor 112; (b) bits 5:3 (one less than the EPT page walk length) are valid; (c) if the processor does not support EPT A / D, bit 6 (the enable bit for the EPT's accessed and dirty flags) will be zero ("0"); and (d) reserved bits 11:8 and 63:N (where N is the processor's physical address width) will be zero ("0").

[0128] If these checks of the first group succeed, the secure EPT pointer and TD-HKID value are programmed into the PMH control register. VM entry then unbans the system management interrupt (SMI). More specifically, if the logical processor is in SEAM VMX root mode and an SMI occurs, the SMI remains pending in hardware until it is unbanned after the above checks have been passed. Thus, the SMI is "detained" until the SEAM VMX root mode can be exited to the legacy VMX root mode using the SAMEXIT instruction. In addition, the prohibition on the non-maskable interrupt (NMI) can be restored normally from the guest interruptibility state. Similarly, here the NMI will be "detained" until leaving from the SEAM VMX root mode.

[0129] In a related implementation, the VMRESUME and VMLAUNCH instructions in the SEAM VMX root mode may perform the following additional actions. The VMRESUME and VMLAUNCH instructions may verify that the TD-HKID stored in the control VMCS is non-zero and is a private key ID. In addition, the SEAM module 137 may modify the calculation of the address space identifier (ASID) used to mark the address of the TD in the translation lookaside buffer (TLB) 128 of the processor 112 as follows. First, the pointer (SEC_EPTP) of the secure EPT is used to replace the shared EPT pointer to locate the extended page table for address translation. Second, the trust domain (TD) bit of the ASID may be set (e.g., set to "1") to indicate the association with the SEAM mode, wherein the ASID is not recognizable to the VMM. This is because the TLB entry is marked with this ASID, and the ASID created in the SEAM mode will be unavailable outside the SEAM mode because the TD bit of the ASID is never set (e.g., "0") outside the SEAM. In one implementation, the TD bit is bit 16 of the virtual processor ID (VPID) of the ASID, although other bits may also be used as the TD bit.

[0130] These modifications to the ASID affect the virtual address to physical address translation performed by the SEAM module (or by the TD in operations performed from the SEAM library) to, for example, prevent conflicts between addresses created by the SEAM module 137 (and the TD) and addresses created by the VMM, legacy VMs, and other software entities executing outside of SEAM mode. This prevention recognizes that SEAM does not trust the VMM to assign unique ASIDs to legacy VMs. The TD mode bits can create a new address space ID that is unique to SEAM. In this way, addresses referenced by the PMH 122 created by the SEAM module 137 (or TD) are marked with an ASID that cannot be used by the VMM 140. This distinction of address spaces is particularly useful due to the separation of the secure EPT from the shared EPT, each of which can use different information to mark TLB entries for different virtual to physical address mappings.

[0131] In a related implementation, the VMRESUME and VMLAUNCH instructions in the SEAM VMX root mode may perform the following additional actions. That is, the TD mode bit may be annotated as being set, such as being annotated as one ("1"), and thereby associated with TD. The TD mode bit is used to make decisions in the processor depending on whether it is a TD guest or a VM guest. For example, this decision about the processing of SMI is based on this TD mode bit. In addition, the SMI processing when in the TD guest mode has been discussed previously. When the processor 112 observes an SMI in the TD guest mode, the processing logic may cause a VM exit to the SEAM library, where the exit reason is set to "SMI VM exit". The observed SMI remains pending after the VM exit. In addition, VMEXIT from the TD guest mode may cause the execution of two additional actions. First, NMI and SMI may be disabled. Second, the TD mode bit may be cleared, such as cleared to zero ("0").

[0132] Fig.11A 1 is a block diagram illustrating a microarchitecture of a processor or integrated circuit that can implement hardware support for SEAM of a computing device that builds a TDX and operates within the TDX according to implementations of the present disclosure. Specifically, processor 1100 depicts an in-order architecture core and register renaming logic, out-of-order issue / execution logic to be included in the processor according to at least one implementation of the present disclosure.

[0133] The processor 1100 includes a front end unit 1130 coupled to an execution engine unit 1150, and both are coupled to a memory unit 1170. The processor 1100 may include 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 another option, the processor 1100 may include a special core, such as a network or communication core, a compression engine, a graphics core, etc. In one implementation, the processor 1100 may be a multi-core processor or may be part of a multi-processor system.

[0134] The front end unit 1130 includes a branch prediction unit 1132, which is coupled to an instruction cache unit 1134, which is coupled to an instruction translation lookaside buffer (TLB) 1136, which is coupled to an instruction fetch unit 1138, which is coupled to a decode unit 1140. The decode unit 1140 (also referred to as a decoder) can decode the instruction and generate one or more micro-operations, microcode entry points, micro-instructions, other instructions or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decoder 1140 can 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), and the like. The instruction cache unit 1134 is also coupled to a memory unit 1170. Decode unit 1140 is coupled to rename / allocator unit 1152 in execution engine unit 1150 .

[0135] The execution engine unit 1150 includes a rename / allocator unit 1152 coupled to a retirement unit 1154 and a set of one or more scheduler units 1156. The scheduler unit(s) 1156 represent any number of different scheduler circuits, including reservation stations (RS), central instruction windows, and the like. The scheduler unit(s) 1156 are coupled to physical register set(s) units 1158. Each of the physical register set units 1158 represents one or more physical register sets, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, and the like, status (e.g., an instruction pointer that is the address of the next instruction to be executed), and the like. The physical register set(s) unit 1158 overlaps with the retirement unit 1154 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using reorder buffer(s) and retirement register set(s), using future file(s), history buffer(s), and retirement register set(s); using register maps and pools of registers; etc.).

[0136] In general, architectural registers are visible from outside the processor or from the programmer's perspective. Registers are not limited to any known specific type of circuit. Various different types of registers are suitable as long as they can store and provide data as 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 and dynamically allocated physical registers, and the like. The retirement unit 1154 and the (one or more) physical register set unit 1158 are coupled to the (one or more) execution clusters 1160. The (one or more) execution clusters 1160 include a set of one or more execution units 1162 and a set of one or more memory access units 1164. The execution unit 1162 can perform various operations (e.g., shifts, additions, subtractions, multiplications) and operate on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point).

[0137] While some implementations may include several execution units dedicated to a particular function or set of functions, other implementations may include only one execution unit or multiple execution units that all perform all functions. Scheduler unit(s) 1156, physical register set unit(s) 1158, and execution cluster(s) 1160 are shown as potentially multiple because some implementations create separate pipelines for certain types of data / operations (e.g., scalar integer pipeline, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or memory access pipeline, each with its own scheduler unit, physical register set unit, and / or execution cluster - and in the case of a separate memory access pipeline, some implementations are implemented where only the execution cluster of this pipeline has memory access unit(s) 1164). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, with the rest being in-order.

[0138] The set of memory access units 1164 is coupled to a memory unit 1170, which may include, for example, a data prefetcher 1180, a data TLB unit 1172, a data cache unit (DCU) 1174, and a level 2 (L2) cache unit 1176. In some implementations, the DCU 1174 is also referred to as a first-level data cache (L1 cache). The DCU 1174 can handle multiple pending cache misses and continue to service incoming stores and loads. It also supports maintaining cache coherence. The data TLB unit 1172 is a cache for improving virtual address translation speed by mapping virtual and physical address spaces. In an exemplary implementation, the memory access unit 1164 may include a load unit, a storage address unit, and a storage data unit, each of which is coupled to the data TLB unit 1172 in the memory unit 1170. The L2 cache unit 1176 may be coupled to one or more other levels of cache and ultimately to the main memory.

[0139] In one implementation, the data prefetcher 1180 speculatively loads / prefetches data into the DCU 1174 by automatically predicting which data will be consumed by the program. Prefetching may refer to transferring data stored in one memory unit (e.g., location) of the memory hierarchy (e.g., a lower level cache or memory) to a higher level memory unit closer to the processor (e.g., resulting in lower access latency) before the processor actually needs the data. More specifically, prefetching may refer to fetching data from one of the lower level caches / memories to a data cache and / or prefetch buffer well in advance of the processor issuing a demand for returning specific data.

[0140] Processor 1100 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with later versions); the MIPS instruction set of Imagination Technologies, Inc. of Kings Langley, Hertfordshire, England; the ARM instruction set of ARM Holdings, Inc. of Sunnyvale, California (with optional additional extensions such as NEON).

[0141] It should be understood that a core may support multithreading (executing two or more parallel sets of operations or threads), and may support multithreading in a variety of ways, including time-sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core for each thread that the physical core is multithreading at the same time), or a combination of these (e.g., time-sliced ​​fetch and decode followed by simultaneous multithreading, such as Hyperthreading technology).

[0142] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in an in-order architecture. Although the illustrated implementation of the processor also includes separate instruction and data cache units and a shared L2 cache unit, alternative implementations 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 implementations, the system may include a combination of internal caches and external caches external to the core and / or processor. Alternatively, all caches may be external to the core and / or processor.

[0143] Fig. 11B According to some implementations of the present disclosure, Fig.11A A block diagram of an in-order pipeline and a register renaming stage, and an out-of-order issue / execution pipeline implemented by processor 1100. Fig. 11B The solid line box in shows the in-order pipeline 1101, while the dashed line box shows the register renaming, out-of-order issue / execution pipeline 1103. Fig. 11B , pipelines 1101 and 1103 include an instruction fetch stage 1102, a length decode stage 1104, a decode stage 1106, an allocation stage 1108, a rename stage 1110, a dispatch (also called dispatch or issue) stage 1112, a register read / memory read stage 1114, an execute stage 1116, a write back / memory write stage 1118, an exception handling stage 1120, and a commit stage 1122. In some implementations, the order of stages 1102-1124 may be different than shown and is not limited to Fig. 11B The specific ordering shown in .

[0144] Fig.12 A block diagram of a microarchitecture of a processing device 1200 including logic circuitry to provide secure arbitration mode (SEAM) capability for TDX operations is illustrated in accordance with at least one implementation of the present disclosure. In some implementations, instructions may be implemented to operate on data elements having sizes of bytes, words, double words, quad words, etc., and data types such as single and double precision integer and floating point data types. In one implementation, an in-order front end 1201 is the portion of the processing device 1200 that takes instructions to be executed and prepares them for use later in the processing device pipeline. An implementation that provides coexistence of a trust domain architecture with a multi-key total memory encryption technique may be implemented in the processing device 1200.

[0145] The front end 1201 may include several units. In one implementation, an instruction prefetcher 1226 fetches instructions from memory and feeds them to an instruction decoder 1228, which in turn decodes or interprets the instructions. For example, in one implementation, the decoder decodes the received instructions into one or more operations called "microinstructions" or "microoperations" (also called microops or uops) that the machine can perform. In other implementations, the decoder parses the instructions into opcodes and corresponding data and control fields, which are used by the microarchitecture to perform operations according to an implementation. In one implementation, a trace cache 1230 takes the decoded uops and assembles them into a program-ordered sequence or trace in a uop queue 1234 for execution. When the trace cache 1230 encounters a complex instruction, the microcode ROM 1232 provides the uops needed to complete the operation.

[0146] Some instructions are converted into a single micro-op, while others require several micro-ops to complete the entire operation. In one implementation, if more than four micro-ops are required to complete the instruction, the decoder 1218 accesses the microcode ROM 1232 to perform the instruction. For one implementation, the instruction may be decoded into a small number of micro-ops for processing at the instruction decoder 1228. In another implementation, if several micro-ops are required to complete the operation, the instruction may be stored in the microcode ROM 1232. The trace cache 1230 references the entry point programmable logic array (PLA) to determine the correct microinstruction pointer to use to read the microcode sequence from the microcode ROM 1232 to complete one or more instructions according to one implementation. After the microcode ROM 1232 completes sorting the micro-ops for an instruction, the front end 1201 of the machine proceeds to start fetching micro-ops from the trace cache 1230.

[0147] The out-of-order execution engine 1203 is where instructions are prepared for execution. The out-of-order execution logic has several buffers to smooth and reorder the flow of instructions as they travel down the pipeline and are scheduled for execution to optimize performance. The allocator logic allocates the machine buffers and resources required for each uop to execute. The allocator / register renaming logic 1240 renames the logical registers to entries in the register file. The allocator 1240 also allocates entries for each uop in one of the two uop queues in front of the instruction scheduler, one for memory operations 1242 and one for non-memory operations 1244, which are: memory scheduler 1246, fast scheduler 1202, slow / normal floating point scheduler 1204, and simple floating point scheduler 1206. The uop schedulers 1202, 1204, 1206 determine when a uop is ready to execute based on the readiness of its slave input register operand sources and the availability of the execution resources required for the uop to complete its operation. One implementation's fast scheduler 1202 may schedule on every half of the master clock cycle, while other schedulers may only schedule once per master processor clock cycle. The scheduler performs operations to dispatch ports arbitrate to schedule uops.

[0148] Register files 1208, 1210 are located between the execution units 1212, 1214, 1216, 1218, 1220, 1222, 1224 in the scheduler 1202, 1204, 1206 and the execution block 1211. There are separate register files 1208, 1210 for integer and floating point operations, respectively. Each register file 1208, 1210 of one implementation also includes a bypass network, which can bypass or forward the just completed result that has not yet been written to the register file to a new slave uop. The integer register file 1208 and the floating point register file 1210 can also communicate data with each other. For one implementation, the integer register file 1208 is divided into two separate register files, one register file for the low 32 bits of data and the second register file for the high 32 bits of data. The floating point register file 1210 of one implementation has 128-bit wide entries because floating point instructions usually have operands with a width of 64 to 128 bits.

[0149] The execution block 1211 contains execution units 1212, 1214, 1216, 1218, 1220, 1222, 1224, where instructions are actually executed. This section includes register files 1208, 1210 that store integer and floating point data operand values ​​required for microinstruction execution. The processing device 1200 of one implementation includes several execution units: address generation unit (AGU) 1212, AGU 1214, fast ALU 1216, fast ALU 1218, slow ALU 1220, floating point ALU 1222, floating point move unit 1224. For one implementation, the floating point execution blocks 1212, 1214 perform floating point, MMX, SIMD and SSE or other operations. The floating point ALU 1212 of one implementation includes a 64-bit by 64-bit floating point divider to perform division, square root and remainder micro ops. For implementations of the present disclosure, floating point hardware may be used to process instructions involving floating point values.

[0150] In one implementation, ALU operations go to high-speed ALU execution units 1216, 1218. The fast ALUs 1216, 1218 of one implementation can perform fast operations with an effective latency of half a clock cycle. For one implementation, most complex integer operations go to the slow ALU 1220 because the slow ALU 1220 includes integer execution hardware for long-latency operations such as multipliers, shifts, flag logic, and branch processing. Memory load / store operations are performed by AGUs 1212, 1214. For one implementation, the integer ALUs 1216, 1218, 1220 are described in the context of performing integer operations on 64-bit data operands. In alternative implementations, the ALUs 1216, 1218, 1220 can be implemented to support a variety of data bits, including 16, 32, 128, 256, and the like. Similarly, the floating point units 1222, 1224 may be implemented to support a range of operands having various widths of bits. For one implementation, the floating point units 1222, 1224 may operate on 128-bit wide packed data operands in conjunction with SIMD and multimedia instructions.

[0151] In one implementation, uop schedulers 1202, 1204, 1206 dispatch dependent operations before a parent load has completed execution. Since uops are speculatively scheduled and executed in processing device 1200, processing device 1200 also includes logic to handle memory misses. If a data load misses in the data cache, there may be dependent operations in progress in the pipeline that leave the scheduler with temporarily incorrect data. A replay mechanism tracks and re-executes instructions that use incorrect data. Only dependent operations need to be replayed, while independent operations are allowed to complete. The scheduler and replay mechanism of one implementation of the processing device are also designed to capture instruction sequences for text string comparison operations.

[0152] The processing device 1200 also includes logic to provide coexistence of the trust domain architecture with the multi-key total memory encryption technology according to one implementation. In one implementation, the execution block 1211 of the processing device 1200 may include the TDRM 142, the MOT 126, and the TDCS to provide coexistence of the trust domain architecture with the multi-key total memory encryption technology according to the description herein.

[0153] The term "register" may refer to a processing device storage location on a board that is used as part of an instruction to identify an operation object. In other words, registers may be those that are available from the outside of the processing device (from the programmer's perspective). However, the registers of an implementation should not be limited to a particular type of circuit in meaning. On the contrary, the registers of an implementation can 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 technologies, such as dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated and dynamically allocated physical registers, and the like. In one implementation, integer registers store thirty-two bit integer data. A register file of an implementation also includes eight multimedia SIMD registers for compacting data.

[0154] For the purposes of this discussion, a register is understood to be a data register designed to hold packed data, such as a 64-bit wide MMX register in a microprocessor device enabled with MMX technology from Intel Corporation of Santa Clara, California. TMRegisters (also referred to as "mm" registers in some cases). These MMX registers, available in both integer and floating point form, can be combined with the packed data element operations accompanying SIMD and SSE instructions. Similarly, 128-bit wide XMM registers associated with SSE2, SSE3, SSE4 or above (collectively referred to as "SSEx") technology can also be used to store such packed data operation objects. In one implementation, when storing packed data and integer data, registers do not need to distinguish between the two data types. In one implementation, integers and floating points are contained in the same register file or in different register files. In addition, in one implementation, floating point and integer data can be stored in different registers or in the same register.

[0155] Implementations that provide secure arbitration mode (SEAM) capability for TDX operation can be implemented in many different system types. Fig.13 , which shows a block diagram of a microprocessor device system 1300 according to an implementation. Fig.13 As shown in FIG. 1 , multi-processing device system 1300 is a point-to-point interconnect system and includes a first processing device 1370 and a second processing device 1380 coupled via a point-to-point interconnect 1350. Fig.13 As shown in , each of processing devices 1370 and 1380 can be a multi-core processing device, including first and second processing device cores (not shown), although there may be potentially many more cores in the processing devices. Each processing device may include hybrid write mode logic according to implementations of the present disclosure. Implementations that provide coexistence of a trust domain architecture with multi-key total memory encryption technology can be implemented in processing device 1370, processing device 1380, or both.

[0156] Although shown with two processing devices 1370, 1380, understand that the scope of the present disclosure is not limited in this regard. In other implementations, one or more additional processing devices may be present in a given processing device.

[0157] Processors 1370 and 1380 are shown as including integrated memory controllers (IMC) 1372 and 1382, respectively. Processing device 1370 also includes point-to-point (PP) interfaces 1376 and 1378 as part of its bus controller unit; similarly, second processing device 1380 includes PP interfaces 1386 and 1388. Processing devices 1370, 1380 can exchange information via point-to-point (PP) interface 1350 using PP interface circuits 1378, 1388. Fig.13As shown in FIG. 1 , IMCs 1372 and 1382 couple the processing devices to respective memories, namely, memory 1332 and memory 1334 , which may be portions of main memory locally attached to the respective processing devices.

[0158] Processors 1370, 1380 may each exchange information with chipset 1390 via respective PP interfaces 1352, 1354 using point-to-point interface circuits 1376, 1394, 1386, 1398. Chipset 1390 may also exchange information with high-performance graphics circuit 1338 via high-performance graphics interface 1392.

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

[0160] Chipset 1390 may be coupled to first bus 1316 via interface 1396. In one implementation, first bus 1316 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I / O interconnect bus, although the scope of the present disclosure is not limited in this regard.

[0161] like Fig.13 As shown in , various I / O devices 1314 may be coupled to first bus 1316, and a bus bridge 1318 that couples first bus 1316 to a second bus 1320. In one implementation, second bus 1320 may be a low pin count (LPC) bus. Various devices may be coupled to second bus 1320, including, for example, a keyboard and / or mouse 1322, communication devices 1327, and a storage unit 1328, such as a disk drive or other mass storage device, which in one implementation may include instructions / code and data 1330. Additionally, audio I / O 1324 may be coupled to second bus 1320. Note that other architectures are possible. For example, instead of Fig.13 In addition to the point-to-point architecture, the system can implement a multi-point branch bus or other such architecture.

[0162] Reference now Fig.14 , which shows a block diagram of a third system 1400 according to an implementation of the present disclosure. Fig.13 and Fig.14 Like elements in the text are numbered likewise, and Fig.13 Some aspects of Fig.14Omitted to avoid ambiguity Fig.14 other aspects.

[0163] Fig.14 Processors 1470, 1480 are illustrated. In one embodiment, processors 1470, 1480 may implement a hybrid core. Processors 1470, 1480 may include integrated memory and I / O control logic ("CL") 1472 and 1482, respectively, and communicate with each other via a point-to-point interconnect 1450 between point-to-point (PP) interfaces 1478 and 1488, respectively. Processors 1470, 1480 each communicate with chipset 1490 via point-to-point interconnects 1452 and 1454 through respective PP interfaces 1476 to 1494 and 1486 to 1498 as shown. For at least one implementation, CL 1072, 1082 may include IMC 1472, 1482 as described herein. In addition, CL 1472, 1482 may also include I / O control logic. Fig.14 Memories 1432, 1434 are shown coupled to CLs 1472, 1482, and I / O device 1414 is also coupled to CLs 1472, 1482. Legacy I / O device 1415 is coupled to chipset 1490 via interface 1496. Implementations that provide coexistence of a trust domain architecture with multi-key total memory encryption techniques may be implemented in processing device 1470, processing device 1480, or both.

[0164] Fig.15 1512N, may include one or more of the cores 1512A ... 1512N of the application processor 1510. Other system designs and configurations known in the art for laptop computers, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processing devices, digital signal processing devices (digital signal processing devices, DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, many types of systems or electronic devices that can contain the processing devices and / or other execution logic disclosed herein are generally suitable.

[0165] Reference now Fig.15 , which shows a block diagram of a SoC 1500 according to an implementation of the present disclosure. In addition, the dashed boxes are features on a more advanced SoC. Fig.151500 , the interconnect unit(s) 1502 are coupled to: an application processor 1510 including a set of one or more cores 1512A-N including one or more cache units 1504A ... 1504N, and a shared cache unit(s) 1506; a system agent unit 1513; a bus controller unit(s) 1516; an integrated memory controller unit(s) 1514; a set of one or more media processing devices 1520, which may include integrated graphics logic 1508, an image processing device 1524 for providing still and / or video camera functionality, an audio processing device 1526 for providing hardware audio acceleration, and a video processing device 1528 for providing video encoding / decoding acceleration; a static random access memory (SRAM) unit 1530; a direct memory access (DMA) unit 1532; and a display unit 1540 for coupling to one or more external displays. An implementation providing coexistence of a trust domain architecture with a multi-key total memory encryption technique may be implemented in the SoC 1500 .

[0166] Next go to Fig.16 , depicting an implementation of a SoC design according to an implementation of the present disclosure. As an illustrative example, SoC 1600 is included in a user equipment (UE). In one implementation, UE refers to any device that will be used by an end user to communicate, such as a handheld phone, a smart phone, a tablet device, an ultra-thin notebook, a notebook with a broadband adapter, or any other similar communication device. The UE may be connected to a base station or node, which may correspond in nature to a mobile station (MS) in a GSM network. An implementation that provides coexistence of a trust domain architecture with multi-key total memory encryption technology may be implemented in SoC 1600.

[0167] Here, SoC 1620 includes two cores, 1606 and 1607. Similar to the above discussion, cores 1606 and 1607 may conform to an instruction set architecture, such as having ArchitectureCore TM, Advanced Micro Devices, Inc. (AMD) processing devices, MIPS-based processing devices, ARM-based processing device designs, or their customers, and their licensees or users. Cores 1606 and 1607 are coupled to cache control 1608 associated with bus interface unit 1609 and L2 cache 1610 to communicate with other parts of system 1600. Interconnect 1611 includes an on-chip interconnect, such as IOSF, AMBA, or other interconnects discussed above, which can implement one or more aspects of the described disclosure.

[0168] Interconnect 1611 provides communication channels to other components, such as to Subscriber Identity Module (SIM) 1630 to interface with a SIM card, to Boot ROM 1635 to store boot code for execution by cores 1606 and 1607 to initialize and boot SoC 1600, to SDRAM controller 1640 to interface with external memory (e.g., DRAM 1660), to Flash controller 1645 to interface with non-volatile memory (e.g., Flash 1665), to Peripheral Control 1650 (e.g., Serial Peripheral Interface) to interface with peripherals, to Video Codec 1620 and Video Interface 1625 to display and receive input (e.g., touch-enabled input), to GPU 1615 to perform graphics-related calculations, etc. Any of these interfaces may include aspects of the implementations described herein.

[0169] In addition, the system illustrates peripherals for communication, such as power control module 1655, module 1670, 3G modem 1675, GPS 1680, and Wi-Fi 1685. Note that as described above, the UE includes a radio for communication. As a result, these peripheral communication modules may not all be included. However, in the UE, some form of radio should be included for external communications.

[0170] Fig.171 is a block diagram of processing components for executing instructions for implementing a secure arbitration mode (SEAM) for TDX operations according to one implementation. As shown, computing system 1700 includes code storage 1702, instruction fetch circuitry 1704, decoding circuitry 1706, execution circuitry 1708, registers 1710, memory 1712, and retirement or commit circuitry 1714. In operation, instructions (e.g., SEAMCALL or SEAMEXIT) will be fetched by instruction fetch circuitry 1704 from code storage 1702, which may include, but is not limited to, cache memory, on-chip memory, memory on the same die as the processor, instruction registers, general registers, or system memory. In one implementation, instructions may have Fig.14 1400 in the same format. After retrieving the instruction from the code storage device 1702, the decoding circuit 1706 may decode the retrieved instruction, including by parsing various fields of the instruction. After decoding the retrieved instruction, the execution circuit 1708 will execute the decoded instruction. While performing the step of executing the instruction, the execution circuit 1708 may read data from and write data to registers 1710 and memory 1712. Registers 1710 may include data registers, instruction registers, vector registers, mask registers, general registers, on-chip memory, memory on the same die as the processor, or memory in the same package as the processor, but are not limited to this. Memory 1712 may include on-chip memory, memory on the same die as the processor, memory in the same package as the processor, cache memory, or system memory, but are not limited to this. After the execution circuit executes the instruction, the retirement or submission circuit 1714 may retire the instruction, ensure that the execution result is written to or has been written to its destination, and free up or release resources for later use.

[0171] Fig.18 18 is a flow chart of an example method 1820 to be executed by a processor to execute a SEAMCALL instruction to cause the processor to enter a trust domain (TD) according to one implementation. After starting the process, the instruction fetch circuitry retrieves the SEAMCALL instruction from the code storage device at block 1822. At optional block 1824, the decode circuitry may decode the retrieved SEAMCALL instruction. At block 1826, the execution circuitry executes the SEAMCALL instruction to cause the logical processor to enter a secure arbitration mode (SEAM) for TDX operation. Entering into SEAM transfers SEAM VMX root mode operation control to the logical processor. Additional actions performed by the SEAMCALL instruction (e.g., regarding storing VMM state and causing the processor to transition to the SEAM state) have been referenced. Fig.9A and Fig.10 Therefore, it will not be discussed in more detail here.

[0172] Fig.19 19 is a flow chart of an example method 1920 to be executed by a processor to execute a SAMEXIT instruction to cause the processor to exit from a trust domain (TD) according to an implementation. After starting the process, the instruction fetch circuitry retrieves the SAMEXIT instruction from the code storage device at block 1922. At optional block 1924, the decode circuitry may decode the retrieved SAMEXIT instruction. At block 1926, the execution circuitry executes the SAMEXIT instruction to cause the logical processor to exit from SAME, thereby transferring VMX root mode operating control back to the VMM. Additional actions performed by the SAMEXIT instruction (e.g., restoring the VMM state) have been previously described with reference to Fig. 9B Therefore, it will not be discussed in more detail here.

[0173] Fig. 20 2000 for implementing a secure arbitration mode (SEAM) for TDX operations. The instruction 2000 may be a SEAMCALL or SEAMEXIT instruction. The parameters in the format of the instruction 2000 may be different for the SEAMCALL or for the SEAMEXIT instruction. Thus, some parameters are depicted as optional with dashed lines. In an implementation, the instruction 2000 includes a page address 2002, an optional opcode 2004, an optional attribute 2006, an optional secure status bit 2008, and an optional valid status bit 2010.

[0174] Fig.21 A schematic representation of a machine in the example form of a computing system 2100 is illustrated, in which a set of instructions can be executed to cause the machine to perform any one or more methods discussed herein. In alternative implementations, the machine can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine can operate as 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 can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a web appliance, a server, a network router, a switch or a bridge, or any machine capable of executing a set of instructions (sequential or otherwise) specifying the actions to be taken by the machine. In addition, although only a single machine is illustrated, the term "machine" should also be understood to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform one or more methods discussed herein. The implementation of conversion pages and segments can be implemented in the computing system 2100.

[0175] The computing system 2100 includes a processing device 2102, a main memory 2104 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (e.g., synchronous DRAM (SDRAM) or DRAM (RDRAM)), etc.), a static memory 2106 (e.g., flash memory, static random access memory (SRAM)), etc.), and a data storage device 2118, which communicate with each other via a bus 2130.

[0176] The processing device 2102 represents one or more general processing devices, such as a microprocessing device, a central processing unit, and the like. More specifically, the 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 that implements other instruction sets, or a processing device that implements a combination of instruction sets. The processing device 2102 may also be one or more special 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, and the like. In one implementation, the processing device 2102 may include one or more processing device cores. The processing device 2102 is configured to execute instructions 2126 for performing the operations discussed herein. In one implementation, the processing device 2102 may be part of the computing system 100 of FIG. 1. Alternatively, the computing system 2100 may include other components as described herein. It should be understood that a core may support multithreading (executing two or more parallel sets of operations or threads), and may support multithreading in a variety of ways, including time-sliced ​​multithreading, simultaneous multithreading (where a single physical core provides a logical core for each thread that the physical core is multithreading at the same time), or a combination of these (e.g., time-sliced ​​fetch and decode followed by simultaneous multithreading, such as Hyperthreading technology).

[0177] The computing system 2100 may also include a network interface device 2108 communicatively coupled to the network 2120. The computing system 2100 may also include a video display unit 2110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 2112 (e.g., a keyboard), a cursor control device 2114 (e.g., a mouse), a signal generating device 2116 (e.g., a speaker), or other peripheral devices. In addition, the computing system 2100 may include a graphics processing unit 2122, a video processing unit 2128, and an audio processing unit 2132. In another implementation, the computing system 2100 may include a chipset (not shown), which refers to a group of integrated circuits or chips designed to work with the processing device 2102 and control communications between the processing device 2102 and external devices. For example, a chipset may be a group of chips on a motherboard that links the processing device 2102 to very high-speed devices, such as main memory 2104 and a graphics controller, and to a lower-speed peripheral bus, such as a USB, PCI, or ISA bus, that links the processing device 2102 to peripherals.

[0178] The data storage device 2118 may include a computer-readable storage medium 2124 having stored thereon instructions 2126 for implementing any one or more of the methods of functionality described herein. The instructions 2126 may also reside, in whole or in part, as instructions 2126 within the main memory 2104 and / or as processing logic within the processing device 2102 during execution thereof by the computing system 2100; the main memory 2104 and the processing device 2102 also constituting computer-readable storage media.

[0179] The computer-readable storage medium 2124 may also be used to store instructions 2126 for utilizing the processing device 2102, such as described with reference to FIG. 1, and / or a software library containing methods for invoking the above-mentioned applications. Although the computer-readable storage medium 2124 is shown as a single medium in the example implementation, the term "computer-readable storage medium" should be understood 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 understood to include any medium that can store, encode, or carry a set of instructions for execution by a machine and cause the machine to execute any one or more methods of the implementation. The term "computer-readable storage medium" should accordingly be understood to include, but is not limited to, solid-state memory, as well as optical and magnetic media.

[0180] The following examples are further implementations.

[0181] Example 1 is a processor comprising: 1) a range register for storing information identifying a reserved range of a memory associated with a secure arbitration mode (SEAM) of the processor; and 2) a processor core coupled to the range register, wherein the processor core includes security logic for unlocking the range register on a logical processor of the processor core for initiating the SEAM; and 3) wherein the logical processor, via execution of the security logic, is used to: a) store a SEAM module and a manifest associated with the SEAM module in a reserved range of the memory identified by the information stored in the range register, wherein the SEAM module is used to support execution of one or more trust domains; b) initialize a SEAM virtual machine control structure (VMCS) within the reserved range of the memory, the SEAMVMCS being used to control state transitions between a virtual machine monitor (VMM) and a SEAM module; and c) authenticate the SEAM module using a manifest signature of the manifest.

[0182] In Example 2, the processor as described in Example 1 further includes 1) multiple measurement registers and 2) a security virtual number (SVN) register, wherein the security logic is also used to: a) record the measurement, identity and SVN value of the SEAM module into the multiple measurement registers; and b) verify the SVN value against a previously recorded SVN value stored in the SVN register.

[0183] In Example 3, a processor as described in Example 2, wherein the manifest includes a combination of at least two of the following: a) a manifest signer public key; b) a first digest of the manifest signer public key, wherein the first digest is the recorded identity of the SEAM module; c) a second digest of the SEAM module and associated loadable components; or d) attributes of the SEAM module; and wherein, in order to record measurements of the SEAM module, the security logic also: e) generates a third digest of the combination of: (i) the SEAM module and associated loadable components; and (ii) the manifest signature; and f) records the third digest as a measurement of the SEAM module in at least one of the multiple measurement registers.

[0184] In Example 4, a processor as described in Example 1, wherein the security logic is further used to perform the following operations in response to a request to load the SEAM module: a) generate a page table to map a reserved range of the memory; b) generate a configurable number of software-writable page directory pointer (PDP) structures to map additional memory, the additional memory being used to store data of the one or more trust domains; c) store the page table and the software-writable PDP structure within the reserved range of the memory; and d) store a page table pointer pointing to the page table in the SEAM VMCS to establish a SEAM state upon subsequent execution of a SEAMCALL instruction.

[0185] In Example 5, a processor as described in Example 1, wherein the security logic is further used to: a) initialize a configuration area within a reserved range of the memory using a data array; and b) initialize multiple SEAM VMCSs including the SEAM VMCS within the data array, wherein each of the multiple SEAM VMCSs is assigned to a different logical processor of the processor core, wherein initializing the multiple VMCSs includes initializing fields of each VMCS.

[0186] In Example 6, a processor as described in Example 1, wherein the processor core is further used to execute memory check firmware to perform the following operations: a) verify that the reserved range programmed into the range register by the basic input / output system (BIOS) firmware does not overlap with other reserved ranges of the memory; b) verify that the processor's multi-key total memory encryption (MK-TME) engine is configured with integrity enabled; c) configure the platform reserved encryption key of the MK-TME engine to encrypt and integrity and replay protect data stored to the reserved range of the memory; and d) mark the reserved range of the memory as valid to store the SEAM module therein.

[0187] In Example 7, the processor as described in Example 6 further includes a memory controller, which includes the MK-TME engine, and the memory controller is used to: a) encrypt the SEAM module using the platform reserved encryption key before the SEAM module is stored in the reserved range of the memory; and b) encrypt and integrity protect the data stored in and retrieved from the reserved range of the memory using the platform reserved encryption key.

[0188] In Example 8, a processor as described in Example 1, wherein the processor core is further used to execute memory check firmware to perform the following operations: a) divide a key identifier (ID) space according to a division set by basic input / output system (BIOS) firmware in a configuration register at boot time, wherein the key ID space is divided between at least a first value range that identifies a private key ID and a second value range that identifies a shared key ID; and b) configure lock the key ID space via a lock on the configuration register.

[0189] In Example 9, a processor as described in Example 1, wherein the logical processor is used to execute the VMM, wherein the VMM is used to call the execution of the SEAMCALL instruction, in response to which the processor core is used to: a) exit as a virtual machine (VM) and transfer virtual root mode operation control to the SEAM module; and b) register the call of the secure arbitration mode as the reason for the VM exit.

[0190] In Example 10, a processor as described in Example 9, wherein the processor core is further used to: a) store a first state of the VMM in the SEAM VMCS; b) load a second state associated with the SEAM module from the SEAM VMCS into the processor; c) operate in the SEAM virtual root mode using the SEAM module when the second state is loaded into the processor; and d) start a first trust domain (TD) using the SEAM module to run in the SEAM virtual non-root mode.

[0191] In Example 11, a processor as described in claim 10, wherein, in response to a system management interrupt, the processor core is also used to: a) cause an exit from the first TD to the SEAM virtual root mode; b) retrieve confidential data from hardware registers associated with the operation of the first TD within the SEAM; c) store the TD state of the first TD to the TD VMCS of the first TD stored in the memory; and d) transfer control to the SEAM module, which will call execution of the SAMEXIT instruction to transfer virtual root mode operation control to the VMM.

[0192] Various implementations may have different combinations of the structural features described above. For example, all optional features of the processors and methods described above may also be implemented for the systems described herein and the specific details in the examples may be used anywhere in one or more implementations.

[0193] Example 12 is a system comprising: 1) a memory device including a reserved range to store a secure arbitration mode (SEAM) module, the SEAM module supporting one or more trust domains (TDs); and 2) a processor coupled to the memory device and including a memory controller, wherein the processor is used to execute the SEAM module to perform the following operations: a) create a TD virtual machine structure (VMCS) in the memory device, the TD VMCS being associated with a first TD; b) store a first pointer to a shared extended page table (EPT) in the TD VMCS, the shared EPT being shared with a virtual machine monitor (VMM) for accessing a shared memory of the memory device; c) store a second pointer to a secure EPT in the TD VMCS, wherein the secure EPT is accessible to the SEAM module for accessing a private memory of the memory device; and d) convert a guest physical address of the first TD to a host physical address of the memory device via a walk of the secure EPT pointed to by the first pointer.

[0194] In Example 13, a system as described in Example 12, wherein the processor is further used to execute the SEAM module to perform the following operations: a) programming a trust domain host key identifier (TD-HKID) to correspond to a private memory encryption key, wherein the private memory encryption key programmed for the TD-HKID is unknown to the VMM; and b) contacting the first TD in the TD VMCS to store the value of the TD-HKID; and c) wherein the memory controller is further used to encrypt the following data using the private memory encryption key: the data will be stored in the private memory at a location identified by the host physical address.

[0195] In Example 14, a system as described in Example 12, wherein the processor is further used to: a) read a position bit of the second pointer from the TD VMCS; b) determine a position of an indicator bit within the guest physical address based on a first value of the position bit, wherein an operating system of the first TD will set the value of the indicator bit; and c) determine a second value of the indicator bit stored at the position of the guest physical address.

[0196] In Example 15, a system as described in Example 14, wherein the memory controller is used to: a) determine that the EPT is a shared EPT based on the second value of the indicator bit; b) encrypt data destined for the host physical address using a shared encryption key shared with the VMM to generate encrypted data; and c) store the encrypted data in the memory device at a host physical address located in a shared memory of the memory device.

[0197] In Example 16, the system as described in Example 14, wherein the memory controller further: a) determines that the EPT is a secure EPT based on the second value of the indicator bit; b) encrypts data destined for the host physical address using a private encryption key associated with a trust domain host key identifier to generate encrypted data; and c) stores the encrypted data in the memory device at a host physical address located in a private memory of the memory device.

[0198] Various implementations may have different combinations of the structural features described above. For example, all optional features of the processors and methods described above may also be implemented for the systems described herein and the specific details in the examples may be used anywhere in one or more implementations.

[0199] Example 17 is a method comprising: 1) booting a secure arbitration mode (SEAM) module into operation from a reserved range of memory within a memory device coupled to the processor by a processor-starting authentication code module; a) calling a SEAM call (SEAMCALL) instruction by a virtual machine monitor (VMM) executed by the processor; 3) executing the SEAMCALL instruction by the processor, comprising: a) saving the VMM state of the processor to a guest area of ​​a SEAM virtual machine control structure (VMCS) stored in the reserved range of the memory; b) loading and imposing the SEAM module state into the processor from a host state area of ​​the SEAM VMCS; b) transitioning the processor to a SEAM virtual root operation mode; and c) executing instructions in the SEAM module starting from an instruction address programmed into the SEAM VMCS; and 4) initializing a trust domain (TD) virtual machine control structure (VMCS) in the memory via the operation of the SEAM module, the TD VMCS supporting the operation of a first TD.

[0200] In Example 18, the method as described in Example 17 further includes 1) programming the following into the TD VMCS by the SEAM module: a) a first pointer to a shared extended page table (EPT), wherein the shared EPT is shared with the VMM and is used to access the shared memory of the memory device; b) a second pointer to a secure EPT, wherein the secure EPT is accessible to the SEAM module and is used to access the private memory of the memory device; and c) a trusted domain host key identifier (TD-HKID) to correspond to a private memory encryption key, wherein the private memory encryption key programmed for the TD-HKID is unknown to the VMM.

[0201] In Example 19, the method as described in Example 18 further includes 1) allowing the SEAM module to call a second instruction that is inaccessible to the processor in operations outside the SEAM, wherein the second instruction includes at least one of the following: a) a processor configuration (PCONFIG) operation that programs the private memory encryption key to correspond to the TD-HKID; or b) in response to execution of the SEAMCALL instruction, disabling the system management interrupt (SMI) and non-maskable interrupt (NMI) of the processor.

[0202] In Example 20, the method as described in Example 18 further includes performing the following operations in response to the SEAM module calling the execution of the VMRESUME instruction for the first trust domain (TD): a) loading the TD state of the first TD from the TD VMCS stored in the memory device into the processor; and b) continuing to start the operation of the first TD in the SEAM virtual non-root mode.

[0203] In Example 21, the method of Example 20, wherein continuing to start the operation of the first TD includes, in response to a VM entry, performing the following operations: 1) determining that an enable EPT VM execution control bit of the TD VMCS has a value of zero; and 2) generating a VM entry failure due to an invalid control field.

[0204] In Example 22, the method of Example 20 further includes: 1) determining that an enable EPT VM execution control bit of the TD VMCS has a value of one; and 2) determining that a secure EPT pointer VM execution control field of the TD VMCS satisfies a set of predetermined criteria.

[0205] In Example 23, the method of Example 20, wherein continuing to start operation of the first TD includes verifying that the TD-HKID is non-zero and is a private key ID.

[0206] In Example 24, the method as described in Example 20 further includes: 1) disabling the system management interrupt (SMI) and non-maskable interrupt (NMI) of the processor when the SEAMCALL instruction is executed; and 2) programming the values ​​of the first pointer and the second pointer into the page miss handler (PMH) control register of the processor; and 3) wherein continuing to start the operation of the first trust domain also includes unblocking the SMI and NMI of the processor.

[0207] In Example 25, a method as described in Example 20, wherein continuing to start the operation of the first TD includes 1) calculating, by a page miss handler (PMH) of the processor, an address space identifier (ASID) used to mark the address of the first TD in an entry of a translation lookaside buffer (TLB), wherein the calculation includes: a) using a second pointer of the secure EPT to replace the first pointer to locate an extended page table for address translation; and b) setting a trust domain (TD) bit of the ASID to indicate an association with the first trust domain, wherein the TD bit makes the ASID unique for the first TD and for SEAM operations.

[0208] Various implementations may have different combinations of the structural features described above. For example, all optional features of the processors and methods described above may also be implemented for the systems described herein and the specific details in the examples may be used anywhere in one or more implementations.

[0209] Example 26 is a non-transitory computer-readable medium storing instructions that, when executed by a processor having a core coupled to a system memory, cause the processor to perform multiple logical operations, including: 1) booting a secure arbitration mode (SEAM) module into operation from a reserved range of memory within a memory device coupled to the processor by launching an authentication code module by the processor; a) calling a SEAM call (SEAMCALL) instruction by a virtual machine monitor (VMM) executed by the processor; 3) executing the SEAMCALL instruction by the processor, including: a) saving the VMM state of the processor to a guest area of ​​a SEAM virtual machine control structure (VMCS) stored in a reserved range of the memory; b) loading and imposing the SEAM module state into the processor from a host state area of ​​the SEAM VMCS; b) transitioning the processor to a SEAM virtual root operating mode; and c) executing instructions in the SEAM module starting from an instruction address programmed into the SEAM VMCS; and 4) initializing a trust domain (TD) virtual machine control structure (VMCS) in the memory via the operation of the SEAM module, the TD VMCS supporting the operation of a first TD.

[0210] In Example 27, the non-transitory computer-readable medium as described in Example 26, wherein the operation further includes: 1) programming by the SEAM module into the TD VMCS: a) a first pointer to a shared extended page table (EPT), wherein the shared EPT is shared with the VMM and is used to access the shared memory of the memory device; b) a second pointer to a secure EPT, wherein the secure EPT is accessible to the SEAM module and is used to access the private memory of the memory device; and c) a trusted domain host key identifier (TD-HKID) to correspond to a private memory encryption key, wherein the private memory encryption key programmed for the TD-HKID is unknown to the VMM.

[0211] In Example 28, the non-transitory computer-readable medium as described in Example 27, wherein the operation also includes 1) allowing the SEAM module to call a second instruction that is inaccessible to the processor in operations outside the SEAM, wherein the second instruction includes at least one of the following: a) a processor configuration (PCONFIG) operation that programs the private memory encryption key to correspond to the TD-HKID; or b) in response to execution of the SEAMCALL instruction, disabling system management interrupts (SMI) and non-maskable interrupts (NMI) of the processor.

[0212] In Example 29, the non-transitory computer-readable medium as described in Example 27, wherein the operation also includes, in response to the SEAM module calling execution of the VMRESUME instruction for a first trust domain (TD): a) loading the TD state of the first TD into the processor from the TD VMCS stored in the memory device; and b) continuing to start operation of the first TD in the SEAM virtual non-root mode.

[0213] In Example 30, the non-transitory computer readable medium of Example 29, wherein continuing to start the operation of the first TD includes, in response to VM entry: 1) determining that an enable EPT VM execution control bit of the TD VMCS has a value of zero; and 2) generating a VM entry failure due to an invalid control field.

[0214] In Example 31, the non-transitory computer readable medium of Example 29, wherein the operations further include: 1) determining that an enable EPT VM execution control bit of the TD VMCS has a value of one; and 2) determining that a secure EPT pointer VM execution control field of the TD VMCS satisfies a set of predetermined criteria.

[0215] In Example 32, the non-transitory computer readable medium of Example 29, wherein continuing to start operation of the first TD includes verifying that the TD-HKID is non-zero and is a private key ID.

[0216] In Example 33, the non-transitory computer-readable medium as described in Example 29, wherein the operation further includes: 1) disabling a system management interrupt (SMI) and a non-maskable interrupt (NMI) of the processor when the SEAMCALL instruction is executed; and 2) programming the values ​​of the first pointer and the second pointer into a page miss handler (PMH) control register of the processor; and 3) wherein continuing to start the operation of the first trust domain also includes unblocking the SMI and NMI of the processor.

[0217] In Example 34, a non-transitory computer-readable medium as described in Example 20, wherein the operation of continuing to start the first TD includes 1) calculating, by a page miss handler (PMH) of the processor, an address space identifier (ASID) used to mark the address of the first TD in an entry of a translation lookaside buffer (TLB), wherein the calculation includes: a) using a second pointer of the secure EPT to replace the first pointer to locate an extended page table for address translation; and b) setting a trust domain (TD) bit of the ASID to indicate an association with the first trust domain, wherein the TD bit makes the ASID unique for the first TD and for SEAM operations.

[0218] Various implementations may have different combinations of the structural features described above. For example, all optional features of the processors and methods described above may also be implemented for the systems described herein and the specific details in the examples may be used anywhere in one or more implementations.

[0219] Example 35 is a system comprising: 1) a device for storing a secure arbitration mode (SEAM) module, the SEAM module supporting one or more trust domains (TDs); and 2) a device for executing the SEAM module to perform the following operations: a) creating a TD virtual machine structure (VMCS) in the memory device, the TD VMCS being associated with a first TD, b) storing a first pointer to a shared extended page table (EPT) in the TD VMCS, the shared EPT being shared with a virtual machine monitor (VMM) for accessing a shared memory of the memory device; c) storing a second pointer to a secure EPT in the TD VMCS, wherein the secure EPT is accessible to the SEAM module for accessing a private memory of the memory device; and d) converting a guest physical address of the first TD to a host physical address of the memory device via a walk of the secure EPT pointed to by the first pointer.

[0220] In Example 36, the system as described in Example 35 further includes: 1) a device for executing the SEAM module to perform the following operations: a) programming a trusted domain host key identifier (TD-HKID) to correspond to a private memory encryption key, wherein the private memory encryption key programmed for the TD-HKID is unknown to the VMM; and b) contacting the first TD in the TD VMCS to store the value of the TD-HKID; and c) a device for encrypting data to be stored in the private memory at a location identified by the host physical address using the private memory encryption key.

[0221] In Example 37, the system as described in Example 35 further includes: a) a device for reading the location bit of the second pointer from the TD VMCS; b) a device for determining the position of the indicator bit within the guest physical address based on a first value of the location bit, wherein the operating system of the first TD will set the value of the indicator bit; and c) a device for determining a second value of the indicator bit stored at the location of the guest physical address.

[0222] In Example 38, the system as described in Example 37 further includes: a) a device for determining that the EPT is a shared EPT based on the second value of the indicator bit; b) a device for encrypting data destined for the host physical address using a shared encryption key shared with the VMM to generate encrypted data; and c) a device for storing the encrypted data in the memory device at a host physical address within a shared memory of the memory device.

[0223] In Example 39, the system as described in Example 37 further includes: a) a device for determining that the EPT is a secure EPT based on the second value of the indicator bit; b) a device for encrypting data destined for the host physical address using a private encryption key associated with a trust domain host key identifier to generate encrypted data; and c) a device for storing the encrypted data in the memory device at a host physical address located in a private memory of the memory device.

[0224] While the present disclosure has been described with respect to a limited number of implementations, those skilled in the art will readily appreciate numerous modifications and variations therefrom. 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.

[0225] In the description herein, many specific details are set forth, such as examples of specific types of processing devices and system configurations, specific hardware structures, specific architectures and microarchitecture details, specific register configurations, specific instruction types, specific system components, specific measurements / heights, specific processing device pipeline stages and operations, etc., in order to provide a thorough understanding of the present disclosure. However, it will be clear to those skilled in the art that these specific details are not required to implement the present disclosure. In other cases, well-known components or methods, such as specific and alternative processing device architectures, specific logic circuits / code for the described algorithms, specific firmware code, specific interconnect operations, specific logic configurations, specific manufacturing techniques and materials, specific compiler implementations, specific representations of algorithms in code, specific power-off and gating techniques / logic, and other specific operational details of computer systems are not described in detail to avoid unnecessarily obscuring the present disclosure.

[0226] The implementation is described with reference to providing coexistence of a trust domain architecture and a multi-key total memory encryption technique in a virtualized system using a trust domain in a specific integrated circuit, such as a computing platform or a microprocessor device. The implementation may also be applicable to other types of integrated circuits and programmable logic devices. For example, the disclosed implementation is not limited to desktop computer systems or portable computers, such as Ultrabooks TM Computer. And can also be used in other devices, such as handheld devices, tablet devices, other thin notebooks, system on chip (SoC) devices and embedded applications. Some examples of handheld devices include cellular 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 chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system that can perform the functions and operations taught below. It is described that the system can be any kind of computer or embedded system. The disclosed implementation is particularly useful for low-end devices, such as wearable devices (e.g., watches), electronic implants, sensory and control infrastructure equipment, controllers, supervisory control and data acquisition (SCADA) systems, etc. In addition, the apparatus, methods and systems described herein are not limited to physical computing devices, but may also involve software optimization for energy conservation and efficiency. As will become readily apparent in the following description, implementation of the methods, apparatus, and systems described herein (whether in terms of hardware, firmware, software, or a combination thereof) is critical to a "green technology" future balanced with performance considerations.

[0227] Although the implementation here is described with reference to processing equipment, other implementations are applicable to other types of integrated circuits and logic devices. Similar techniques and teachings of the implementation of the present disclosure can be applied to other types of circuits or semiconductor devices that can benefit from higher pipeline throughput and improved performance. The teachings of the implementation of the present disclosure are applicable to any processing equipment or machine that performs data manipulation. However, the present disclosure is not limited to processing equipment or machines that perform 512-bit, 256-bit, 128-bit, 64-bit, 32-bit or 16-bit data operations, but can be applied to any processing equipment and machine that performs the manipulation or management of data therein. In addition, the description here provides examples, and the accompanying drawings show various examples for illustration. However, these examples should not be interpreted in a limiting sense, because they are just intended to provide examples of the implementation of the present disclosure, rather than providing an exhaustive list of all possible implementations of the implementation of the present disclosure.

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

[0229] Instructions for programming logic to perform the implementation of the present disclosure may be stored in a memory in the system, such as a DRAM, cache, flash memory, or other storage device. In addition, the instructions may be distributed via a network or by other computer-readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, but not limited to, a floppy disk, an optical disk, a compact disc read-only memory (Compact Disc, Read-Only Memory, CD-ROM), and a magneto-optical disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), an erasable programmable read-only memory (Erasable Programmable Read-Only Memory, EPROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic card or an optical card, a flash memory, or a tangible machine-readable storage device used when transmitting information through the Internet via an electrical, optical, acoustic, or other form of propagation signal (e.g., a carrier wave, an infrared signal, a digital signal, etc.). Accordingly, computer-readable media includes any type of tangible machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0230] A design may go through various stages, from creation to simulation to manufacturing. Data representing a design may represent the design in several ways. First, as useful in simulation, hardware may be represented using a hardware description language or another functional description language. In addition, a circuit-level model with logic and / or transistor gates may be generated at some stages of the design process. In addition, most designs reach the level of data representing the physical placement of various devices in a hardware model at a certain stage. In the case of using conventional semiconductor manufacturing techniques, the data representing the hardware model may be data specifying the presence or absence of various features on different mask layers for a mask used to produce an integrated circuit. In any representation of a design, data may be stored in any form of machine-readable medium. A memory or a magnetic storage device or optical storage device such as a disk may be a machine-readable medium for storing information transmitted via light waves or electric waves, which are modulated or otherwise generated to transmit such information. When an electric carrier wave indicating or carrying a code or design is transmitted, a new copy is made in terms of performing a copy, buffering, or retransmission of an electric signal. Thus, a communications provider or network provider may store, at least temporarily, an article, such as information encoded into a carrier wave, embodying techniques of implementations of the present disclosure on a tangible machine-readable medium.

[0231] Module used herein refers to any combination of hardware, software and / or firmware. As an example, a module includes hardware, such as a microcontroller, which is associated with a non-transient medium to store code suitable for being executed by the microcontroller. Therefore, in one implementation, mentioning a module refers to hardware, which is specially configured to identify and / or execute code to be stored on a non-transient medium. In addition, in another implementation, the use of a module refers to a non-transient medium including a code, which is particularly suitable for being executed by a microcontroller to perform a predetermined operation. As can be inferred, in another implementation, the term module (in this example) can refer to a combination of a microcontroller and a non-transient medium. Typically, the module boundaries illustrated as being separated are generally variable and may overlap. For example, the first and second modules may share hardware, software, firmware, or a combination thereof, and may retain some independent hardware, software, or firmware. In one implementation, the use of the term logic includes hardware, such as transistors, registers, or other hardware, such as programmable logic devices.

[0232] The use of the phrase "configured to" refers in one implementation 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 the specified task. As a purely illustrative example, a logic gate can provide a 0 or 1 during operation. But a logic gate that is "configured to" provide an enable signal to a clock does not include every possible logic gate that can provide a 1 or 0. Instead, the logic gate is coupled in a way that a 1 or 0 output during operation enables the clock. Note again that the use of the term "configured to" does not require operation, but focuses on the potential state of the device, hardware and / or element, where in the potential state, the device, hardware and / or element is designed to perform a specific task when the device, hardware and / or element is in operation.

[0233] Additionally, the use of the phrases "used to," "capable of," and / or "operable to" in one implementation refers to a certain device, logic, hardware, and / or element designed in a manner that enables the device, logic, hardware, and / or element to be used in a specified manner. As above, note that the use of "used to," "capable of," or "operable to" in one implementation refers to a potential state of a device, logic, hardware, and / or element, wherein the device, logic, hardware, and / or element is not in operation, but is designed in a manner that enables the device to be used in a specified manner.

[0234] The value used herein includes any known representation of a number, state, logic state, or binary logic state. Typically, the use of logic levels, logic values, or logic values ​​is also referred to as 1 and 0, which simply represents a binary logic state. For example, 1 refers to a high logic level, and 0 refers to a low logic level. In one implementation, a storage unit, such as a transistor or a flash memory unit, may be able to store a single logic value or multiple logic values. However, other representations of values ​​in a computer system are used. For example, the decimal number ten may also be represented as a binary value 1010 and a hexadecimal letter A. Therefore, a value includes any representation of information that can be stored in a computer system.

[0235] Additionally, states may be represented by values ​​or portions of values. As an example, a first value, such as a logical one, may represent a default or initial state, while a second value, such as a logical zero, may represent a non-default state. Additionally, the terms reset and set in one implementation refer to default and updated values ​​or states, respectively. For example, a default value may include a high logic value, i.e., reset, while an updated value may include a low logic value, i.e., set. Note that any combination of values ​​may be utilized to represent any number of states.

[0236] The implementation of the methods, hardware, software, firmware or code described above may be implemented via instructions or codes that can be executed by a processing element stored on a machine-accessible, machine-readable, computer-accessible or computer-readable medium. Non-transitory machine-accessible / readable media include any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine (e.g., 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 storage media or optical storage media; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; other forms of storage devices for storing information received from transient (propagating) signals (e.g., carrier waves, infrared signals, digital signals); etc., which are to be distinguished from non-transitory media from which information can be received. Instructions for programming logic to perform the implementation of the present disclosure may be stored in a memory in the system, such as DRAM, cache, flash memory or other storage devices. In addition, instructions may be distributed via 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) - but not limited to - floppy disks, optical disks, compact disc read-only memory (CD-ROM), and magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or tangible machine-readable storage devices used when transmitting information through the Internet via electrical, optical, acoustic or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, 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).

[0237] References throughout this specification to "an implementation" or "an implementation" mean that a particular feature, structure, or characteristic described in connection with that implementation is included in at least one implementation of the present disclosure. Thus, the appearances of the phrase "in one implementation" or "in an implementation" throughout this specification do not necessarily all refer to the same implementation. Furthermore, particular features, structures, or characteristics may be combined in any appropriate manner in one or more implementations.

[0238] In the foregoing specification, detailed descriptions are given with reference to specific exemplary implementations. However, it is apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the appended claims. The specification and drawings should therefore be viewed in an illustrative rather than a restrictive sense. Furthermore, the foregoing use of implementations and / or other exemplary language does not necessarily refer to the same implementation or the same example, but may refer to different and distinct implementations, as well as possibly the same implementation.

[0239] Some parts of the detailed description are presented by algorithms and symbolic representations of operations on data bits in computer memory. These algorithmic descriptions and representations are the means used by technical personnel in the field of data processing to most effectively convey the essence of their work to other technical personnel in the field. Algorithms are here and generally conceived as self-consistent sequences of operations leading to desired results. These operations are those requiring physical manipulation of physical quantities. Usually (but not necessarily), these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared and otherwise manipulated. It has been proven that sometimes, mainly for the reason of customary usage, it is convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc. The blocks described herein can be hardware, software, firmware or a combination thereof.

[0240] It should be remembered, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless it is clear from the above discussion that specifically stated otherwise, it should be understood that discussions throughout the specification utilizing terms such as "define," "receive," "determine," "issue," "link," "associate," "obtain," "authenticate," "inhibit," "execute," "request," "communicate," and the like refer to the actions and processes of a computing system or similar electronic computing device that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computing system's registers and memories into other data similarly represented as physical quantities within the computing system's memories or registers or other such information storage, transmission, or display devices.

[0241] The words "example" or "exemplary" are used herein to mean serving as an example, instance or illustration. Any aspect or design described herein as "example" or "exemplary" is not necessarily to be interpreted as being preferred or advantageous over other aspects or designs. Rather, the use of the words "example" or "exemplary" is intended to give concepts in a specific way. As used in this application, 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 natural inclusive replacement. That is, if X includes A; X includes B; or X includes both A and B, then "X includes A or B" is satisfied in any of the foregoing cases. In addition, the article "one" used in this application and the appended claims should generally be interpreted as meaning "one or more", meaning that it is directed to a singular form unless otherwise specified or clear from the context. In addition, the use of the term "an implementation" or "an implementation" or "an implementation" or "an implementation" in various places is not intended to mean the same implementation or implementation, unless described as such. In addition, the terms "first," "second," "third," "fourth," etc. used herein are intended to be used as labels to distinguish different elements and may not necessarily have ordinal meanings according to their numerical numbers.

Claims

1. A processor, comprising: Decode circuitry for decoding a SEAMCALL instruction for a virtual machine monitor (VMM) in a legacy VMX root operating mode; as well as An execution circuit is used to execute an operation corresponding to the SEAMCALL instruction, wherein the operation includes: Exit the virtual machine (VM); transitioning the processor from the legacy VMX root operating mode to a secure arbitration mode (SEAM) VMX root operating mode, wherein SEAM modules are to be hosted in the SEAM VMX root operating mode; Storing the VMM state of the processor in a virtual machine control structure (VMCS); Loading the SEAM module state of the processor from the VMCS; disabling system management interrupts (SMI) and non-maskable interrupts (NMI) in the SEAM VMX root operating mode; and The SEAM module is called.

2. The processor of claim 1, wherein: The execution circuit calls the SEAM module to call the execution of the instruction for creating a trust domain (TD).

3. The processor of claim 1, wherein: The execution circuit calls the SEAM module to call the execution of the instruction for adding a page to the TD.

4. The processor of claim 1, wherein: The execution circuit calls the SEAM module to call the execution of the instruction for entering the TD.

5. The processor of claim 1 , further comprising: A memory storing the SEAM module, the SEAM module including instructions, which when executed by the processor cause the processor to perform operations including creating a TD, adding a page to the TD, and entering the TD.

6. The processor of claim 1, wherein: The execution circuit performs the operation corresponding to the SEAMCALL instruction to indicate the cause of the VM exit as SEAMCALL.

7. The processor of claim 1, further comprising: The range register is used to store information identifying a reserved range of a memory, and the reserved range of the memory is used to store the SEAM module.

8. The processor of claim 1, further comprising: The register is used to store the measurement value of the SEAM module and the security version number (SVN) of the SEAM module.

9. The processor of claim 1, wherein: The SEAM module is trusted by the TD, but the VMM is not trusted by the TD.

10. The processor of claim 1, wherein: The SEAM module is validated by the processor.

11. A system comprising: System memory; a processor coupled to the system memory, the processor comprising: Decoding circuitry for decoding a SEAMCALL instruction for a virtual machine monitor (VMM) in a legacy VMX root operating mode; and An execution circuit, used to execute an operation corresponding to the SEAMCALL instruction, comprising: Exit the virtual machine (VM); transitioning the processor from the legacy VMX root operating mode to a secure arbitration mode (SEAM) VMX root operating mode, wherein SEAM modules are to be hosted in the SEAM VMX root operating mode; Storing the VMM state of the processor in a virtual machine control structure (VMCS); Loading the SEAM module state of the processor from the VMCS; disabling system management interrupts (SMI) and non-maskable interrupts (NMI) in the SEAM VMX root operating mode; and The SEAM module is called.

12. The system of claim 11, further comprising: a range register for storing information identifying a reserved range of a memory, the reserved range of the memory being used to store the SEAM module; as well as Registers for storing the measurement values ​​of the SEAM module and the security version number (SVN) of the SEAM module. 13 . The system of claim 12 , wherein the execution circuit calls the SEAM module to call execution of an instruction for adding a page to a TD.

14. The system of claim 11, wherein: The execution circuit calling the SEAM module is to call the execution of an instruction for creating a trust domain (TD), and wherein the SEAM module is trusted by the TD, but the VMM is not trusted by the TD.

15. The system of claim 14, wherein: The execution circuit calls the SEAM module to call the execution of the instruction for entering the TD.

16. The system of claim 11, further comprising: A memory storing the SEAM module, the SEAM module including instructions, which when executed by the processor cause the processor to perform operations including creating a TD, adding a page to the TD, and entering the TD.

17. The system of claim 16, wherein the execution circuit performs the operation corresponding to the SEAMCALL instruction to indicate the cause of the VM exit as SEAMCALL, and wherein: The SEAM module is validated by the processor.

18. A method comprising: Decodes the SEAMCALL instruction for a virtual machine monitor (VMM) in legacy VMX root operating mode; as well as Execute an operation corresponding to the SEAMCALL instruction, the operation comprising: Exit the virtual machine (VM); transitioning the processor from the legacy VMX root operating mode to a secure arbitration mode (SEAM) VMX root operating mode, wherein SEAM modules are to be hosted in the SEAM VMX root operating mode; Storing the VMM state of the processor in a virtual machine control structure (VMCS); Loading the SEAM module state of the processor from the VMCS; disabling system management interrupts (SMI) and non-maskable interrupts (NMI) in the SEAM VMX root operating mode; and The SEAM module is called.

19. The method of claim 18, further comprising: Information for identifying a reserved range of a memory is stored in a range register, and the reserved range of the memory is used to store the SEAM module.

20. The method of claim 19, wherein: Invoking the SEAM module includes executing instructions to create a trust domain (TD).

21. The method of claim 18, wherein: Calling the SEAM module includes executing instructions to add pages to the TD.

22. The method of claim 21, further comprising: The measured values ​​of the SEAM module and a security version number (SVN) of the SEAM module are stored in a plurality of registers.

23. The method of claim 22, further comprising: The processor validates the SEAM module.

24. The method of claim 23, wherein: Calling the SEAM module includes executing an instruction to enter TD, and further includes: indicating the reason for the VM exit as SEAMCALL.

25. A method comprising: The instruction fetch circuit obtains the SEAMCALL instruction from the code storage device; The decoding circuit decodes the obtained SEAMCALL instruction; The execution circuitry executes a SEAMCALL instruction to cause the logical processor to enter a secure arbitration mode (SEAM) for TDX operations.

26. The method of claim 25, wherein: Entering SEAM will transfer SEAM VMX root mode operation control to the logical processor.

27. The method of claim 25, wherein: The actions performed by the SEAMCALL instruction include storing the VMM state and causing the processor to transition into the SEAM state.

28. An apparatus comprising means for performing the method of any one of claims 25-27.

Images