Method and apparatus for debugging confidential virtual machine of processor in production mode

Abstract

Techniques for debugging a confidential virtual machine of a processor in a production mode are described. In some examples, a hardware processor core is to implement: a trust domain manager to manage one or more hardware isolated virtual machines as respective trust domains of regions having memory protected by respective encryption keys; and a virtual machine monitor that is not allowed to access the protected memory region of the one or more hardware isolated virtual machines; and a memory management circuit coupled between the hardware processor core and the memory, in which a memory dump file is generated in response to the hardware isolated virtual machine, the trust domain manager is configured to encrypt the memory dump file with a debug key to generate an encrypted memory dump file and store the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor, the debug key is different from any of the respective encryption keys.

Description

Background Art

[0001] A processor or a collection of processors executes instructions from an instruction set (e.g., an instruction set architecture (ISA)). An instruction set is the programming-related portion of a computer architecture and generally includes native data types, instructions, register architecture, addressing modes, memory architecture, exception handling, and external input and output (IO). It should be noted that the term instruction may refer to macroinstructions or microinstructions herein, such as instructions provided to a processor for execution, or microinstructions such as instructions decoded by a decoder of a processor from macroinstructions. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0003] Figure 1 A block diagram of a computer system including multiple cores with a trust domain manager, a memory manager circuit, and a storage device including a data structure for a virtual machine debug key (VDK) is illustrated according to an example of the present disclosure.

[0004] Figure 2 A block diagram of a host including a trust domain manager and storage for data structures of a VDK is illustrated according to an example of the present disclosure.

[0005] Figure 3 A block diagram of a host in production mode according to an example of the present disclosure is illustrated, the host including a trust domain manager that does not allow a host virtual machine monitor (VMM) to access (e.g., read) private data of a guest virtual machine (e.g., of a trust domain) from a memory space of a guest virtual machine (e.g., of a trust domain).

[0006] Figure 4 A block diagram of a host computer including a trust domain manager that utilizes one or more VDKs to allow a host virtual machine monitor (VMM) to access (eg, read) private data (eg, of a trust domain) of a guest virtual machine is illustrated according to an example of the present disclosure.

[0007] Figure 5A block diagram of a host according to an example of the present disclosure is illustrated, the host including a trust domain manager that utilizes encrypted shared memory of a virtual machine (eg, a trust domain) to implement VDK provisioning (eg, provisioning an application programming interface (API)) in a secure manner.

[0008] Figure 6 is a flow chart illustrating the operation of a method for provisioning a VDK according to examples of the present disclosure.

[0009] Figure 7 is a flow chart illustrating the operation of a method for encrypting private data of a virtual machine (eg, of a trust domain) via a VDK according to an example of the present disclosure.

[0010] Figure 8 is a flow chart illustrating the operation of a method for removing a VDK according to an example of the present disclosure.

[0011] Fig. 9 is a flow chart illustrating the operation of a method for encrypting and storing private data of a virtual machine (eg, of a trust domain) via a VDK according to an example of the present disclosure.

[0012] Fig.10 is a block diagram of an example trust domain (e.g., a confidential VM) according to the present disclosure that also acts as a debug agent for tenant workloads in the trust domain that is authorized to view debug files and debug images encrypted by a VDK.

[0013] Fig.11 is a block diagram of an example remote debug client (RDC) according to the present disclosure, which is authorized to view debug files from a guest-host VM (e.g., TD) and use a VDK to decrypt an encrypted debug image for decryption by the RDC (e.g., on a system in debug mode).

[0014] Fig.12 is a flow chart illustrating the operation of a method for debugging private data of a virtual machine (eg, of a trust domain) according to examples of the present disclosure.

[0015] Fig.13 An example computing system is illustrated.

[0016] Fig.14 A block diagram illustrating an example processor and / or System on a Chip (SoC) that may have one or more cores and an integrated memory controller.

[0017] Fig.15Ais a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example.

[0018] Fig. 15B is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example.

[0019] Fig.16 An example of execution unit(s) circuitry is shown.

[0020] Fig.17 is a block diagram of a register architecture according to some examples.

[0021] Fig.18 An example of the instruction format is shown.

[0022] Fig.19 Figure 1 shows an example of an addressing information field.

[0023] Fig. 20 An example of the first prefix is ​​illustrated.

[0024] Figure 21A-Figure 21D How to use the diagram Fig. 20 Example of the R, X, and B fields of the first prefix in .

[0025] Figure 22A-22B An example of the second prefix is ​​shown in the figure.

[0026] Fig.23 An example of the third prefix is ​​shown in FIG.

[0027] Fig.24 is a block diagram illustrating converting binary instructions in a source instruction set architecture to binary instructions in a target instruction set architecture using a software instruction converter according to an example. DETAILED DESCRIPTION

[0028] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for debugging a confidential virtual machine (eg, a trust domain) of a processor in production mode.

[0029] In the following description, numerous specific details are set forth. However, it should be understood that examples of the present disclosure may be implemented without these specific details. In other instances, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of the present description.

[0030] References in the specification to "an example", "examples", "examples", etc. indicate that the described examples may include a particular feature, structure, or characteristic, but not every example necessarily includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same example. In addition, when a particular feature, structure, or characteristic is described in conjunction with an example, it is considered within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0031] A (e.g., hardware) processor (e.g., having one or more cores) may execute instructions (e.g., threads of instructions) to operate on data, for example, to perform arithmetic, logical, or other functions. For example, software may request an operation, and a hardware processor (e.g., one or more cores of the hardware processor) may perform the operation in response to the request. Certain operations include accessing one or more memory locations to, for example, store and / or read (e.g., load) data. A system may include multiple cores, for example, where a suitable subset of the cores is in each of a plurality of sockets, for example, in a system on a chip (SoC). Each core (e.g., each processor or each socket) may access a data storage device (e.g., memory). The memory may include volatile memory (e.g., dynamic random-access memory (DRAM)) or (e.g., byte-addressable) persistent (e.g., non-volatile) memory (e.g., non-volatile RAM) (e.g., separate from any system storage device, such as, but not limited to, separate from a hard drive). An example of a persistent memory is a dual in-line memory module (DIMM) (e.g., a non-volatile DIMM) (e.g., a memory module that can be accessed according to the Peripheral Component Interconnect Express (PCIe) standard, for example. Optane TM memory).

[0032] In some examples of computing, a virtual machine (VM) (e.g., a guest machine) is a simulation of a computer system. In some examples, a VM is based on a specific computer architecture and provides the functionality of an underlying physical computer system. Their implementation may involve specialized hardware, firmware, software, or a combination. In a certain example, a virtual machine monitor (VMM) (also referred to as a hypervisor) is a software program that, when executed, enables the creation, management, and control of VM instances, and manages the operation of a virtualized environment on a physical host machine. In some examples, the VMM is the main software behind the virtualized environment and implementation. In some examples, when installed on a host machine (e.g., a processor), the VMM facilitates the creation of VMs, for example, each VM has a separate operating system (OS) and application. The VMM can manage the backend operations of these VMs by allocating necessary computing, memory, storage, and other input / output (IO) resources (such as, but not limited to, an input / output memory management unit (IOMMU) (e.g., an IOMMU circuit)). A VMM may provide a centralized interface for managing the complete operation, status, and availability of VMs installed on a single host machine or spread across different interconnected hosts.

[0033] It may be desirable to maintain security (e.g., confidentiality) of information of a virtual machine from a VMM and / or (one or more) other virtual machines. Some processors (e.g., a system on a chip (SoC) including a processor) utilize their hardware to isolate virtual machines, e.g., where each virtual machine is referred to as a "trust domain" (e.g., a "trusted zone" or a "secure zone"). Some processors support an instruction set architecture (ISA) (e.g., an ISA extension) to implement trust domains. For example, Trust Domain Extensions ( trust domain extension, Trust Domains (TDs) are a set of hardware-isolated virtual machines (VMs) that utilize architectural elements to deploy hardware-isolated virtual machines (VMs) called trust domains (TDs).

[0034] In some examples, a hardware processor (e.g., its trust domain manager) and its ISA isolates the TD VM from the VMM (e.g., hypervisor) and / or other non-TD software (e.g., on a host platform). In some examples, a hardware processor (e.g., its trust domain manager) and its ISA implement a trust domain to enhance confidential computing by helping to protect the trust domain from a wide range of software attacks and reducing the trusted computing base (TCB) of the trust domain. In some examples, a hardware processor (e.g., its trust domain manager) and its ISA enhance cloud tenants' control over data security and protection. In some instances, a hardware processor (e.g., its trust domain manager) and its ISA implement a trust domain (e.g., a trusted virtual machine) to enhance the ability of a cloud-service provider (CSP) to provide managed cloud services without disclosing tenant data to adversaries.

[0035] However, in some examples, privileged system code (e.g., OS, VMM, and / or firmware) has access to memory storing data (e.g., to read and / or write to memory). This is particularly problematic in cases where data should remain private to privileged (e.g., kernel / system level and / or non-user level) system code (e.g., confidential information is in memory for a trust domain). Some examples herein (e.g., examples implementing trust domains) eliminate privileged software from a trusted computing base (TCB) (e.g., a TCB of a TD).

[0036] Some architectures support two modes of operation for enclaves (e.g., trust domains): (1) debug mode, and (2) production (e.g., non-debug) mode. In some examples, production mode enclaves (e.g., trust domains) have full protection provided by the architecture. In some examples, to support enclaves, debug mode enclaves are distinguished from production mode enclaves in one or more of the following ways.

[0037] (i) In some examples, a debug mode enclave is created with the ATTRIBUTES.DEBUG bit set (e.g., where this field appears in the output of the enclave report (e.g., EREPORT) instruction (e.g., REPORT.ATTRIBUTES). In some examples, the debug bit is not measured as part of the build process, so the debug enclave and the production enclave can have the same measurement, for example, in this case, this ensures that the reports generated by activities (e.g., verification) will look the same, which helps to simplify the debugging process.

[0038] (ii) In some examples, the key returned by an enclave get key (e.g., EGETKEY) instruction in a debug enclave is different for the same enclave in debug mode than in production mode, e.g., where data sealed by a production enclave cannot be inspected by a debug enclave (and vice versa), which helps ensure protection of secrets.

[0039] (iii) In some examples, a debugger (e.g. Debug mode enclaves can be debugged using a software guard extensions (SGX) debugger, such as a debugger that does not support SGX and cannot debug enclaves under any circumstances.

[0040] (iv) In some examples, performance counters may be enabled within a debug mode enclave, e.g., where these counters may be used for performance tuning enclaves.

[0041] In some examples, a processor (e.g., core) is used to implement a host virtual machine monitor (host VMM) that acts as a host-to-guest TD, e.g., where the term "host" is used to distinguish between the "host VMM" and future VMMs that may be nested within a trust domain.

[0042] In some examples, a processor (eg, a core) is used to implement a trust domain manager, for example, where the trust domain manager utilizes, for example, a set of ISA extensions (eg, Trust Domain Extensions ( TDX)) is used to manage one or more trust domains (TDs) of virtual machines (VMs) designed as hardware isolation.

[0043] In some examples, a processor (e.g., a core) is used to implement a debugging architecture of a trust domain manager, which includes the following debugging capabilities: (i) debugging on TD, which is used to debug a guest TD using software running inside the TD (e.g., from inside the "guest" side); and / or (ii) debugging outside TD, which is used to debug a guest TD configured in debug mode using software running outside the TD (e.g., from inside the "host" side) (e.g., via a host-side TD outside debugging interface in a deployment environment).

[0044] However, option (2) implies that the VMM is trusted for the TD content. In some examples, the debugging code (e.g., debugging agent) resides inside the guest TD, and it can interact with external entities (e.g., debuggers) via standard input / output (I / O) interfaces. In some examples, the trust domain manager is designed to virtualize the TD debugging capabilities and isolate the TD debugging capabilities from the host VMM and other guest TDs or traditional VMs. In some examples, for example, regardless of the state of the debugging attributes (e.g., ATTRIBUTES.DEBUGTD) of the guest TD, debugging on the TD can be used for production TD or debugging TD. In some examples, the host VMM controls whether the guest TD can use the performance monitoring capabilities of the processor (e.g., using the performance monitoring ISA), which can be controlled, for example, using the performance monitoring attributes (e.g., ATTRIBUTES.PERFMON) bit of the TD, which is, for example, part of the parameters of the trust domain (e.g., TD_PARAMS input to TDH.MNG.INIT 5).

[0045] In some examples, the processor is used to generate a memory dump file (e.g., where the data in the memory dump file is referred to as a memory dump, a core dump, a storage device dump, a crash dump, and / or a system dump). In some examples, the memory dump file includes a recorded state of a working memory of a computer program (e.g., an application and / or an OS) at a particular time, the recorded state being generated, for example, in response to a program crash or otherwise abnormal termination. In some examples, the memory dump file includes a processor state (e.g., including processor registers (e.g., which may include a program counter and a stack pointer)), memory management information, and / or other processor and operating system information (e.g., flags).

[0046] In some examples, the host operating system is allowed to access the memory dump file, but the guest program (e.g., guest application and / or guest OS) is not allowed to access the memory dump file. In some examples, the guest program (e.g., running on a virtual machine (e.g., a trust domain)) sends its request to the VMM, but as described above, in some examples, the VMM is not trusted by the trust domain manager and is therefore not allowed to access the dump file, such as by causing the dump file to be encrypted by a private virtual machine encryption key (e.g., VEK) that the VMM is not allowed to access.

[0047] In some examples, it may be desirable to have TD out-of-band debugging of a guest program (e.g., a guest application and / or a guest operating system (OS)) where, for example, a memory dump is confidential data of the guest program and is thus protected by a corresponding VEK that is not shared with an untrusted VMM. The examples herein relate to methods and circuits that overcome these problems by generating and / or using debug keys (e.g., virtual machine debug keys (VDKs)). The examples herein relate to allowing a VMM to dump and / or access private data and / or memory of a confidential VM (e.g., via a host-to-host interface in production mode) while protecting the confidentiality and integrity of the private data and / or memory of the VM. Thus, the examples herein prevent data leakage, such as confidential data. The examples herein allow a host VMM to dump a guest VM private memory space in a production environment without causing security compromise, such as to facilitate the deployment, debugging, and / or management of guest VMs in confidential computing (CC).

[0048] In some examples, the use of virtual machine (e.g., trust domain) debug keys disclosed herein is an improvement to the operation of the (e.g., computer's) SoC (e.g., processor) itself, because, for example, it allows the SoC (e.g., processor) to prevent data in the virtual machine's (e.g., trust domain's) protected memory from being accessed by undesired entities, but still allows the VMM to access the protected data to perform debugging. As an example, a guest OS operating in a trust domain is not allowed to access a dump file generated in the trust domain (e.g., generated when a guest application running in the trust domain crashes) because when the guest OS requests the VMM to perform the access, it is denied as an untrusted entity. The examples herein allow private data to be encrypted by a dump key (e.g., the dump key is separate / unique from the encryption key of the code and / or other data in the trust domain), and thereby allow the VMM (or another entity) to perform debugging operations on the private data when the VMM (or another entity) is provided with the dump key. Examples herein relate to methods and apparatus for debugging a confidential virtual machine (eg, while in production mode).

[0049] In some examples, confidential computing (CC) uses memory encryption to protect the confidentiality and integrity of guest VMs, such as where the private memory of the target VM is encrypted using a private VM Encryption Key (VEK), and the VEK is managed by a privileged trust domain manager (e.g., a trust module). Trust Domain Extensions ( TDX) and Multi-Key Total Memory Encryption (MKTME) circuits (eg, engines) work together to apply VM memory encryption and introduce a trust module (eg, TDX module) to manage the guest trust domain's (TD's) VEK and other secrets. For example, some The processor includes a Secure Encrypted Virtualization-EncryptedState (SEV-ES) and / or SEV-Secure Nested Paging (SEV-SNP) hardware memory encryption engine (e.g., embedded in a memory controller) to encrypt the VM's memory and use the processor hardware as a trust module to manage the guest SEV's VEK.

[0050] In some CC solutions, the VMM is not trusted, and thus, the trust domain manager does not allow the VMM to access the private memory space of the VM (eg, in production mode) (see, e.g., Figure 3 ) and thereby prevent debugging of the guest VM (e.g., in a production and / or deployed environment as opposed to a deployment and / or manufacturing environment). While such a restriction may be appropriate for production deployments, it is too restrictive for tenant-driven VM debugging. In some examples, guest VM private memory encryption introduces a significant functional regression, where dumping / accessing the memory space of the guest VM from the VMM is an important function for tenants and / or cloud service providers (CSPs) to debug (e.g., dumping a misbehaving VM core file to debug the problem offline).

[0051] Without the ability to dump the guest VM (or view the plaintext of an encrypted dump), debugging guest programs (e.g., guest OS / applications) after production is extremely difficult. Lack of post-production debugging capabilities breaks conventional virtual machine management methods. Examples herein enable confidential guest VM memory space / or data access (e.g., in production mode) while preserving its security, e.g., where Secure Encrypted Virtualization (e.g., SEV / SEV-ES / SEV-SNP), Trusted Execution Technology, Realm Management Extension (RME) or other confidential computing technologies, such functionality is included.

[0052] The examples herein do not rely on a stable guest TD OS and / or do not require TD external debugging to be applied only to deployment environments where the host VM is implicitly trusted, for example, the examples herein can be used in cloud environments where tenants work in production environments where the VMM is not trusted. The examples herein defend against attacks by malicious VMMs, for example, to prevent the VMM from observing the contents of a memory dump file (e.g., unless allowed by a trusted domain manager via a VDK).

[0053] Now turn to Figure 1 , depicts an example system architecture. Figure 1 A block diagram of a computer system according to an example of the present disclosure is illustrated, the computer system including multiple cores 102-0 to 102-N (where N is any positive integer greater than 1, but a single core example may also be utilized) with a trust domain manager (e.g., a single trust domain manager or trust domain managers 101-0 to 101-N distributed in each core), a memory management circuit 114, and a memory 116 including a storage device (e.g., accessible only by the trust domain manager) for a data structure 126 of a virtual machine debug key (VDK). In some examples,

[0054] In some examples, each core includes (e.g., or logically includes) a set of registers, such as register 108-0 for core 102-0, register 108-0 for core 102-N, etc. Register 108 may be, for example, a data register and / or a control register for each core (e.g., or each logical core of a plurality of logical cores of a physical core).

[0055] In some examples, (e.g., each) hardware processor core (e.g., core 102-0) includes: (i) hardware decoder circuit 104-0 for decoding instructions, such as instructions for requesting access to a block (or multiple blocks) of memory (e.g., trust domain memory 124); and / or (ii) hardware execution circuit 106-0 for executing decoded instructions, such as instructions for requesting access to a block (or multiple blocks) of memory.

[0056] The depicted hardware processor core 102-0 includes one or more registers 108-0, such as, for example, general purpose (e.g., data) register(s) 110-0 (e.g., registers RAX 110A, RBX 110B, RCX 110C, RDX 110D, etc.) and / or (optionally) (e.g., capabilities-specific only) control register(s) 112-0 (e.g., registers for controlling use of a VEK and / or VDK).

[0057] In some examples, one or more of cores 102 are coupled to memory 116 via memory management circuitry 118. In some examples, memory management circuitry 118 is used to control access (e.g., access by execution circuitry 106-0) to memory 116 (e.g., addressable memory of memory 116).

[0058] In some examples, memory 116 is a memory local to a hardware processor (e.g., system memory). Memory 116 may be DRAM. In some examples, memory 116 is a memory separate from the hardware memory, such as a memory of a server. Note that the figures herein may not depict all data communication connections. One of ordinary skill in the art will appreciate that this is to avoid obscuring certain details in the figures. Note that a bidirectional arrow in the figures may not require bidirectional communication, for example, it may indicate unidirectional communication (e.g., to or from that component or device). Any or all combinations of communication paths may be utilized in some examples herein.

[0059] The contents of memory 116 may include operating system (OS) and / or virtual machine monitor code 118, user (e.g., program) code 120, non-trusted domain memory 122 (e.g., pages), trusted domain memory 124 (e.g., pages), storage for a data structure 126 of a virtual machine (e.g., trusted domain) debug key (VDK) (e.g., accessible only by a trusted domain manager), storage for a data structure 128 of a virtual machine (e.g., trusted domain) encryption key (VEK) (e.g., accessible only by a trusted domain manager), shared memory 130 for virtual machines (e.g., shared memory for a trusted domain), or any combination of the above. In some examples of computing, a virtual machine (VM) is an emulation of a computer system. In some examples, a VM is based on a specific computer architecture and provides the functionality of an underlying physical computer system. Their implementation may involve specialized hardware, firmware, software, or a combination. In some examples, a virtual machine monitor (VMM) (also referred to as a hypervisor) is a software program that, when executed, enables the creation, management, and control of VM instances and manages the operation of a virtualized environment on a physical host machine. In some examples, the VMM is the main software behind the virtualized environment and implementation. In some examples, when installed on a host machine (e.g., a processor), the VMM facilitates the creation of VMs, for example, each VM has a separate operating system (OS) and application. The VMM can manage the back-end operations of these VMs by allocating necessary computing, memory, storage, and other input / output (IO) resources (such as, but not limited to, an input / output memory management unit (IOMMU)). The VMM can provide a centralized interface for managing the complete operation, status, and availability of VMs installed on a single host machine or distributed across different interconnected hosts. Similarly, an operating system can support multiple processes in separate address spaces defined by their respective paging structures to separate the memory pages of one process from the memory pages of another process.

[0060] In some examples, the hardware initialization manager (non-transitory) storage device 132 stores hardware initialization manager firmware (e.g., or software). In one example, the hardware initialization manager (non-transitory) storage device 132 stores Basic Input / Output System (BIOS) firmware. In another example, the hardware initialization manager (non-transitory) storage device 136 stores Unified Extensible Firmware Interface (UEFI) firmware. In some examples (e.g., triggered by power-on or reboot of the processor), the computer system 100 (e.g., core 102-0) executes the hardware initialization manager firmware (e.g., or software) stored in the hardware initialization manager (non-transitory) storage device 132 to initialize the system 100 for operation, such as to start executing an operating system (OS) and / or initialize and test (e.g., hardware) components of the system 100.

[0061] In some examples, a trusted execution environment (TEE) security manager (e.g., implemented by the trust domain manager 101) is used to: provide an interface to the VMM to allocate memory, processors, and other resources to the trust domain (e.g., the trusted virtual machine), (ii) implement security mechanisms and access controls (e.g., translation tables, etc.) to protect the confidentiality and integrity of the trust domain (e.g., the trusted virtual machine) data and execution state in the host from entities that are not in the trusted computing base of the trust domain (e.g., the trusted virtual machine), (iii) use protocols to manage the security state of the trusted device interface (TDI) to be used by the trust domain (e.g., the trusted virtual machine), (iv) establish / manage IDE encryption keys for the host and schedule key refreshes if necessary. The TSM programs the IDE encryption keys into the host root port and communicates with the DSM to configure the integrity and data encryption (IDE) encryption keys in the device, (v) or any single item or combination of the above items. In some examples, the TEE security manager provides (e.g., also provides) authentication and attestation services, where code and data are measured, and the measurements are sent to a remote entity to prove that the code and data are loaded and run in a TEE on an authenticated machine.

[0062] In some examples, "measurement" of an endpoint (e.g., of code) describes the process of computing a cryptographic hash of a piece of firmware / software or configuration data and linking the cryptographic hash to a trusted execution environment endpoint identity through the use of a digital signature. This allows an authentication initiator to establish the identity and measurement of the firmware / software or configuration running on an authenticated trusted execution environment endpoint.

[0063] In some examples, to help implement security policies for TD, a new mode of the processor called Secure-Arbitration Mode (SEAM) is introduced to host a digitally signed but not necessarily encrypted security service module (e.g., provided by the manufacturer). In some examples, the Trust Domain Manager (TDM) 101 is hosted in a reserved memory space identified by a SEAM-range register (SEAMRR). In some examples, the processor only allows software executed within the SEAM memory range to access the SEAM-memory range, while all other software accesses and direct-memory access (DMA) from the device to the memory range are terminated. In some examples, the SEAM module does not have any memory access rights to other protected memory areas in the platform, including system management mode (SMM) memory or (e.g., Software Guard Extensions (SGX) protected memory.

[0064] In some examples, a trust domain manager (e.g., trust domain managers 101-0 to 101-N) assigns a VEK to each virtual machine (e.g., a trust domain) to maintain confidentiality of each virtual machine. As further discussed herein, in some examples, a trust domain manager (e.g., trust domain managers 101-0 to 101-N) assigns a dump key (e.g., VDK) to a virtual machine (e.g., a trust domain) to allow an entity separate from the trust domain and the trust domain manager (e.g., to allow a VMM) to access a dump file encrypted with the dump key (e.g., VDK), for example, where the VDK is different from the VEK of the trust domain used to generate the dump file.

[0065] In some examples, privileged system code (eg, OS and / or VMM code 124) is used to provide (eg, allocate) memory to the trusted domain manager 101 for use by the trusted domain to insert code and / or data.

[0066] Figure 2A host (eg, Figure 1 100 ), the host computer including a trust domain manager and a storage device for a data structure 126 of a VDK.

[0067] In some examples, the host 200 implements a trusted provisioning agent (TPA) 204 of a trust domain and multiple trust domains, which are shown as trust domain "1" 206-1, trust domain "2" 206-2, and trust domain "3" 206-3, but any single or multiple trust domains may be implemented. In some examples, the host 200 includes a trust domain manager 101 for managing trust domains (e.g., where vertical dashed lines indicate isolation between trust domains, between trust domains and, for example, host OS 118A, VMM 118B, BIOS 136, VMM memory 208 (e.g., non-secure TDM memory), etc.). In some examples, the virtual machine monitor 118B manages (e.g., generates) one or more virtual machines, for example, where the trust domain manager 101 isolates a first virtual machine as a first trust domain from a second (or more) virtual machines as a second (or more) trust domains.

[0068] In some examples, a trust domain has both (e.g., Figure 1 The private memory in the trust domain memory 124 in the ) has (for example, Figure 1 In some examples, the trusted domain manager 101 accesses the data structure 126 for the VDK to manage encryption (and / or decryption) of the dump file via the corresponding VDK.

[0069] As an example, the guest OS 206A-1 operating in the trust domain 206-1 is not allowed to access a dump file generated in the trust domain 206-1 (e.g., generated when the guest application 206B-1 running in the trust domain 206-1 crashes) (e.g., and stored in the trust domain 206-1) because when the guest OS 206A-1 requests the VMM 118B to perform access within the trust domain 206-1, the guest OS 206A-1 is denied because the VMM 118B is an untrusted entity. Instead of adding VMM 118B as a trusted entity, examples herein allow private data to be encrypted with a dump key from a data structure 126 of the VDK (e.g., where the dump key is separate / unique from the encryption key for code and / or other data in the trust domain), and thereby allow VMM 118B (or another entity, such as a trusted entity) to perform debugging operations on the private data when VMM 118B (or another entity, such as a trusted entity), for example, is provided with the dump key via a VDK-encrypted memory dump stored in VMM memory 208 (e.g., and the VMM is provided with the VDK to allow debugging via a VDK-decrypted memory dump). In some examples, for example, an environment (e.g., environment X) is authorized to debug, and thereby the environment is provided with a corresponding VDK for the VDK-encrypted memory dump. Such authorization may include an environment (e.g., a trusted entity, such as a VMM that is not untrusted) having access to a decryption key (e.g., VDK) for decrypting a debug image. Authorization may also include access to hardware, VMM, and / or OS debug modes, such as access to a physical port for debugging, such as, but not limited to, a Joint Test Action Group (JTAG) port, for example, where JTAG is a generic name for those standards standardized as the IEEE 1149.1 Standard Test Access Port and Boundary Scan Architecture (2013). Debugging and testing performed in accordance with the IEEE 1149.1-2013 (JTAG) standard may include testing printed circuit boards (e.g., using boundary scan), integrated circuits (e.g., processors, controllers, etc.), embedded systems, and other components.

[0070] In some examples, the trusted domain manager 101 has write access to untrusted memory (e.g., VMM memory 208), but such access does not make the trusted domain manager 101 untrusted, for example, the trusted domain manager 101 only writes VDK-encrypted dump files to the memory (e.g., VMM memory 208).

[0071] Now turn to Figure 3, for example, in situations where the VMM is not trusted, allowing the VMM access (eg, via the trust domain manager 101) may be undesirable. Figure 3 A block diagram of a host in production mode according to an example of the present disclosure is illustrated, the host including a trust domain manager 101 (e.g., having a memory encryption engine 302) that does not allow a host virtual machine monitor (VMM) 118B (e.g., including memory 208 outside of the trust domain(s)) to access (e.g., read) private data of a guest virtual machine (e.g., of the trust domain) from a memory space 124 of the guest virtual machine (e.g., of the trust domain). In some examples, a VDK logically changes the behavior of a host-host interface. For example, where (e.g., in production mode) if a VDK is not present, the host-host interface is not allowed to access the trust domain memory 124 (e.g., guest VM memory). In some examples (e.g., in debug mode but not production mode), the host-host interface is allowed to access the trust domain memory 124 (e.g., guest VM memory), for example, regardless of whether a VDK is present.

[0072] Figure 4 A block diagram of a host according to an example of the present disclosure is illustrated, the host including a trust domain manager 101 that utilizes one or more VDKs to allow a host virtual machine monitor (VMM) 118B to access (e.g., read) private data (e.g., of a trust domain) of a guest virtual machine (e.g., private data within a trust domain(s) 206). In some examples, the VMM 118B is considered a host (e.g., in contrast to a guest having lower privileges / access on a processor), the trust domain manager 101 is also considered a host, and the trust domains (e.g., confidential VMs protected by corresponding VEKs, see e.g., Figure 4 ) is considered a guest machine (e.g., a guest machine managed by the trust domain manager 101). In some examples, for example, compared to Figure 3 , Figure 4 The illustrated trust domain manager causes a private dump file of a trust domain (e.g., a memory dump file) to be encrypted via a corresponding dump key (e.g., VDK from data structure 126), for example, and the encrypted version (e.g., ciphertext) is stored in a memory (e.g., a memory outside the trust domain where the dump file was generated). Figure 4 In response to the generation of a dump file by code from the first trust domain (TD-1) 206-A (eg, a crash of the code), the trust domain manager 101 generates a dump file via the VDK (eg, Figure 4The dump file is encrypted by using a VDK-1 in the trust domain manager 101 (e.g., but the dump file may need to be decrypted by a system key and the plaintext is then encrypted by the VDK), and the VDK-encrypted dump file is stored in a memory (e.g., the VMM memory 208). In some examples, the trust domain manager 101 includes a buffer 402 for storing the dump file for encryption (or decryption).

[0073] In some examples, the trust domain manager 101 (e.g., the MEE 302 of the trust domain manager 101) performs (i) encryption by taking data (e.g., plaintext) and performing encryption based on a key to generate encrypted data (e.g., ciphertext), and / or (ii) decryption by taking encrypted data (e.g., ciphertext) and performing decryption based on a key to generate the data (e.g., plaintext).

[0074] In some examples, each entry of the data structure 126 (e.g., table) of the VDK includes one or more of the following: an indication 402 of a particular VM (e.g., a trust domain), an indication 406 of a corresponding dump key for the particular VM, and / or an indication 408 of an (optional) protected page range. In some examples, for example, assuming that the TD opts in (and does not opt ​​out) to have the VDK, the trust domain manager is used to populate the VDK field 406 (e.g., and / or the protected page range 408) for the VM (e.g., TD) when the VM (e.g., TD) is created. In some examples, the data structure 126 and / or the data structure 128 of the VEK are only accessible by the trust domain manager 101 (e.g., can only be read and / or written by the trust domain manager 101).

[0075] In some examples, the VDK is used for guest to trusted domain manager (TDM) communications, such as compared to remote debug client (RDC) keys that are used for RDC to guest / TDM communications.

[0076] In some examples, the VDK logically changes the behavior of the host-host interface. For example, where (e.g., in production mode) if the VDK is not present, the host-host interface is not allowed to access the trusted domain memory 124 (e.g., guest VM memory). In some examples (e.g., in debug mode but not production mode), the host-host interface is allowed to access the trusted domain memory 124 (e.g., guest VM memory) regardless of whether the VDK is present.

[0077] Examples herein protect against confidential VM (e.g., TD) data leakage by encrypting the target VM's private (e.g., confidential) data (e.g., for the target VM's private memory) according to a VM debug key (VDK) during debug memory dump / access by a trust domain manager. In some examples, this includes one or more of the following:

[0078] (i) VDK provisioning: In some examples, the VDK of the target VM is provisioned by the guest VM itself to ensure that only the VM owner (e.g., "tenant") can decrypt the encrypted (e.g., memory dump) file. In some examples, a key provisioning application programming interface (API) is introduced into the VM guest-host interface to enable VDK provisioning, deletion and / or updating.

[0079] (ii) VDK data structure 126 (e.g., table): The trust domain manager (e.g., trust module) maintains the VDK within an internal key data structure, e.g., such that only the trust domain manager and the target VM have key access privileges (e.g., and the target VM can only access its VDK and not any other VDK).

[0080] (iii) Debug API extension: Extend the host-host debug API (e.g., read commands (e.g., TDH.MEM.RD of TDX)) to access private data of a non-debuggable guest VM, for example, since the data (eg, passwords) will be encrypted by the VDK, no security compromise is introduced.

[0081] (iv) Intermediate Buffer: In some examples, the VM dump file (e.g., core file) is relatively large, so a bounce memory space (e.g., buffer 402) is included, for example, as an intermediate buffer for guest private data encryption via the VDK during the dump.

[0082] Figure 5 A block diagram of a host according to an example of the present disclosure is illustrated, the host including a trust domain manager 101 that utilizes an encrypted shared memory 502 of virtual machines (e.g., trust domains 206-1 and 206-2) to implement VDK provisioning (e.g., provisioning application programming interfaces (APIs)) in a secure manner. In some examples, when a guest VM (e.g., TD) is created (e.g., started), a tenant (e.g., a guest OS and / or a guest application) calls the VDK provisioning API to provision the VDK to the trust domain manager 101, for example, wherein the process occurs in a guest VM private environment to ensure confidentiality and integrity of the VDK.

[0083] In some examples, the VDK provisioning API is implemented via a guest-host communication interface based on a shared memory 502. For example, since the shared memory is encrypted by a VEK and the VEK is managed by the trust domain manager 101, the trust domain manager 101 can obtain the real API caller (e.g., key owner) via the VEK. In some examples, each entry of the VEK data structure 128 (e.g., table) includes one or more of the following: an indication 504 of a specific VM (e.g., a trust domain), an indication 506 of a corresponding (e.g., non-VDK) encryption key of the specific VM, and / or an indication of an (optional) protected page range.

[0084] In some examples, the trust domain manager is used to store the provisioned (e.g., generated) VDK with an indication of the key owner (e.g., TD) in a VDK data structure 126 (e.g., table). In some examples, a tenant (e.g., guest OS / application) of a VM (e.g., TD) is used to update and / or delete the VDK, for example, via a VDK provisioning API.

[0085] Figure 6 600 of a method for provisioning a VDK according to an example of the present disclosure. Some or all of operation 600 (or other processes described herein, or variations and / or combinations thereof) are configured under the control of a trust domain manager (or other components discussed herein) and / or one or more computer systems (e.g., processors) configured with executable instructions as implemented herein, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, by hardware, or a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program that includes instructions that can be executed by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 600 are performed by the trust domain manager 101 of other figures.

[0086] Operation 600 includes, at box 602, creating a VM (e.g., TD) (e.g., VM booting). Operation 600 further includes, at box 604, supplying a VDK to a trust domain manager, e.g., via a guest-host communication interface. Operation 600 further includes, at box 606, the trust domain manager storing the VDK in a data structure for the VDK (e.g., showing a VM (e.g., TD) to VDK (e.g., TD-debug key, TDDK) mapping). In some examples, there is a VDK for secure communication, e.g., compared to a VDK specifically for encrypting dump images. This can be indicated in data structure 126. For example, there can be a VDK (e.g., symmetric or asymmetric), a VDK-debug (e.g., symmetric or asymmetric), and a key encryption key (KEK) (e.g., an asymmetric cryptographic system such as, but not limited to, RSA). In some examples, if VDK-debug is omitted (eg, for resource-constrained environments), the VDK can be a multi-use key.

[0087] In some examples, the trust domain manager is used to encrypt the private memory of the VM when the VMM accesses the VM private memory via the debug API, see e.g. Figure 7 .

[0088] Figure 7 is a flowchart illustrating operation 700 of a method for encrypting private data of a virtual machine (e.g., of a trust domain) (e.g., a guest VM for a processor in production mode) via a VDK according to an example of the present disclosure. Some or all of operation 700 (or other processes described herein, or variations and / or combinations thereof) are configured under the control of a trust domain manager (or other components discussed herein) and / or one or more computer systems (e.g., processors) configured with executable instructions as implemented herein, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, through hardware, or a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 700 are performed by the trust domain manager 101 of other figures.

[0089] Operation 700 includes: at box 702, the VMM (e.g., via the VMM calling a host debugging API) requests the trust domain manager to access the private memory of the VM (e.g., TD) (e.g., private data from the private memory). In some examples, the request made by the VMM at box 702 is generated in response to a guest program (e.g., guest OS / application) of the VM (e.g., TD) requesting a memory dump (e.g., requesting access to a memory dump file). Operation 700 further includes: at box 704, checking whether the VM (e.g., TD) is in protected mode, for example, where the data of the VM is encrypted in protected mode and not encrypted in unprotected mode. If it is "no" at box 704, operation 700 proceeds to: at box 706, using a debugging method for non-encrypted data; and if it is "yes" at box 704, operation 700 proceeds to: at box 708, the trust domain manager queries the VDK data structure for the target VM (e.g., TD). Operation 700 further includes: at box 710, checking whether there is a corresponding VDK for the VM; and if it is "no", operation 700 proceeds to: at box 712, returning null (or other error indication), such as an error code indicating that "VDK is empty" for the VM; and if it is "yes", operation 700 proceeds to: at box 714, encrypting the private data of the VM (e.g., memory dump) using the VDK; and operation 700 then proceeds to: at box 716, returning the encrypted private data (e.g., by storing the encrypted private data in the VMM memory).

[0090] In some examples, use of a VDK (e.g., a TDDK) allows offline or remote debugging in a secure environment, e.g., a tenant can utilize the VDK of an owned target VM to decrypt encrypted memory (e.g., data from encrypted memory) and use debugging tools on the decrypted data (e.g., to inspect memory space).

[0091] In some examples, the trust domain manager is used to manage the deprovisioning (e.g., removal) of provisioned (e.g., generated) VDKs, for example, from a VDK data structure 126 (e.g., table). In some examples, the trust domain manager defends against attacks (e.g., replay attacks and / or denial-of-service (DoS) attacks) by removing (e.g., deactivating) the corresponding VDK (e.g., and other VM resources) when its VM is destroyed (e.g., deactivated).

[0092] Figure 8800 of a method for removing a VDK according to an example of the present disclosure. Some or all of operation 800 (or other processes described herein, or variations and / or combinations thereof) are configured under the control of a trust domain manager (or other components discussed herein) and / or one or more computer systems (e.g., processors) configured with executable instructions as implemented herein, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, through hardware, or a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program that includes instructions that can be executed by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 800 are performed by the trust domain manager 101 of other figures.

[0093] Operation 800 includes, at block 802, destroying a VM (e.g., TD) (e.g., in response to a corresponding request from its tenant). Operation 800 further includes, at block 804, the trust domain manager clearing (e.g., deleting) the VDK for the VM from a data structure for the VDK (e.g., removing the VM to VDK mapping).

[0094] Fig. 9 is a flowchart illustrating operation 900 of a method for encrypting and storing private data of a virtual machine (e.g., a trust domain) via a VDK according to an example of the present disclosure. Some or all of operation 900 (or other processes described herein, or variations and / or combinations thereof) are configured under the control of a trust domain manager (or other components discussed herein) and / or one or more computer systems (e.g., processors) configured with executable instructions as implemented herein, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, through hardware or a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 900 are performed by a processor core (e.g., a trust domain manager 101 of a processor core) of other figures.

[0095] Operation 900 includes, at block 902, managing, by a trust domain manager of a hardware processor core, one or more hardware-isolated virtual machines as respective trust domains having regions of memory protected by respective encryption keys, the hardware processor core also including a virtual machine monitor that is not permitted to access the protected regions of memory of the one or more hardware-isolated virtual machines. Operation 900 further includes, at block 904, responsive to the hardware-isolated virtual machines generating a memory dump file, encrypting, by the trust domain manager, the memory dump file using a debug key to generate an encrypted memory dump file, the debug key being different from any of the respective encryption keys. Operation 900 also includes, at block 906, storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor.

[0096] In some examples, a memory dump (e.g., a crash dump) is encrypted to an entity that has been set up to receive encrypted crash dumps. In one example, the recipient of the memory dump can be anyone (e.g., any key), but the entity authorized to run the workload is also authorized to debug it. In another example, the example workload may use a trained machine learning (ML) model that contains secrets (e.g., trade secrets), for example, where the ML model is loaned to a VM to process a user's data set, but the ML model is not allowed to be stolen. In this case, a trusted third party can inspect the dump, but must assume the trustee protection of the user data and the service provider's AI model.

[0097] In some examples, routing messages through the VMM is performed in the path that the VM (e.g., TD) messages traverse to reach their destination, but the trust model excludes the VMM from tampering with the memory dump, so the examples in this article allow a VM authorized to debug an image to obtain (e.g., exclusive) access to the image, which is done by encrypting the dump image relative to the VM, for example, a VM-specific KEK wraps the dump image key (e.g., VDK-debug) so that only the VM can decrypt it.

[0098] In some examples, a VM (e.g., a TD) has pages mapped into its memory range so that once a dump is stored in memory, the VM can access the memory. Prior to this, the page may be marked as inaccessible or zero-filled. In some examples, the VMM blocks access, for example, by marking the page as unreadable or by applying a mutex (e.g., a mutex) protection on the page. In some examples, the trust domain manager writes the ciphertext encrypted by the VDK to the memory page in response to a dump (e.g., a crash interrupt). In some examples, when the write is complete, the trust domain manager signals the VMM to inform the VMM to remove the protection on the page, and signals the TD that the dump of the crash is waiting. In some examples, for example, when the TD chooses to join with a memory (e.g., crash) dump, the TD already has a VDK (e.g., a decrypted VDK) because it needs to initially present the VDK (e.g., an encrypted VDK) to the trust domain manager.

[0099] In some examples, the trust domain manager generates the VDK in data structure 126. In some examples, the trust domain manager dynamically transmits the decrypted VDK to the TD, for example, using a symmetric key that is written to a TD memory (e.g., page) that is exclusively accessible to the TD. In some examples, the symmetric key is used to decrypt the dump file, for example, after all other workloads are removed from the system and / or only TDs authorized to enter debug mode are allowed to run. In some examples, for security reasons, the symmetric key is not shared with the TD until after other workloads (e.g., TDs) are removed and the system is in debug mode.

[0100] In some examples, asymmetric keys are supplied. In some examples, the advantage of using asymmetric keys is that if TD uses a hardware security module (HSM) for a transportable key, VMM can map the HSM device to a trust domain manager memory, supply a private key, and then disconnect the device. In some examples, then, before debug mode can be used, HSM can be switched to different (e.g., separate from the production machine) debug machines. In some examples, HSM can be a smart card (e.g., fob), such as but not limited to a common access card (CAC) or a safety element that meets a universal serial bus (USB) standard. In some examples, HSM is a submodule of the rack scale of different server blades / racks that can be switched to be designed for debugging purposes. In some examples, the encrypted dump file can be moved across unprotected buses, rack-scale backplanes, structures, etc. without decryption.

[0101] In some examples, the debugger runs in "debug mode", which is a mode of a processor (e.g., a thread). In some examples, the OS kernel and VMM control the transition to debug mode. Some examples herein allow a trust domain manager to (at least partially) control the transition to debug mode. In one example, setting the VDK is a way to control access to debug mode, for example, if the TD is not authorized to debug, the trust domain manager does not allow registration of the VDK. In some examples, the VMM and OS transitions are controlled by the trust domain manager, for example, by the VMM and OS asking the trust domain manager whether the TD is authorized to enter the (one or more) debug modes they manage.

[0102] In some examples, the VDK (e.g., and the debug interface) is used to protect the guest VM's (e.g., TD's) memory dump file, for example, the VDK is used (e.g., only used) to encrypt a specific address space (e.g., for runtime debugging scenarios).

[0103] In some examples, in production mode, the tenant can read the value of one or more specific variables from the guest VM memory space via the host-host debug interface, for example, where the VDK is used to encrypt the memory space of the target variable instead of the entire memory space. In some examples, in production mode, the tenant can set (e.g., write) the value of some variables via the host-host debug interface, for example, where the content to be written is encrypted using the VDK in the tenant's secure environment (e.g., the trust module will decrypt the encrypted content and then set it to the (one or more) target variables).

[0104] Fig.10 is a block diagram of an example trust domain 206-1 (e.g., a confidential VM) according to the present disclosure, which also operates as a debugging agent for tenant workloads in the trust domain 206-1 (e.g., of the compute node 1010) (e.g., in the security environment of Tenant 1), authorized to view debug files 1006 and debug images encrypted by a VDK (e.g., VDK-1 for VM1) (e.g., on a system in debug mode).

[0105] In some examples, if the VDK for a VM (e.g., TD) is symmetric, the VDK (e.g., VDK-1 1004 for TD-1's VDK-encrypted private memory 1006) is known to both the guest-host VM (e.g., TD) and the trust domain manager (TDM) 101.

[0106] There are multiple ways to provision the symmetric key. (A) copy the symmetric key into a guest-host VM (e.g., TD) memory page that is shared exclusively between the guest-host VM (e.g., TD) and TDM, or (B) rely on provisioning keys (e.g., key encryption key (KEK)), where the symmetric key is wrapped by the KEK public key and decrypted by the private KEK. For example, the guest or the TDM can have the private key, and whichever has the private key is the one that does the decryption, and the other side does the encryption.

[0107] Fig.11 1 is a block diagram of an example remote debugging client (RDC) 1102 (e.g., in a secure environment of Tenant 1) (e.g., of a compute node 1110, for example, and a debugging network agent 1108 running in a host) (e.g., where the debugging network agent 1108 is used to forward an encrypted debugging key 1112 (e.g., VDK) from a TDM) according to the present disclosure, the remote debugging client (RDC) 1102 being authorized to view a debugging file 1106 from a guest-host VM (e.g., TD) and to decrypt an encrypted debugging image using the VDK used by the RDC 1102 for decryption (e.g., on a system in debug mode).

[0108] In some examples, as a prerequisite for RDC debugging, the RDC 1102 generates a debug image key encryption key (KEK) key pair, where a private KEK (e.g., KEK-RDC-PRIV 1104) is used to decrypt the debug image encryption key (e.g., VDK 406), and a public KEK (e.g., KEK-RDC-PUB 410) is used by the trust domain manager 101 to encrypt the debug image encryption key (e.g., VDK 406). For example, if the debug image encryption key 406 (e.g., VDK-1) for the VM (e.g., TD) is symmetric, the private KEK key 1104 is assumed to be generated on the RDC 1102, and the public KEK key 410 is supplied to the TDM 101. In some examples, the KEK public key 410 is used to encrypt the debug image encryption key VDK 406 (e.g., VDK-1 for TD-1), and the debug image encryption key VDK 406 (e.g., VDK-1 for TD-1) is further used to encrypt the debug image. In some examples, the RDC 1102 can encrypt the debug image using the RDC private KEK 1104 (e.g., Fig.11The encrypted debug image is decrypted using VDK 406 after unwrapping VDK 406 with KEK-1-RDC-PRIV in (e.g., since the KEK-1-RDC-PRIV key only exists on RDC 1102, only that RDC can access the debug image). In some examples, the VDK is a symmetric key, so it is known to the Trust Domain Manager (TDM) 101 and securely shared with designated debug clients (e.g., RDC 1102 and TD-1 206-1).

[0109] There are multiple ways to share the symmetric VDK 406. (A) Copy the symmetric VDK 406 into a guest-host VM 206-1 (e.g., TD) memory page that is shared exclusively between the guest-host VM (e.g., TD) and TDM (101), or (B) rely on a provisioning key (e.g., a key encryption key (KEK) (e.g., 410 or 412)), where the symmetric key is wrapped by the KEK public key and decrypted by the private KEK. For example, the guest or the TDM can have the private key, and whichever has the private key is the one that does the decryption, and the other side does the encryption.

[0110] In some examples (e.g., if RDC is used), an asymmetric KEK key pair needs to be generated (e.g., KEK-1-RDC-PUB public key and KEK-1-RDC-PRIV key, as a key pair for TD-1), and then the public key is provisioned to TDM 101. In some examples, the guest-host VM (e.g., TD) should approve the possibility of RDC debugging the entity. In some examples, the public KEK (e.g., 410 or 412) is securely provisioned to TDM 101 over a secure channel, such as, but not limited to, the Distributed Manageability Task Force (DMTF) Security Protocol and Data Model (SPDM) protocol or the Internet Engineering Task Force (IETF) Transport Layer Security (TLS) protocol applied to path 1114 connecting VM 206-1 to data structure 126 (e.g., TDM key table) or applied to path 1113 connecting RDC 1102 to TD-1 206-1. In some examples, the public KEK 410 is first securely provisioned to the guest-host VM (e.g., TD) (for approval), then forwarded to the TDM (e.g., they establish a TLS session before doing meaningful work in the guest-host VM (e.g., TD), which then provisions both the VDK and KEK-PUB 410 (e.g., in data structure 126) into the TDM.

[0111] In some examples, when the debug image is generated, the TDM may choose to encrypt the debug image using VDK 406 or deliver the debug image over a secure channel (such as, but not limited to, SPDM or TLS). In some examples, the TDM may choose to wrap the VDK with a KEK (410 or 412, or both) and deliver the encrypted debug image 1106 and the wrapped VDK image 1112 to the RDC, for example, over an unsecure channel. A policy may be configured to address what action the TDM should take.

[0112] In some examples, hardware underlying (e.g., "implementing") a guest-host VM (e.g., TD) then transitions into debug mode, e.g., thereby causing hardware access to a debug (e.g., JTAG) port. In some examples, as a prerequisite to entering debug mode, any other guest VMs (e.g., not experiencing a failure) have migrated off the platform. In some embodiments, the operations include: (1) fault detection in the guest-host VM (e.g., TD), (2) encryption of the guest-host VM (e.g., TD) debug image, (3) migration of other VMs to a second / peer computer, (4) a decision to debug on the guest-host VM or on the RDC, (5) setting up a connection to the RDC, (6) placing the first computer in debug mode, (7) signaling the RDC to begin debugging, (8) the RDC decrypting the debug image using the KEK private key, and then (9) the RDC accessing (one or more) (e.g., JTAG) ports, etc.

[0113] In some examples, the hardware of the RDC 102 is used to debug a debug image, such as where the RDC hardware enters a debug mode, thereby causing hardware access to a debug (eg, JTAG) port, etc.

[0114] In some examples, some of the guest-host VM (e.g., TD) pages may be kept confidential (e.g., omitted from the debug image). In some examples, the guest-host VM (e.g., TD) tenant may locate application-specific secrets and privacy-sensitive data in one or more of the "unrestricted" pages, for example, and if a failure occurs that causes the debug image, the "unrestricted" pages may be excluded.

[0115] In some examples, a policy authorizes an "unrestricted" page to be included in a debug image for a local debug client (LDC), while remaining unrestricted for RDC, e.g., where the RDC may be provided by a third party that is untrusted with knowledge of secret and privacy-sensitive data, while the guest-host VM (e.g., TD) already knows such information.

[0116] Fig.121 is a flowchart illustrating operation 1200 of a method for debugging private data of a virtual machine (e.g., a trust domain) according to an example of the present disclosure. Some or all of operation 1200 (or other processes described herein, or variations and / or combinations thereof) are configured under the control of a trust domain manager (or other components discussed herein) and / or one or more computer systems (e.g., processors) configured with executable instructions as implemented herein, and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, through hardware, or a combination thereof. The code is stored on a computer-readable storage medium, for example, in the form of a computer program including instructions that can be executed by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 1200 are performed by the trust domain manager 101 of other figures.

[0117] Operation 1200 includes: at 1202, the tenant detects a guest VM (e.g., TD) failure. Operation 1200 further includes: at box 1204, checking whether the guest VM (e.g., TD) is debugged in a remote debugging client (RDC) or in a guest VM (e.g., TD). If yes (to be debugged in RDC), proceed to: at box 1206, querying a debug key (e.g., VDK) from the host / VMM of the computing node. Operation 1200 further includes: at box 1208, accessing the encrypted VDK and decrypting it using the private key of RDC (e.g., KEK-PRIV). Operation 1200 further includes: at box 1210, reading the encrypted memory space of the guest VM (e.g., TD), such as a static core file or a specific memory address. Operation 1200 further includes: at box 1212, decrypting the memory space using the decrypted VDK. Operation 1200 further includes: at box 1214, using a debugging tool (e.g., GDM for Strace to check the value) on the decrypted data. If no (debugging in a guest VM (e.g., TD)), proceed to: at box 1216, causing the tenant to start a new confidential VM, such as a debug VM (D-VM). Operation 1200 further includes: at box 1218, reading the encrypted memory space of the failed VM from the host agent to the D-VM. Operation 1200 further includes: at box 1220, decrypting the memory space using the VDK. Operation 1200 further includes: at box 1222, using a debugging tool (e.g., GDM for Strace to check the value) on the decrypted data.

[0118] Exemplary architectures, systems, etc. that may be used in the above are described in detail below. Exemplary instruction formats that may cause any of the operations herein are described in detail below.

[0119] At least some examples of the disclosed technology can be described according to the following examples: Example 1. A device comprising: A hardware processor core that implements: a trust domain manager for managing one or more hardware isolated virtual machines as respective trust domains having memory regions protected by respective encryption keys, and a virtual machine monitor that is not permitted to access protected memory regions of one or more hardware isolated virtual machines; and a memory management circuit coupled between the hardware processor core and the memory, In which, in response to a hardware-isolated virtual machine generating a memory dump file, the trust domain manager is used to encrypt the memory dump file using a debug key to generate an encrypted memory dump file and store the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor, and the debug key is different from any encryption key in the corresponding encryption keys. Example 2. The apparatus of Example 1, wherein the trust domain manager is configured to: in response to a request to create a hardware isolated virtual machine, generate a debug key and store the debug key in a data structure of the trust domain manager. Example 3. The apparatus of Example 2, wherein, for each hardware isolated virtual machine of the plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping. Example 4. The apparatus of Example 2, wherein the trust domain manager is to remove the debug key from the trust domain manager's data structure in response to a request for a virtual machine that violates hardware isolation. Example 5. The apparatus of Example 1, wherein the trust domain manager is configured to, in response to the hardware-isolated virtual machine generating a memory dump file, perform: checking, in a data structure including a mapping of debug keys to hardware isolated virtual machines, whether a debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; and If the debug key does not exist in the data structure, an error indication is returned. Example 6. The apparatus of Example 1, wherein the trust domain manager is configured to: generate a debug key in response to a request to create a hardware-isolated virtual machine; and store the debug key in a data structure of the trust domain manager when the hardware processor core is in production mode. Example 7. The apparatus of Example 1, wherein the trust domain manager is configured to allow only a virtual machine isolated by the trust domain manager and the hardware that generated the memory dump file to access the debug key. Example 8. The apparatus of any of Examples 1-7, wherein the hardware isolated virtual machine is configured to generate a memory dump file in response to a crash of a non-operating system application in the hardware isolated virtual machine. Example 9. A method comprising: managing, by a trust domain manager of a hardware processor core, one or more hardware isolated virtual machines as respective trust domains having regions of memory protected by respective cryptographic keys, the hardware processor core also including a virtual machine monitor that is not permitted to access the protected memory regions of the one or more hardware isolated virtual machines; In response to the hardware isolated virtual machine generating a memory dump file, encrypting, by the trust domain manager, the memory dump file using a debug key to generate an encrypted memory dump file, the debug key being different from any of the corresponding encryption keys; and The encrypted memory dump file is stored in a portion of memory accessible by a virtual machine monitor. Example 10. The method as described in Example 9 further comprises: In response to a request to create a hardware isolated virtual machine, generating, by the trust domain manager, a debug key; and The debug key is stored in a data structure of the trust domain manager. Example 11. The method of Example 10, wherein, for each hardware isolated virtual machine of the plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping. Example 12. The method of Example 10, further comprising removing, by the trust domain manager, the debug key from a data structure of the trust domain manager in response to a request to the virtual machine to violate hardware isolation. Example 13. The method of Example 9 further comprises: in response to the hardware-isolated virtual machine generating a memory dump file, the trust domain manager performing: checking, in a data structure including a mapping of debug keys to hardware isolated virtual machines, whether a debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; and If the debug key does not exist in the data structure, an error indication is returned. Example 14. The method of Example 9 further comprises: In response to a request to create a hardware isolated virtual machine, generating, by the trust domain manager, a debug key; and When the hardware processor core is in production mode, the debug keys are stored in a data structure of the trust domain manager. Example 15. The method of Example 9, further comprising: allowing, by the trust domain manager, only a virtual machine isolated by the trust domain manager and the hardware that generated the memory dump file to access the debug key. Example 16. The method of any of Examples 9-15, further comprising: in response to a non-operating system application crashing in the hardware isolated virtual machine, generating a memory dump file by the hardware isolated virtual machine. Example 17. An apparatus comprising: Memory; A hardware processor core that implements: a trust domain manager for managing one or more hardware isolated virtual machines as respective trust domains having regions of memory protected by respective encryption keys, and a virtual machine monitor that is not permitted to access protected memory regions of one or more hardware isolated virtual machines; and a memory management circuit coupled between the hardware processor core and the memory, In which, in response to a hardware-isolated virtual machine generating a memory dump file, the trust domain manager is used to encrypt the memory dump file using a debug key to generate an encrypted memory dump file and store the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor, and the debug key is different from any encryption key in the corresponding encryption keys. Example 18. The apparatus of Example 17, wherein the trust domain manager is to: in response to a request to create a hardware isolated virtual machine, generate a debug key and store the debug key in a data structure of the trust domain manager. Example 19. The apparatus of Example 18, wherein, for each hardware isolated virtual machine of the plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping. Example 20. The apparatus of Example 18, wherein the trust domain manager is to remove the debug key from the trust domain manager's data structure in response to a request to the virtual machine to violate hardware isolation. Example 21. The apparatus of Example 17, wherein the trust domain manager is configured to, in response to the hardware isolated virtual machine generating a memory dump file, perform: checking, in a data structure including a mapping of debug keys to hardware isolated virtual machines, whether a debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; and If the debug key does not exist in the data structure, an error indication is returned. Example 22. The apparatus of Example 17, wherein the trust domain manager is configured to: generate a debug key in response to a request to create a hardware isolated virtual machine; and store the debug key in a data structure of the trust domain manager when the hardware processor core is in production mode. Example 23. The apparatus of Example 17, wherein the trust domain manager is to allow only a virtual machine isolated by the trust domain manager and the hardware that generated the memory dump file to access the debug key. Example 24. The apparatus of any of Examples 17-23, wherein the hardware isolated virtual machine is to generate a memory dump file in response to a crash of a non-operating system application in the hardware isolated virtual machine. Example computer architecture.

[0120] An example computer architecture is described in detail below. It is known in the art for laptops, desktop computers, and handheld personal computers.

[0121] Other system designs and configurations of personal computers (PCs), personal digital assistants, engineering workstations, servers, disaggregated servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (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 short, various systems or electronic devices that can contain the processors and / or other execution logic disclosed herein are generally suitable.

[0122] Fig.13An example computing system is illustrated. Multiprocessor system 1300 is an interfaced system and includes multiple processors or cores, including a first processor 1370 and a second processor 1380 coupled via an interface 1350 (e.g., a point-to-point (PP) interconnect, a fabric, and / or a bus). In some examples, first processor 1370 and second processor 1380 are isomorphic. In some examples, first processor 1370 and second processor 1380 are heterogeneous. Although example system 1300 is shown as having two processors, the system may have three or more processors, or may be a single processor system. In some embodiments, the computing system is a system on a chip (SoC).

[0123] Processors 1370 and 1380 are shown as including integrated memory controller (IMC) circuits 1372 and 1382, respectively. Processor 1370 also includes interface circuits 1376 and 1378; similarly, second processor 1380 includes interface circuits 1386 and 1388. Processors 1370, 1380 may exchange information via interface 1350 using interface circuits 1378, 1388. IMCs 1372 and 1382 couple processors 1370, 1380 to respective memories, namely memory 1332 and memory 1334, which may be part of the main memory locally attached to the respective processors.

[0124] Processors 1370, 1380 can each utilize interface circuits 1376, 1394, 1386, 1398 to exchange information with a network interface (NW I / F) 1390 via respective interfaces 1352, 1354. Network interface 1390 (e.g., one or more of an interconnect, bus, and / or structure, a chipset in some examples) can optionally exchange information with a coprocessor 1338 via interface circuit 1392. In some examples, coprocessor 1338 is a special-purpose processor, such as a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural-network processing unit (NPU), an embedded processor, and the like.

[0125] A shared cache (not shown) may be included in either processor 1370, 1380, or may be external to both processors but connected to the processors via an interface (e.g., a PP interconnect) such that if a processor is placed in a low power mode, local cache information of either or both processors may also be stored in the shared cache.

[0126] The network interface 1390 can be coupled to the first interface 1316 via the interface circuit 1396. In some examples, the first interface 1316 can be an interface such as a Peripheral Component Interconnect (PCI) interconnect, a PCI Express interconnect, or another I / O interconnect. In some examples, the first interface 1316 is coupled to a power control unit (PCU) 1317, which can include circuits, software, and / or firmware to perform power management operations with respect to the processors 1370, 1380, and / or the coprocessor 1338. The PCU 1317 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 1317 also provides control information to control the generated operating voltage. In various examples, the PCU 1317 can include various power management logic units (circuits) to perform hardware-based power management. Such power management may be entirely processor controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0127] PCU 1317 is illustrated as existing as logic separate from processor 1370 and / or processor 1380. In other cases, PCU 1317 may execute on a given one or more of the cores (not shown) of processor 1370 or 1380. In some cases, PCU 1317 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other examples, the power management operations to be performed by PCU 1317 may be implemented external to the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other examples, the power management operations to be performed by PCU 1317 may be implemented within BIOS or other system software.

[0128] Various I / O devices 1314 and a bus bridge 1318 can be coupled to the first interface 1316, and the bus bridge 1318 couples the first interface 1316 to the second interface 1320. In some examples, (one or more) additional processors 1315 are coupled to the first interface 1316, such as a coprocessor, a high-throughput many integrated core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor. In some examples, the second interface 1320 can be a low pin count (LPC) interface. Various devices can be coupled to the second interface 1320, including, for example, a keyboard and / or mouse 1322, a communication device 1327, and a storage circuit 1328. Storage circuit 1328 may be one or more non-transitory machine-readable storage media described below, such as a disk drive or other mass storage device, which in some examples may include instructions / code and data 1330 and may implement storage 1328. Additionally, audio I / O 1324 may be coupled to second interface 1320. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 1300 may implement a multi-drop interface or other such architecture rather than a point-to-point architecture.

[0129] Example core architectures, processors, and computer architectures.

[0130] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general-purpose in-order cores for general-purpose computing purposes; 2) high-performance general-purpose out-of-order cores for general-purpose computing purposes; 3) special-purpose cores, mainly for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU including one or more general-purpose in-order cores for general-purpose computing purposes and / or one or more general-purpose out-of-order cores for general-purpose computing purposes; and 2) a coprocessor including one or more special-purpose cores mainly for graphics and / or scientific (throughput) computing purposes. These different processors result in different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies in the same package as the CPU; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip (SoCs), which may include the coprocessors described above and additional functionality on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s). An example core architecture is described next, followed by a description of an example processor and computer architecture.

[0131] Fig.14 A block diagram of an example processor and / or SoC 1400 is illustrated, which may have one or more cores and have an integrated memory controller. The processor 1400 illustrated in solid line boxes has a single core 1402A, a system agent unit circuit 1410, and a set of one or more interface controller unit circuits 1416, while the optionally added dashed line boxes illustrate an alternative processor 1400 as having multiple cores 1402A-N, a set of one or more integrated memory control unit circuits 1414 in the system agent unit circuit 1410, dedicated logic 1408, and a set of one or more interface controller unit circuits 1416. Note that the processor 1400 may be Fig.13 One of the processors 1370 or 1380 or the coprocessors 1338 or 1315.

[0132] Thus, different implementations of processor 1400 may include: 1) a CPU, where the dedicated logic 1408 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 1402A-N are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 1402A-N are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 1402A-N are a large number of general purpose in-order cores. Thus, processor 1400 may be a general purpose processor, a coprocessor, or a special purpose processor, such as a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1400 may be part of one or more substrates and / or may be implemented on one or more substrates using any of a variety of process technologies, such as complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0133] The memory hierarchy includes one or more levels of cache unit circuits 1404A-N within the cores 1402A-N, a set of one or more shared cache unit circuits 1406, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 1414. The set of one or more shared cache unit circuits 1406 may include one or more intermediate level caches, such as level 2 (L2), level 3 (L3), level 4 (4), or other level caches, such as last level cache (LLC), and / or combinations thereof. While in some examples an interface network circuit 1412 (e.g., a ring interconnect) provides an interface to the dedicated logic 1408 (e.g., integrated graphics logic), the set of shared cache unit circuits 1406, and the system agent unit circuit 1410, alternative examples use any number of well-known techniques to provide interfaces to these units. In some examples, coherency is maintained between one or more circuits in the shared cache unit circuits 1406 and the cores 1402A-N. In some examples, interface controller unit circuit 1416 couples the cores 1402 to one or more other devices 1418, such as one or more I / O devices, storage, one or more communication devices (e.g., wireless network, wired network, etc.), and the like.

[0134] In some examples, one or more of the cores 1402A-N have multi-threading capabilities. The system agent unit circuit 1410 includes those components that coordinate and operate the cores 1402A-N. The system agent unit circuit 1410 may include, for example, a power control unit (PCU) circuit and / or a display unit circuit (not shown). The PCU may be (or may include) logic and components required to adjust the power state of the cores 1402A-N and / or the dedicated logic 1408 (e.g., integrated graphics logic). The display unit circuit is used to drive one or more externally connected displays.

[0135] The cores 1402A-N may be homogeneous with respect to instruction set architecture (ISA). Alternatively, the cores 1402A-N may be heterogeneous with respect to ISA; that is, a subset of the cores 1402A-N may be capable of executing one ISA, while other cores may be capable of executing only a subset of the ISA or may be capable of executing another ISA.

[0136] Example core architectures—in-order and out-of-order core block diagrams.

[0137] Fig.15A The block diagram of illustrates both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to some examples. Fig. 15B The block diagram of illustrates both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor, according to an example. Fig.15A The solid line boxes in -B illustrate the in-order pipeline and in-order core, while the optionally added dashed line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0138] exist Fig.15A , the processor pipeline 1500 includes a fetch stage 1502, an optional length decode stage 1504, a decode stage 1506, an optional allocation (Alloc) stage 1508, an optional rename stage 1510, a dispatch (also called dispatch or issue) stage 1512, an optional register read / memory read stage 1514, an execute stage 1516, a write back / memory write stage 1518, an optional exception handling stage 1522, and an optional commit stage 1524. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 1502, one or more instructions are fetched from the instruction memory, and during the decode stage 1506, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In one example, the decode stage 1506 and the register read / memory read stage 1514 may be combined into one pipeline stage. In one example, during the execution stage 1516, decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0139] As an example, Fig. 15BAn example register renaming, out-of-order issue / execution architecture core may implement pipeline 1500 in the following manner: 1) instruction fetch circuitry 1538 performs fetch and length decode stages 1502 and 1504; 2) decode circuitry 1540 performs decode stage 1506; 3) rename / allocator unit circuitry 1552 performs allocate stage 1508 and rename stage 1510; 4) (one or more) scheduler circuitry 1556 performs schedule stage 1512; 5) (one or more) physical register file circuitry 1558 and memory unit circuitry 1570 perform register read / memory read stage 1514; (one or more) execution clusters 1560 perform execute stage 1516; 6) memory unit circuitry 1570 and (one or more) physical register file circuitry 1558 perform write back / memory write stage 1518; 7) various circuits may be involved in exception handling stage 1522; and 8) retirement unit circuitry 1554 and (one or more) physical register file circuitry 1558 perform commit stage 1524.

[0140] Fig. 15B Processor core 1590 is shown to include front end unit circuit 1530 coupled to execution engine unit circuit 1550, and both are coupled to memory unit circuit 1570. Core 1590 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, core 1590 can be a special purpose core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.

[0141] The front end unit circuit 1530 may include a branch prediction circuit 1532 coupled to an instruction cache circuit 1534 coupled to an instruction translation lookaside buffer (TLB) 1536 coupled to an instruction fetch circuit 1538 coupled to a decode circuit 1540. In one example, the instruction cache circuit 1534 is included in the memory unit circuit 1570 instead of the front end circuit 1530. The decode circuit 1540 (or decoder) may 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 decode circuit 1540 may also include an address generation unit (AGU, not shown) circuit. In one example, the AGU uses the forwarded register port to generate the LSU address and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode circuit 1540 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read only memory (ROM), and the like. In one example, the core 1590 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode circuit 1540 or otherwise within the front end circuit 1530). In one example, the decode circuit 1540 includes a micro-op or operation cache (not shown) to save / cache decoded operations, micro-tags, or micro-operations generated during decoding or other stages of the processor pipeline 1500. The decode circuit 1540 may be coupled to the rename / allocator unit circuit 1552 in the execution engine circuit 1550.

[0142] The execution engine circuit 1550 includes a rename / allocator unit circuit 1552, which is coupled to a retirement unit circuit 1554 and a set of one or more scheduler circuits 1556. The scheduler circuit 1556 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit(s) 1556 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit(s) 1556 is coupled to the physical register file(s) circuit(s) 1558. Each of the physical register file(s) circuit(s) 1558 represents one or more physical register files, 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, status (e.g., instruction pointers, i.e., the address of the next instruction to be executed), and the like. In one example, the (one or more) physical register file circuits 1558 include vector register unit circuits, write mask register unit circuits, and scalar register unit circuits. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The (one or more) physical register file circuits 1558 are coupled to the retirement unit circuit 1554 (also called the retirement queue) to demonstrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROB) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and pools of registers; etc.). The retirement unit circuit 1554 and the (one or more) physical register file circuits 1558 are coupled to (one or more) execution clusters 1560. The (one or more) execution clusters 1560 include a set of one or more execution unit circuits 1562 and a set of one or more memory access circuits 1564. The execution unit circuit(s) 1562 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuit(s) 1556, physical register file circuit(s) 1558, and execution cluster(s) 1560 are shown as possibly multiple because some examples create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuit(s), physical register file circuit(s), and / or execution cluster—and in the case of a separate memory access pipeline, only the execution cluster of that pipeline has memory access unit circuit(s) 1564 in some examples of the implementation). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0143] In some examples, the execution engine unit circuit 1550 can perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AMB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0144] A set of memory access circuits 1564 are coupled to the memory cell circuit 1570, which includes a data TLB circuit 1572, which is coupled to a data cache circuit 1574, which is coupled to a level 2 (L2) cache circuit 1576. In one example, the memory access circuit 1564 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 1572 in the memory cell circuit 1570. The instruction cache circuit 1534 is further coupled to the level 2 (L2) cache circuit 1576 in the memory cell circuit 1570. In one example, the instruction cache 1534 and the data cache 1574 are combined into a single instruction and data cache in the L2 cache circuit 1576, a level 3 (L3) cache circuit (not shown), and / or a main memory (not shown). The L2 cache circuit 1576 is coupled to one or more other levels of cache and ultimately to the main memory.

[0145] Core 1590 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added with newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions, such as NEON)) that include the instruction(s) described herein. In one example, core 1590 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), allowing operations used by many multimedia applications to be performed using packed data.

[0146] Example execution unit circuit(s).

[0147] Fig.16 An example of execution unit circuit(s) is shown, for example Fig. 15B (One or more) execution unit circuits 1562. As shown, (one or more) execution unit circuits 1562 may include one or more ALU circuits 1601, optional vector / single instruction multiple data (single instruction multiple data, SIMD) circuits 1603, load / store circuits 1605, branch / jump circuits 1607, and / or floating-point unit (FPU) circuits 1609. ALU circuits 1601 perform integer arithmetic and / or Boolean operations. Vector / SIMD circuits 1603 perform vector / SIMD operations on packed data (e.g., SIMD / vector registers). Load / store circuits 1605 execute load and store instructions to load data from memory into registers, or store data from registers to memory. Load / store circuits 1605 may also generate addresses. Branch / jump circuits 1607 cause branches or jumps to a certain memory address depending on the instruction. FPU circuits 1609 perform floating-point arithmetic. The width of execution unit circuit(s) 1562 varies depending on the example and may range, for example, from 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0148] Example register architecture.

[0149] Fig.171 is a block diagram of a register architecture 1700 according to some examples. As shown, the register architecture 1700 includes a vector / SIMD register 1710, whose width varies from 128 bits to 1024 bits. In some examples, the vector / SIMD register 1710 is physically 512 bits, and only some low-order bits are used depending on the mapping. For example, in some examples, the vector / SIMD register 1710 is a 512-bit ZMM register: the low-order 256 bits are used for the YMM register, and the low-order 128 bits are used for the XMM register. Therefore, there is an overlay of registers. In some examples, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length. Scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either maintained as the same as before the instruction, or are zeroed, depending on the example.

[0150] In some examples, the register architecture 1700 includes a write mask / predicate register 1715. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 1715 can allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 1715 corresponds to a data element position at the destination. In other examples, the write mask / predicate register 1715 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0151] The register architecture 1700 includes a plurality of general purpose registers 1725. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some examples, these registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0152] In some examples, register architecture 1700 includes a scalar floating-point (FP) register file 1745, which is used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set architecture extensions, or as an MMX register to perform operations on 64-bit packed integer data, and to store operands for some operations performed between MMX and XMM registers.

[0153] One or more flag registers 1740 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 1740 can store condition code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 1740 are referred to as program status and control registers.

[0154] Segment registers 1720 contain segment points for accessing memory. In some examples, these registers are referred to by the names CS, DS, SS, ES, FS, and GS.

[0155] Machine-specific registers (MSRs) 1735 control and report processor performance. Most MSRs 1735 handle system-related functions and are not accessible to applications. Machine check registers 1760 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0156] One or more instruction pointer registers 1730 store instruction pointer values. Control register(s) 1755 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processor 1370, 1380, 1338, 1315, and / or 1400) and the characteristics of the currently executing task. Debug registers 1750 control and allow monitoring of debug operations of the processor or core.

[0157] Memory (mem) management registers 1765 specify the location of data structures used in protected mode memory management. These registers may include global descriptor table registers (GDTR), interrupt descriptor table registers (IDTR), task registers, and local descriptor table registers (LDTR).

[0158] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. Register architecture 1700 may be used, for example, in a register file / memory, or in a physical register file circuit 1558.

[0159] Instruction set architecture.

[0160] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because there are fewer included fields) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, the example ADD instruction has a specific opcode and instruction format, the instruction format includes an opcode field to specify the opcode, and includes an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field that selects the specific operand. In addition, although the following description is made in the context of the x86 ISA, it is within the knowledge of those skilled in the art to apply the teachings of the present disclosure to other ISAs.

[0161] Example instruction format.

[0162] The examples of the (one or more) instructions described herein may be implemented in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of (one or more) instructions may be executed on these systems, architectures, and pipelines, but are not limited to those described in detail.

[0163] Fig.18An example of an instruction format is illustrated. As shown, an instruction may include multiple components, including, but not limited to, one or more fields for: one or more prefixes 1801, an opcode 1803, addressing information 1805 (e.g., a register identifier, memory addressing information, etc.), a displacement value 1807, and / or an immediate value 1809. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 1803 field. In some examples, the illustrated order is the order in which the fields are to be encoded, however, it should be understood that in other examples, the fields may be encoded in another order, combined, etc.

[0164] (One or more) prefix fields 1801 modify the instruction when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operation objects (e.g., 0x66) and address sizes (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0165] The opcode field 1803 is used to at least partially define the operation to be performed when the instruction is decoded. In some examples, the length of the primary opcode encoded in the opcode field 1803 is one, two or three bytes. In other examples, the primary opcode can be other lengths. Extra 3-bit opcode fields are sometimes encoded in another field.

[0166] The addressing information field 1805 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig.19An example of an addressing information field 1805 is illustrated. In this illustration, an optional MOD R / M byte 1902 and an optional scale, index, base (SIB) byte 1904 are shown. The MOD R / M byte 1902 and SIB byte 1904 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. Note that each of these fields is optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 1902 includes a MOD field 1942, a register (reg) field 1944, and an R / M field 1946.

[0167] The content of MOD field 1942 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 1942 has a binary value of 11 (11b), register direct addressing mode is utilized, otherwise register indirect addressing mode is used.

[0168] Register field 1944 may encode a destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The contents of register field 1944 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 1944 is supplemented with additional bits from a prefix (e.g., prefix 1801) to allow for greater addressing.

[0169] R / M field 1946 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 1946 may be combined with MOD field 1942 to specify an addressing mode.

[0170] SIB byte 1904 includes a scale field 1952, an index field 1954, and a base address field 1956 for address generation. Scaling field 1952 indicates a scaling factor. Index field 1954 specifies the index register to be used. In some examples, index field 1954 is complemented with additional bits from a prefix (e.g., prefix 1801) to allow for larger addressing. Base address field 1956 specifies the base address register to be used. In some examples, base address field 1956 is complemented with additional bits from a prefix (e.g., prefix 1801) to allow for larger addressing. In practice, the contents of scale field 1952 allow the contents of index field 1954 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 * address generation of index + base address).

[0171] Some addressing forms use displacement values ​​to generate memory addresses. For example, 缩放 1805, which indicates a compressed displacement scheme for which the displacement value is calculated and stored in displacement field 1807.

[0172] In some examples, the immediate value field 1809 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, and so on.

[0173] Fig. 20 An example of a first prefix 1801A is illustrated. In some examples, the first prefix 1801A is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0174] Instructions using the first prefix 1801A can use a 3-bit field to specify up to three registers, depending on the format: 1) using the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902; 2) using the MOD R / M byte 1902 with the SIB byte 1904, including using the reg field 1944 as well as the base field 1956 and the index field 1954; or 3) using the register field of the opcode.

[0175] In the first prefix 1801A, bit positions 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but cannot determine the operand width alone. Therefore, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0176] Note that adding another bit allows for 16 (2 4 ) registers, while the separate MOD R / M reg field 1944 and the R / M field 1946 of MOD R / M can only address 8 registers each.

[0177] In the first prefix 1801A, bit position 2 (R) may be an extension of the MOD R / M reg field 1944 and may be used to modify the MOD R / M reg field 1944 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 1902 specifies other registers or defines an extended opcode, R is ignored.

[0178] Bit position 1 (X) may modify the SIB byte index field 1954 .

[0179] Bit position 0 (B) may modify the base address in R / M field 1946 or SIB byte base address field 1956 of MOD R / M; or it may modify the opcode register field used to access a general register (eg, general register 1725).

[0180] Fig.21A -D illustrates an example of how the R, X, and B fields of the first prefix 1801A are used. Fig.21A It is illustrated that when the SIB byte 1904 is not used for memory addressing, the R and B from the first prefix 1801A are used to extend the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902. Fig.21B It is illustrated that when the SIB byte 1904 is not used, the R and B from the first prefix 1801A are used to extend the reg field 1944 and the R / M field 1946 of the MOD R / M byte 1902 (register-register addressing). Fig. 21C It is illustrated that when the SIB byte 1904 is used for memory addressing, the R, X, and B from the first prefix 1801A are used to extend the reg field 1944 of the MOD R / M byte 1902 as well as the index field 1954 and the base address field 1956. Fig.21D It is illustrated that when a register is encoded in the opcode 1803 , the B from the first prefix 1801A is used to extend the reg field 1944 of the MOD R / M byte 1902 .

[0181] Fig.22A-B illustrates an example of a second prefix 1801B. In some examples, the second prefix 1801B is an example of a VEX prefix. The second prefix 1801B encoding allows instructions to have more than two operands and allows SIMD vector registers (e.g., vector / SIMD registers 1710) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 1801B provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 1801B enables the operands to perform non-destructive operations, such as A=B+C.

[0182] In some examples, the second prefix 1801B has two forms - a two-byte form and a three-byte form. The two-byte second prefix 1801B is mainly used for 128-bit, scalar and some 256-bit instructions; while the three-byte second prefix 1801B provides a compact replacement for 3-byte opcode instructions and the first prefix 1801A.

[0183] Fig.22A An example of a two-byte form of the second prefix 1801B is illustrated. In one example, the format field 2201 (byte 0 2203) contains the value C5H. In one example, byte 1 2205 includes an "R" value in bit [7]. This value is the complement of the "R" value of the first prefix 1801A. Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form and is valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0184] Instructions using this prefix may use the R / M field 1946 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0185] Instructions using this prefix may use the reg field 1944 of MOD R / M to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0186] For instruction syntax supporting four operands, vvvv, R / M field 1946 of MOD R / M, and reg field 1944 of MOD R / M encode three of the four operands. Bits [7:4] of immediate value field 1809 are then used to encode the third source register operand.

[0187] Fig. 22B An example of a three-byte form of the second prefix 1801B is illustrated. In one example, the format field 2211 (byte 0 2213) contains the value C4H. Byte 1 2215 includes "R", "X" and "B" in bits [7:5], which are the complements of these values ​​of the first prefix 1801A. Bits [4:0] (shown as mmmm) of byte 1 2215 include content that encodes one or more implicit leading opcode bytes as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means 0F3AH leading opcode, and so on.

[0188] The use of bit [7] of byte 2 2217 is similar to that of W of the first prefix 1801A, including helping to determine the size of operands that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0189] Instructions using this prefix may use the R / M field 1946 of MOD R / M to encode an instruction operand that references a memory address, or to encode a destination register operand or a source register operand.

[0190] Instructions using this prefix may use the reg field 1944 of MOD R / M to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0191] For instruction syntax supporting four operands, vvvv, R / M field 1946 of MOD R / M, and reg field 1944 of MOD R / M encode three of the four operands. Bits [7:4] of immediate value field 1809 are then used to encode the third source register operand.

[0192] Fig.23 An example of a third prefix 1801C is illustrated. In some examples, the third prefix 1801C is an example of an EVEX prefix. The third prefix 1801C is a four-byte prefix.

[0193] The third prefix 1801C can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see the discussion of registers in previous figures, e.g. Fig.17 ) or predicate instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 1801B.

[0194] The third prefix 1801C can encode features specific to the instruction class (e.g., a packed instruction with "load+operation" semantics can support an embedded broadcast feature, a floating-point instruction with rounding semantics can support a static rounding feature, a floating-point instruction with non-rounding arithmetic semantics can support a "suppress all exceptions" feature, and so on).

[0195] The first byte of the third prefix 1801C is the format field 2311, which in one example has a value of 62 H. The subsequent bytes are called payload bytes 2315-2319, and together form a 24-bit value of P[23:0], providing specific capabilities in the form of one or more fields (described in detail herein).

[0196] In some examples, P[1:0] of payload byte 2319 is the same as the two mm bits in the lower order. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and the reg field 1944 of MOD R / M. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 1944 and the R / M field 1946 of MOD R / M, access to the next set of 8 registers beyond the lower 8 registers is allowed. P[9:8] provides opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

[10] is a fixed value of 1 in some examples. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0197] P

[15] is similar to W of the first prefix 1801A and the second prefix 1811B, and can be used as an opcode extension bit or an operand size promotion.

[0198] P[18:16] specifies the index of a register in the operation mask (write mask) register (e.g., write mask / predicate register 1715). In one example, the particular value aaa=000 has special behavior, implying that no operation mask is used for this particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from update during the execution of any operation (specified by the basic operation and the enhanced operation); in another example, the old value of each element of the destination is retained (if the corresponding mask bit has a value of 0). In contrast, when zeroing, the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic operation and the enhanced operation); in one example, the elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span of elements modified, from first to last); however, the elements modified do not have to be consecutive. Thus, the operation mask field enables a subset of vector operations, including loads, stores, arithmetic, logical, etc. Although in the described examples, the contents of the operation mask field select which of several operation mask registers contains the operation mask to be used (so that the contents of the operation mask field indirectly identify the masking to be performed), alternative examples alternatively or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0199] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes various features that vary in different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0200] The following table details an example of the encoding of registers in instructions using the third prefix 1801C. Table 1: 32-register support in 64-bit mode Table 2: Encoding register specifiers in 32-bit mode Table 3: Operation Mask Register Specifier Encoding

[0201] Program code can be applied to input information to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the present application, the processing system includes any system having a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor, or any combination thereof.

[0202] Program code can be implemented in a process-oriented or object-oriented high-level programming language to communicate with the processing system. If desired, program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0203] Examples of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of these implementation approaches. Examples can be implemented as computer programs or program codes, executed on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0204] One or more aspects of at least one example can be implemented by representative instructions stored on a machine-readable medium, which represent various logics within a processor, and when these instructions are read by a machine, the machine makes logic for performing the technology described herein. These representations are called "intellectual property (IP) cores" and can be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into a manufacturing machine that makes the logic or processor.

[0205] These machine-readable storage media may include, but are not limited to, non-transitory tangible arrangements of items manufactured or formed by a machine or device, including storage media such as: hard disks, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), semiconductor devices (e.g., read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM)), magnetic cards or optical cards, or any other type of medium suitable for storing electronic instructions.

[0206] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description languages ​​(HDL), that define the structures, circuits, devices, processors and / or system features described herein. Such examples may also be referred to as program products.

[0207] Emulation (including binary translation, code deformation, etc.).

[0208] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented with software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0209] Fig.24The block diagram of illustrates the use of a software instruction converter according to an example, which is used to convert binary instructions in a source ISA into binary instructions in a target ISA. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.24 It is shown that a program in a high-level language 2402 can be compiled using a first ISA compiler 2404 to generate first ISA binary code 2406 that can be natively executed by a processor having at least one first ISA core 2416. The processor having at least one first ISA core 2416 represents any processor that is capable of executing or otherwise processing (1) a substantial portion of the first ISA or (2) a program that is natively executed by a processor having at least one first ISA core. The first ISA compiler 2404 represents a compiler operable to generate first ISA binary code 2406 (e.g., object code) that can be executed on a processor 2416 having at least one first ISA core with or without additional linking processing. Similarly, Fig.24 It is shown that a program in a high-level language 2402 can be compiled using an alternative ISA compiler 2408 to generate an alternative ISA binary code 2410, which can be executed natively by a processor 2414 without a first ISA core. An instruction converter 2412 is used to convert the first ISA binary code 2406 into code that can be executed natively by a processor 2414 without a first ISA core. This converted code will not necessarily be the same as the alternative ISA binary code 2410; however, the converted code will implement the overall operation and be composed of instructions from the alternative ISA. Thus, the instruction converter 2412 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without a first ISA processor or core to execute the first ISA binary code 2406 through simulation, emulation, or any other process.

[0210] Reference to "an example", "an example", etc. indicates that the example being described may include a particular feature, structure, or characteristic, but not every example may include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same example. In addition, when a particular feature, structure, or characteristic is described in conjunction with one example, it should be considered that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other examples (whether or not explicitly described).

[0211] In addition, in the various examples described above, unless otherwise specifically noted, selection language such as phrases "at least one of A, B, or C" or "A, B and / or C" should be understood to refer to A, B, or C, or any combination thereof (i.e., A and B, A and C, B and C, and A, B and C).

[0212] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident 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 claims.

Claims

1. A device comprising: A hardware processor core, the hardware processor core being used to implement: a trust domain manager for managing one or more hardware-isolated virtual machines as respective trust domains having regions of memory protected by respective cryptographic keys, and a virtual machine monitor that is not permitted to access protected memory regions of the one or more hardware isolated virtual machines; as well as a memory management circuit coupled between the hardware processor core and the memory, In which, in response to a hardware-isolated virtual machine generating a memory dump file, the trust domain manager is used to encrypt the memory dump file using a debug key to generate an encrypted memory dump file and store the encrypted memory dump file in a portion of the memory that can be accessed by the virtual machine monitor, and the debug key is different from any encryption key among the corresponding encryption keys.

2. The device according to claim 1, wherein: The trust domain manager is used to: in response to a request to create the hardware-isolated virtual machine, generate the debug key and store the debug key in a data structure of the trust domain manager.

3. The device as claimed in claim 2, wherein: For each hardware isolated virtual machine of a plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping.

4. The device according to claim 2, wherein: The trust domain manager is to remove the debug key from the data structure of the trust domain manager in response to a request for a virtual machine to break the hardware isolation.

5. The device according to claim 1, wherein: The trust domain manager is configured to, in response to the hardware-isolated virtual machine generating the memory dump file, perform: checking, in a data structure including debug key to hardware isolated virtual machine mappings, whether the debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; as well as If the debug key does not exist in the data structure, an error indication is returned.

6. The device according to claim 1, wherein: The trust domain manager is used to: generate the debug key in response to a request to create the hardware-isolated virtual machine; and store the debug key in a data structure of the trust domain manager when the hardware processor core is in production mode.

7. The device of claim 1, wherein: The trust domain manager is used to allow only a virtual machine isolated by the trust domain manager and the hardware that generates the memory dump file to access the debug key.

8. The device according to any one of claims 1 to 7, wherein: The hardware isolated virtual machine is used to generate the memory dump file in response to a crash of a non-operating system application in the hardware isolated virtual machine.

9. A method comprising: managing, by a trust domain manager of a hardware processor core, one or more hardware isolated virtual machines as respective trust domains having regions of memory protected by respective cryptographic keys, the hardware processor core also including a virtual machine monitor that is not permitted to access the protected memory regions of the one or more hardware isolated virtual machines; In response to the hardware-isolated virtual machine generating a memory dump file, the trust domain manager encrypts the memory dump file using a debug key to generate an encrypted memory dump file, the debug key being different from any of the corresponding encryption keys; as well as The encrypted memory dump file is stored in a portion of the memory accessible by the virtual machine monitor.

10. The method of claim 9, further comprising: In response to a request to create the hardware-isolated virtual machine, generating the debug key by the trust domain manager; as well as The debug key is stored in a data structure of the trust domain manager.

11. The method of claim 10, wherein: For each hardware isolated virtual machine of a plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping.

12. The method of claim 10, further comprising: Responsive to a request to the virtual machine to break the hardware isolation, removing, by the trust domain manager, the debug key from the data structure of the trust domain manager.

13. The method of claim 9, further comprising: In response to the hardware-isolated virtual machine generating the memory dump file, the trust domain manager performs: checking, in a data structure including debug key to hardware isolated virtual machine mappings, whether the debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; as well as If the debug key does not exist in the data structure, an error indication is returned.

14. The method of claim 9, further comprising: In response to a request to create the hardware-isolated virtual machine, generating the debug key by the trust domain manager; as well as The debug key is stored in a data structure of the trust domain manager while the hardware processor core is in production mode.

15. The method of claim 9, further comprising: Only a virtual machine isolated by the trusted domain manager and the hardware that generated the memory dump file is allowed by the trusted domain manager to access the debug key.

16. The method of any one of claims 9 to 15, further comprising: The memory dump file is generated by the hardware isolated virtual machine in response to a crash of a non-operating system application in the hardware isolated virtual machine.

17. An apparatus comprising: Memory; A hardware processor core, the hardware processor core being used to implement: a trust domain manager for managing one or more hardware isolated virtual machines as respective trust domains having memory regions protected by respective encryption keys, and a virtual machine monitor that is not permitted to access protected memory regions of the one or more hardware isolated virtual machines; as well as a memory management circuit coupled between the hardware processor core and the memory, In which, in response to a hardware-isolated virtual machine generating a memory dump file, the trust domain manager is used to encrypt the memory dump file using a debug key to generate an encrypted memory dump file and store the encrypted memory dump file in a portion of the memory that can be accessed by the virtual machine monitor, and the debug key is different from any encryption key among the corresponding encryption keys.

18. The device of claim 17, wherein: The trust domain manager is used to: in response to a request to create the hardware-isolated virtual machine, generate the debug key and store the debug key in a data structure of the trust domain manager.

19. The device of claim 18, wherein: For each hardware isolated virtual machine of a plurality of hardware isolated virtual machines, the data structure of the trust domain manager includes a corresponding debug key to hardware isolated virtual machine mapping.

20. The apparatus of claim 18, wherein: The trust domain manager is to remove the debug key from the data structure of the trust domain manager in response to a request for a virtual machine to break the hardware isolation.

21. The apparatus of claim 17, wherein: The trust domain manager is configured to, in response to the hardware-isolated virtual machine generating the memory dump file, perform: checking, in a data structure including debug key to hardware isolated virtual machine mappings, whether the debug key exists for the hardware isolated virtual machine that generated the memory dump file; If the debug key is present in the data structure, encrypting the memory dump file using the debug key and storing the encrypted memory dump file in a portion of the memory accessible by the virtual machine monitor; as well as If the debug key does not exist in the data structure, an error indication is returned.

22. The apparatus of claim 17, wherein: The trust domain manager is used to: generate the debug key in response to a request to create the hardware-isolated virtual machine; and store the debug key in a data structure of the trust domain manager when the hardware processor core is in production mode.

23. The apparatus of claim 17, wherein: The trust domain manager is used to allow only a virtual machine isolated by the trust domain manager and the hardware that generates the memory dump file to access the debug key.

24. The device according to any one of claims 17 to 23, wherein: The hardware isolated virtual machine is used to generate the memory dump file in response to a crash of a non-operating system application in the hardware isolated virtual machine.

Images