Multi-key cryptographic memory protection

Abstract

A multi-key cryptographic memory protection is disclosed. In one embodiment, an apparatus comprises a processor to execute instructions, wherein the instructions include a memory access operation associated with a memory location of a memory. The apparatus further comprises a memory encryption controller to identify the memory access operation, determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory, identify an encryption key associated with the protected domain, perform a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain, and return a result of the cryptographic operation, wherein the result is to be used for the memory access operation.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to the field of computer security, and more particularly, but not exclusively, to cryptographic memory protection. BACKGROUND

[0002] Growing demands for robust computer security have led to widespread use of cryptography in mainstream computer systems and networks. For example, disk encryption can be used to protect data that resides on persistent disk storage devices, while network encryption can be used to protect data that is transmitted over a network. However, data that resides in system memory is often stored and / or transmitted in plaintext and thus can be vulnerable to attack. BRIEF DESCRIPTION OF DRAWINGS

[0003] The present disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It is emphasized that, according to common practice, the various features are not necessarily drawn to scale, and are merely intended to illustrate the various embodiments. Where explicitly indicated by explicit or implicit showing of scale, it is merely provided as one illustrative example. In other embodiments, the size of various features can be arbitrarily enlarged or reduced to facilitate discussion.

[0004] Figure 1 A schematic diagram illustrating an example computing system, in accordance with certain embodiments, is shown.

[0005] Figure 2 An example embodiment of a multi-key cryptographic memory protection system is shown.

[0006] Figure 3 An example of configuring a protected domain using processor instructions is shown.

[0007] Figure 4 A state machine of an example embodiment of cryptographic memory protection is shown.

[0008] Figure 5 A flowchart of an example embodiment of cryptographic memory protection is shown.

[0009] Figure 6A -B, 7, 8, 9, and 10 show example computer architectures that can be used in accordance with embodiments disclosed herein. DETAILED DESCRIPTION

[0010] The following disclosure provides a number of different embodiments or examples for implementing different features of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Additionally, the present disclosure can refer to a number of means for implementing the embodiments and / or configurations. Mean-plus-function clauses can refer to elements as means-plus-function whether the elements are specifically recited as means-plus-function elements. Additionally, the present disclosure can refer to a number of acts or operations to be taken by one or more devices. These acts or operations can be referred to as being taken by a "device," possibly the device that is implicitly the object of the action. However, these acts or operations can also be taken by other devices not explicitly described. For example, while an apparatus can be described that receives input and manipulates the input, it is also possible that two apparatuses are used, one that receives the input and manipulates the input, and one that ultimately manipulates the input. Depending upon the circumstances, each of these apparatuses would be deemed to be performing an operation or an act for purposes of the present disclosure. The different embodiments can have different advantages, and no particular advantage is necessarily required by any embodiment.

[0011] The growing demand for robust computer security has led to the widespread use of cryptography in mainstream computer systems and networks and the development of increasingly complex and secure modern cryptographic techniques. For example, disk encryption can be used to protect data that resides on persistent disk storage devices, while network encryption can be used to protect data that is transmitted over a network. However, data that resides in system memory is often stored and / or transmitted in plaintext and can therefore be vulnerable to attack. For example, an attacker can use a variety of techniques to maliciously access data stored in memory, such as bus scanning and / or memory scanning, among others. Moreover, in some cases, these malicious techniques can be used to access memory locations that include encryption keys stored in plaintext, such as encryption keys used for disk encryption, thereby facilitating further unauthorized access to other data protected by encryption.

[0012] Accordingly, the present disclosure describes embodiments of password memory protection. The described embodiments can be used to provide memory encryption protection, thereby providing an additional layer of security by plugging holes associated with unprotected or insecure memory. For example, in some embodiments, memory encryption can be provided by implementing a password engine or controller on a memory path or memory bus. In this way, data can be encrypted and protected when residing in memory and during transfers to and from memory (e.g., when transferred from memory to a processor via a memory bus or memory path, and vice versa). However, while memory encryption can be necessary for certain users and / or use cases, uniform memory protection across a computing system can be insufficient in certain situations. For example, cloud service providers often host data and / or applications or workloads for multiple customers or third parties. Further, cloud service providers can use memory encryption to provide uniform protection for all hosted customer workloads, e.g., using a single encryption key. However, simply providing uniform memory encryption protection for all hosted workloads, without differentiating between workloads of different customers, can be insufficient. For example, cloud service providers and / or their customers can be unwilling to share the same encryption key for all customers. Instead, cloud service providers and / or their customers can prefer to provide memory encryption on a per-tenant basis (e.g., per customer or per virtual machine) to ensure that each customer workload is individually protected and isolated using a unique encryption key.

[0013] Thus, the described embodiments provide memory encryption that supports multiple keys and is configurable or programmable. The number of supported keys, for example, can depend on the implementation. In some embodiments, for example, a memory protection engine can be configured or programmed (e.g., by software) to encrypt different regions or pages of memory using different encryption keys and / or algorithms. For example, in some embodiments, a user or tenant (e.g., a cloud service provider or customer) can specify that a particular region or page of memory be protected in plaintext (e.g., unencrypted), standard or default encryption protection (e.g., encrypted using a default or global encryption key), or custom encryption protection (e.g., encrypted using a unique encryption key). In this way, memory encryption can be provided and configured separately for different tenants, customers, or protection domains. In some embodiments, for example, a "domain" can be viewed as a collection of resources associated with a particular workload, which can include any region of memory containing data associated with that workload. Moreover, memory encryption can be configured separately for each domain, allowing each domain or workload to be protected using a separate encryption key. In this way, cryptographic isolation can be achieved for different tenants, customers, or workloads of a user. Moreover, workloads can also be isolated from management software (e.g., a virtual machine manager) of a cloud service provider. Domains can also be configured in plaintext mode, as in some cases it can not be desirable to perform memory encryption for a particular domain (e.g., to avoid performance impacts of memory encryption, to share memory (and I / O) between different entities, to reclaim memory, etc.).

[0014] The described embodiments can also be used to protect data when using memory for persistent data storage, such as storage class memory (SCM) and other forms of flash and solid state storage (e.g., non-volatile dual in-line memory modules (NVDIMMs), direct access storage (DAS) memory, etc.). For example, when using memory rather than disk-based storage to provide persistent data storage, disk encryption software can not be able to adequately protect stored data if memory encryption is not supported. Thus, the described embodiments can be used to protect data using memory encryption when memory is used for persistent data storage.

[0015] The described embodiments provide numerous features and advantages, including password memory protection (e.g., via a password engine on the memory path), multi-key encryption support, and software programmable configurability and flexibility. These features enable isolated encryption protection by using separate keys for different domains, memory regions, workloads, tenants, and / or customers, thereby providing support for multiple password-isolated protection domains. In this way, the described embodiments can be used to meet increased security requirements for certain users and / or use cases, such as cloud service providers with hosted workloads of multiple third parties or customers. The described embodiments can also be used to take advantage of the performance benefits of using memory for persistent data storage (e.g., NVDIMMs or other storage class memory (SCM)) without sacrificing security.

[0016] Furthermore, the described memory encryption embodiments can be implemented using a common CPU-centric approach that is compatible with any type of memory, including volatile memory (e.g., random access memory (RAM), such as dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and static RAM (SRAM)) and non-volatile memory (e.g., storage class memory (SCM), direct access storage (DAS) memory, non-volatile dual in-line memory module (NVDIMM), and / or other forms of flash or solid state storage).

[0017] The described embodiments are also scalable, as they can be implemented using instructions, commands, parameters, and / or data structures (e.g., encryption key tables) that can be extended as needed in the future. For example, the described embodiments can be scaled to provide multi-domain memory encryption for computing systems with 64 terabytes (TB) of addressable physical memory. Furthermore, the described embodiments can be further scaled, for example, by extending to physical addresses (PAs) and / or cache tags.

[0018] Example embodiments that can be used to implement features and functionality of the present disclosure will now be described in more detail with reference to the drawings.

[0019] Figure 1A schematic diagram illustrating example computing system 100 is shown. In embodiments, system 100 and / or its underlying components can include the cryptographic memory protection functionality described throughout this disclosure. For example, cloud service provider 120 generally hosts workloads 130 (e.g., data and / or applications) for multiple customers or third parties. Accordingly, in some embodiments, cloud service provider 120 can implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thereby ensuring that each customer workload 130 is individually protected and isolated using a unique encryption key. Cryptographic memory protection can also be implemented by other components of system 100, such as edge devices 110. Further example embodiments of cryptographic memory protection are described throughout this disclosure in conjunction with the remaining figures.

[0020] The various components in the illustrated example of computing system 100 will now be further discussed below.

[0021] Edge devices 110 can include any equipment and / or devices deployed or connected proximate to the“edge” of communication system 100. In the illustrated embodiment, edge devices 110 include end-user devices 112 (e.g., desktops, laptops, mobile devices), Internet of Things (IoT) devices 114, and gateways and / or routers 116, among such examples. Edge devices 110 can communicate with each other and / or with other remote networks and services (e.g., cloud services 120) through one or more networks and / or communication protocols, such as communication network 150. Further, in some embodiments, certain edge devices 110 can include the cryptographic memory protection functionality described throughout this disclosure.

[0022] End-user devices 112 can include any device that allows or facilitates user interaction with computing system 100, including, for example, desktop computers, laptop computers, tablets, mobile phones and other mobile devices, and wearable devices (e.g., smart watches, smart glasses, headsets), among such examples.

[0023] IoT devices 114 can include any device capable of communicating and / or capable of participating in an Internet of Things (IoT) system or network. An IoT system can refer to a new or improved ad-hoc system and network composed of multiple different devices (e.g., IoT devices 114) that interoperate or coordinate for a particular application or use case. Such ad-hoc systems are on the rise as more and more products and equipment evolve to become “smart,” meaning that they are controlled or monitored by a computer processor and are capable of communicating with other devices. For example, IoT devices 114 can include a computer processor and / or a communication interface to allow for interoperation with other components of system 100, such as with cloud services 120 and / or with other edge devices 110. IoT devices 114 can be “greenfield” devices that are developed from the ground up with IoT capabilities, or “brownfield” devices that are created by integrating IoT capabilities into existing legacy devices that were not originally developed with IoT capabilities. For example, in some cases, IoT devices 114 can be built from sensors and communication modules that are integrated in or attached to “things,” such as equipment, toys, tools, vehicles, living things (e.g., plants, animals, people), and so on. Alternatively or additionally, certain IoT devices 114 can rely on intermediary components, such as edge gateways or routers 116, to communicate with various components of system 100.

[0024] IoT devices 114 can include various types of sensors for monitoring, detecting, measuring, and generating sensor data and signals associated with properties of their environments. For example, a given sensor can be configured to detect one or more respective properties, such as movement, weight, physical contact, biological attributes, temperature, wind, noise, light, location, humidity, radiation, liquid, specific chemical compounds, battery life, wireless signals, computer communications and bandwidth, and so on such examples. Sensors can include physical sensors (e.g., physical monitoring components) and virtual sensors (e.g., software-based monitoring components). IoT devices 114 can also include actuators for performing various actions in their respective environments. For example, actuators can be used to selectively activate certain functions, such as switching power or operation of security systems (e.g., alarms, cameras, locks) or home appliances (e.g., audio systems, lighting, HVAC devices, garage doors), and so on such examples.

[0025] In practice, the present disclosure contemplates potentially limitless use of IoT devices 114 and associated sensors / actuators. IoT devices 114 can include, for example, any type of equipment and / or device associated with any type of system 100 and / or industry, including: transportation (e.g., automotive, aviation), industrial manufacturing, energy (e.g., power plants), telecommunications (e.g., Internet, cellular, and television service providers), medical (e.g., healthcare, pharmaceuticals), food processing, and / or retail industries, among others. For example, in the transportation industry, IoT devices 114 can include equipment and devices associated with an aircraft, automobile, or watercraft, such as navigation systems, autonomous flight or driving systems, traffic sensors and controllers, and / or any internal mechanical or electrical components (e.g., engines) monitored by sensors. IoT devices 114 can also include equipment, devices, and / or infrastructure associated with industrial manufacturing and production, shipping (e.g., cargo tracking), communication networks (e.g., gateways, routers, servers, cellular towers), server farms, power plants, wind farms, oil and gas pipelines, water treatment and distribution, waste collection and treatment, and weather monitoring (e.g., temperature, wind, and humidity sensors), among such examples. IoT devices 114 can also include, for example, any type of “smart” device or system, such as smart entertainment systems (e.g., televisions, audio systems, electronic gaming systems), smart home or office appliances (e.g., heating-ventilation-air conditioning (HVAC) appliances, refrigerators, washing machines, dryers, coffee makers), power control systems (e.g., automated electrical, lighting, and HVAC controls), security systems (e.g., alarms, locks, cameras, motion detectors, fingerprint scanners, facial recognition systems), and other home automation systems, among such examples. IoT devices 114 can be statically positioned, such as mounted on a building, wall, floor, ground, light pole, sign, water tower, or any other fixed or static structure. IoT devices 114 can also be mobile, such as devices in vehicles or aircraft, drones, packages (e.g., for tracking cargo), mobile devices, and wearable devices, among such examples. Furthermore, IoT devices 114 can also be any type of edge device 110, including end user devices 112 as well as edge gateways and routers 116.

[0026] Edge gateways and / or routers 116 can be used to facilitate communications to and from edge devices 110. For example, a gateway 116 can provide communication capabilities to existing legacy devices (e.g., "brownfield" IoT devices) that were not originally developed with any such capabilities. A gateway 116 can also be used to extend the geographic range of edge devices 110 that have short-range, proprietary, or otherwise limited communication capabilities, such as IoT devices 114 with Bluetooth or ZigBee communication capabilities. For example, a gateway 116 can act as an intermediary between an IoT device 114 and a remote network or service by providing front-haul to the IoT device 114 using its native communication capabilities (e.g., Bluetooth, ZigBee) and back-haul to other networks 150 and / or cloud services 120 using another wired or wireless communication medium (e.g., Ethernet, WiFi, cellular). In some embodiments, a gateway 116 can be implemented by a dedicated gateway device, or can be implemented by a general-purpose device, such as another IoT device 114, an end-user device 112, or other type of edge device 110.

[0027] In some instances, a gateway 116 can also implement certain network management and / or application functionality (e.g., IoT management and / or IoT application functionality for IoT devices 114), either alone or in conjunction with other components, such as cloud services 120 and / or other edge devices 110. For example, in some embodiments, configuration parameters and / or application logic can be pushed to or pulled from a gateway device 116, allowing IoT devices 114 (or other edge devices 110) within range or proximity of the gateway 116 to be configured for a particular IoT application or use case.

[0028] Cloud services 120 can include services that are hosted remotely over network 150 or in the "cloud." For example, in some embodiments, cloud services 120 can be hosted remotely on servers (e.g., application servers or database servers) in a data center. Cloud services 120 can include any services that can be utilized by or available to edge devices 110, including but not limited to, data and application hosting, computing services (e.g., data analytics, search, diagnostics and fault management), security services (e.g., monitoring, alerting, user authentication), mapping and navigation, geolocation services, network or infrastructure management, IoT applications and management services, payment processing, audio and video streaming, messaging, social networking, news and weather, and the like such examples. Moreover, in some embodiments, certain cloud services 120 can include the cryptographic memory protection functionality described throughout this disclosure. For example, cloud service providers 120 typically host workloads 130 (e.g., data and / or applications) for multiple customers or third parties. Accordingly, in some embodiments, cloud service providers 120 can implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thereby ensuring that each customer workload 130 is individually protected and isolated using a unique encryption key.

[0029] Network 150 can be used to facilitate communication between components of computing system 100. For example, edge devices 110 (such as end user devices 112 and IoT devices 114) can use network 150 to communicate with each other and / or access one or more remote cloud services 120. Network 150 can include any number or type of communication networks, including, for example, local area networks, wide area networks, public networks, the Internet, cellular networks, Wi-Fi networks, short-range networks (e.g., Bluetooth or ZigBee), and / or any other wired or wireless networks or communication mediums.

[0030] Any, all, or some of the computing devices of system 100 can be adapted to execute any operating system, including a Linux or other UNIX-based operating system, Microsoft Windows, Windows Server, Mac OS, Apple iOS, Google Android, or any custom and / or proprietary operating system, as well as virtual machines adapted to virtualize execution of a particular operating system.

[0031] Although Figure 1 Although Figure 1 Not all of the elements illustrated within system 100 of the disclosure are utilized in every alternative implementation of the disclosure. Further, various ones of the elements can be utilized in combination with one another in any suitable manner in accordance with the teachings of the disclosure. Figure 1One or more of the elements described in the example may be located outside system 100, while in other instances, certain elements may be included within one or more of the other said elements and other elements not described in the illustrated implementation, or may be included as part of one or more of the other said elements and other elements not described in the illustrated implementation. Furthermore, Figure 1 Some of the elements shown can be combined with other components and used for alternative or additional purposes besides those described herein.

[0032] Multi-key cryptographic memory protection

[0033] Figure 2 An example embodiment of a multi-key cryptographic memory protection system 200 is shown. In the illustrated embodiment, the memory protection system 200 includes a processor 202, a system agent 204, and a memory 210. As further described below, the memory protection system 200 provides cryptographic protection for data stored on the memory 210.

[0034] Processor 202 can be used to execute instructions, code, and / or any other form of logic or software, such as instructions associated with a software application. Processor 202 may include any combination of logical or processing elements operable to execute instructions loaded from memory or implemented directly in hardware, such as microprocessors, digital signal processors, field-programmable gate arrays (FPGAs), graphics processing units (GPUs), programmable logic arrays (PLAs), or application-specific integrated circuits (ASICs). In some embodiments, for example, processor 202 and / or memory protection system 200 may be implemented using the computer architecture of Figures 6-10.

[0035] Memory 210 can be used to store information, such as code and / or data used by processor 202 during execution, and / or persistent data associated with applications or users of system 200. Memory 210 may include any type of component or combination thereof capable of storing information, including volatile memory (e.g., random access memory (RAM), such as dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and static RAM (SRAM)) and / or non-volatile memory (e.g., storage class memory (SCM), direct access memory (DAS) memory, non-volatile dual in-line memory modules (NVDIMM), and / or other forms of flash or solid-state storage).

[0036] The system agent 204 can be used to provide various functionality for the processor 202, such as managing access to the memory 210 and / or other resources of the system 200. In the illustrated embodiment, for example, the system agent 204 includes a memory controller 208 for controlling and / or managing access to the memory 210 of the system 200. In addition, as further described below, the system agent 204 also includes a memory protection controller 206 for protecting data stored on the memory 210. In some embodiments, the system agent 204 can also provide an interface between the processor 202 and other components of the system 200 (e.g., using a direct media interface (DMI) and / or a PCI express bridge). In various embodiments, the system agent 204 can include any combination of logic elements configured to perform the functions of the system agent 204 described herein, loaded from memory or other non-transitory computer readable media, or implemented directly in hardware, including by way of non-limiting example: microprocessors, digital signal processors (DSPs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), programmable logic arrays (PLAs), application specific integrated circuits (ASICs), and / or virtual machine (VM) processors. The system agent 204 can be integrated with the processor 202, or alternatively, the system agent 204 can be implemented on a separate chip communicatively coupled or connected to the processor 202.

[0037] The memory controller 208 can be used to control and / or manage access to the memory 210 of the system 200. In various embodiments, the memory controller 208 can be implemented using any combination of hardware and / or software logic, including microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), virtual machines (VMs), and / or any other type of circuit or logic.

[0038] In the illustrated embodiment, system 200 provides cryptographic memory protection for memory 210. In some embodiments, for example, cryptographic memory protection can be implemented by extending and / or modifying a particular computer architecture. For example, cryptographic memory protection can be implemented by extending the functionality of processor 202 and / or introducing memory protection controller 206. In the illustrated embodiment, for example, processor 202 is extended to support control registers 203 and processor instructions that can be used to enable and / or configure cryptographic memory protection, and memory protection controller 206 is implemented to provide cryptographic memory protection. Although the illustrated example uses separate logical blocks to depict memory protection controller 206 and processor 202, in actual embodiments, memory protection controller 206 and processor 202 can be integrated together, or alternatively can be implemented as separate components. In various embodiments, for example, memory protection controller 206 can be implemented using any combination of hardware and / or software logic, including microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), virtual machines (VMs), and / or any other type of circuitry or logic.

[0039] Memory protection controller 206 protects data stored on memory 210 using memory encryption. In some embodiments, for example, memory protection controller 206 can be implemented on a memory path or memory bus to allow for encryption of data transferred to and from memory 210, and / or stored thereon. Further, in some embodiments, memory protection controller 206 can be configurable or programmable, and can include support for multiple encryption keys. Thus, memory protection controller 206 can be configured or programmed (e.g., by software) to encrypt different regions or pages of memory 210 using different encryption keys and / or algorithms. In this manner, memory encryption can be provided and configured separately for different users, tenants, customers, applications, and / or workloads.

[0040] For example, in some embodiments, the memory protection controller 206 can be used to define various secure or protected domains that can be separately configured and protected using memory encryption. In some embodiments, for example, a "domain" can be considered to be a collection of resources associated with a particular workload (e.g., a workload of a particular user or application), and can include any region of memory containing data associated with that workload. For example, a protected domain of a customer workload of a cloud service provider can include resources (e.g., memory) associated with an operating system (O / S), a virtual machine (VM) (e.g., a VM running on a virtual machine manager (VMM)), and / or any ring-3 application running on the O / S or VM. The memory protection controller 206 can allow protected domains to be separately configured and protected, thereby allowing each protected domain to be cryptographically isolated in memory by encrypting its associated code and / or data with a unique encryption key. In this way, by defining different protected domains for various workloads, workloads of different users, customers, and / or tenants can be cryptographically isolated.

[0041] In some embodiments, processor instructions and / or hardware registers can be used to discover and configure the cryptographic memory protection of the system 200. For example, in some embodiments, processor instructions can be used to determine whether the system 200 supports cryptographic memory protection, such as the CPU identification (CPUID) instructions used by software to identify the capabilities of a particular processor.

[0042] After determining that the system 200 supports cryptographic memory protection, hardware registers can then be used to enable and / or configure the cryptographic memory protection, such as the control registers 203 of the processor 202. For example, the control registers 203 can include various model-specific registers (MSRs) that allow software to discover, enable, and / or configure the cryptographic memory protection capabilities of the system 200. In some embodiments, for example, the control registers 203 can include a memory encryption capabilities register, a memory encryption activation register, and / or one or more memory encryption exclusion registers, as further described below.

[0043] The memory encryption capabilities register (ME CAPABILITY MSR) can be used to allow software to discover the memory encryption capabilities of the system 200. For example, software can read the ME CAPABILITY MSR (e.g., using a read MSR (RDMSR) instruction) to identify the types and / or algorithms of encryption supported, the maximum number of encryption keys that can be used simultaneously, etc. Table 1 illustrates an example embodiment of the memory encryption capabilities register (ME CAPABILITY MSR).

[0044] Table 1 : Memory Encryption Capabilities Register (ME_CAPABILITY_MSR)

[0045]

[0046]

[0047] The Memory Encryption Activation Register (ME ACTIVATE M SR) can be used to activate the cryptographic memory protection of the system 200 (e.g., by setting appropriate values in the register fields). Table 2 shows an example embodiment of the Memory Encryption Activation Register (ME ACTIVATE M SR).

[0048] Table 2: Memory Encryption Activation Register (ME ACTIVATE M SR)

[0049]

[0050]

[0051]

[0052] The Memory Encryption Exclusion Registers (ME EXCLUDE BASE M SR and ME EXCLUDE MASK M SR) can be used to exclude certain memory regions from the cryptographic memory protection provided by the system 200. For example, in some embodiments, the exclusion registers can be used to identify a memory base address, and then memory encryption can be bypassed for memory addresses that match the base address (e.g., allowing access to the excluded or bypassed memory addresses in plaintext mode).

[0053] Table 3 shows an example embodiment of the Memory Encryption Exclusion Mask Register (ME EXCLUDE MASK M SR), and Table 4 shows an example embodiment of the Memory Encryption Exclusion Base Register (ME EXCLUDE BASE M SR).

[0054] Table 3: Memory Encryption Exclusion Mask Register (ME EXCLUDE MASK M SR)

[0055]

[0056] Table 4: Memory Encryption Exclusion Base Register (ME EXCLUDE BASE M SR)

[0057]

[0058] In the illustrated embodiment, the memory protection controller 206 maintains an internal domain key table 207 to identify protected domains that have been configured in the system 200. The key table 207 can be implemented using any form of storage or memory (e.g., RAM), and can also be implemented directly on the memory protection controller 206, in the memory 210, and / or using another memory component.

[0059] The entries 207a-d of the domain key table 207 each correspond to a different protected domain. For example, each entry 207a-d includes a key or domain identifier (ID), a protection mode, and an associated encryption key (if applicable). In some embodiments, for example, the key ID can represent higher order bits of memory addresses within the associated protected domain. For example, as discussed above, the ME KEYID BITS field of the ME ACTIVATE MSR register specifies the number of bits used for the key ID. In the illustrated example, each key ID in the domain key table 207 is represented using 5 bits. Thus, the protected domain associated with a given key ID covers all memory addresses whose highest order 5 bits match the key ID. In the illustrated embodiment, the key IDs are stored as fields in the key table 207, but in alternative embodiments, the key IDs can be used as an index into the key table 207 rather than being stored directly in the key table 207.

[0060] Further, in some embodiments, multiple protection modes can be supported, and each protected domain can be protected using a particular protection mode. For example, in some embodiments, the supported protection modes can include a clear mode (e.g., unencrypted), a standard or default encryption mode (e.g., encrypted using a standard or default encryption key), and / or a custom encryption mode (e.g., encrypted using a unique encryption key). Thus, the key table 207 can identify the protection mode associated with each protected domain or key ID.

[0061] For example, in the illustrated example, the domain key table 207 includes four entries. The first entry identifies a protected domain corresponding to key ID 00000 (and thus covering all memory addresses including 00000 in the highest order 5 bits) that is protected using the key "ABC" in a default encryption mode. The second entry identifies a protected domain corresponding to key ID 00001 (and thus covering all memory addresses including 00001 in the highest order 5 bits) that is protected in plaintext mode and thus does not have an associated encryption key. The third entry identifies a protected domain corresponding to key ID 00010 (and thus covering all memory addresses including 00010 in the highest order 5 bits) that is protected using the key "XYZ" in a custom encryption mode. The fourth entry identifies a protected domain corresponding to key ID 00011 (and thus covering all memory addresses including 00011 in the highest order 5 bits) that is protected using the key "ABC" in a default encryption mode. As these examples illustrate, the domain protected using the custom encryption mode has a unique key ("XYZ"), the domain protected using the default encryption mode shares an encryption key ("ABC"), and the domain protected in plaintext mode is not encrypted and thus does not have an associated key.

[0062] In some embodiments, processor instructions implemented by the processor 202 can be used to define and / or configure protected domains, such as in connection with Figure 3 And "platform configuration" (PCONFIG) instructions described throughout this disclosure. PCONFIG instructions, for example, can be used to define and / or configure protected domains by programming new entries (or modifying existing entries) in the key table 207 of the memory protection controller 206. In this way, PCONFIG instructions can be used to programmatically (e.g., by management software) define and configure protected domains.

[0063] Figure 3 An example 300 is shown of using processor instructions to configure protected domains. In some embodiments, for example, a processor can implement instructions that can be used to configure protected domains associated with a memory protection system. For example, the processor instructions can be "platform configuration" (PCONFIG) instructions, "trusted platform action manager" (TPAS) instructions, and / or any other suitable type of instructions.

[0064] "Platform configuration" (PCONFIG) instructions, for example, can be used to define and / or configure protected domains by programming new entries (or modifying existing entries) in a domain key table of a memory protection controller (e.g., from Figure 2Protected domains are defined and / or configured by programming (or modifying) new entries in the domain key table 207 of the memory protection controller 206. In this way, protected domains can be defined and configured programmatically using the PCONFIG instruction. Once a protected domain has been configured using the PCONFIG instruction, the memory address associated with the protected domain is protected in a manner specified by the configuration for the protected domain. For example, when using encryption protection, data is encrypted before being written to a memory address within the protected domain, and data read from a memory address within the protected domain is decrypted before being returned to the requesting processor.

[0065] In some embodiments, the PCONFIG instruction may require a privilege level or privilege ring. For example, the processor may support a hierarchical structure of privilege levels or privilege rings to restrict access to certain resources. In some embodiments, privilege ring 0 may be the lowest level of restriction, while privilege rings with higher numbers may be increasingly restrictive. For example, privilege ring 0 may be used for system management software (e.g., operating system kernels and device drivers), while privilege ring 3 may be used for user-space applications. Therefore, in some embodiments, the PCONFIG instruction may be a ring-0 instruction that can only be used by software that executes in the highest privilege ring (e.g., management software for configuring protected domains). Alternatively or additionally, the PCONFIG instruction may be a ring-3 instruction that can be used by any user-space application to configure its own protected domain.

[0066] Figure 3 An example call flow 300 associated with the PCONFIG instruction is shown. The example illustrates a call flow 300 between software 310, which performs domain configuration using the PCONFIG instruction, and a memory protection controller 320. The memory protection controller 320 may include any engine, controller, or other component providing cryptographic memory protection (e.g., Figure 2Software 310 can include any software used to configure domains protected by memory protection controller 206). Software 310 can include any software used to configure domains protected by memory protection controller 320, such as a virtual machine manager and / or other management software. The illustrated call flow begins with software 310 selecting a key programming mode (call 302a) for programming an encryption key for a particular domain. For example, as discussed further below, software 310 can specify a key directly for a domain, or can request that a random key be generated. Software 310 can then call a PCONFIG processor instruction to perform domain configuration (call 302b). When the PCONFIG instruction is called, memory protection controller 320 programs the key and protection mode for the particular domain (call 302c). Memory protection controller 320 then returns a status code to software 310 (call 302d), and the status code is then processed by software 310 (call 302e).

[0067] In some embodiments, the PCONFIG instruction can support various leaf functions for configuring and managing protected domains. When the PCONFIG instruction is executed, for example, a particular leaf function to be called can be specified in a hardware register (e.g., the EAX register). In some embodiments, parameters used by the particular leaf function can also be specified in hardware registers (e.g., the RBX / RCX / RDX registers).

[0068] Table 5 illustrates an example of PCONFIG leaf encodings that can be used to implement support for multiple leaf functions. Although only one leaf function is defined (the KEY_PROGRAM leaf), additional leaf functions can be defined using reserved leaf encodings to extend the functionality of the PCONFIG instruction.

[0069] Table 5: PCONFIG Leaf Function Encodings

[0070]

[0071] The key programming leaf function of the PCONFIG instruction (KEY_PROGRAM) can be used to program a key for a protected domain. In some embodiments, parameters used by the key programming leaf function can be specified in a key programming structure (KEY_PROGRAM_STRUCT), and an address of the key programming structure can be specified in a hardware register (e.g., the RBX register). Table 6 illustrates an example embodiment of a key programming structure (KEY_PROGRAM_STRUCT).

[0072] Table 6: Key Programming Structure (KEY_PROGRAM_STRUCT)

[0073]

[0074] As shown in Table 6, the key programming structure identifies the key ID for the particular domain being programmed, and it also specifies the key programming command. In some embodiments, for example, the key programming leaf function can support multiple key programming commands, and the desired command can be specified in the key programming structure. In addition, in some embodiments, the key programming structure can also include a reserved field(s) that can be used for future extensions to the key programming leaf function.

[0075] Table 7 shows examples of key programming commands that can be supported by the key programming leaf function.

[0076] Table 7: Key Programming Commands

[0077]

[0078] After the key programming leaf function is executed, a return value or status code can be specified in a hardware register to indicate whether the key programming function was successful. Table 8 shows examples of status codes that can be returned by the key programming leaf function.

[0079] Table 8: Status Codes Returned by Key Programming Leaf Function (KEY_PROGRAM)

[0080]

[0081] Although the illustrated embodiments use the PCONFIG processor instruction to perform domain configuration, other embodiments can use alternative and / or additional methods for domain configuration. For example, in some embodiments, hardware registers can be used to perform domain configuration. For example, a PCONFIG model-specific register (MSR) can be implemented for performing domain configuration, allowing software to invoke PCONFIG operations by writing to the PCONFIG MSR (e.g., executing a WRMSR instruction with an index passed in a register such as the ECX register for the PCONFIG MSR). In addition, certain parameters for the PCONFIG operations (and their associated leaf functions and commands) can be passed in hardware registers. For example, the address of the key programming structure (KEY_PROGRAM_STRUCT) can be passed in a hardware register, such as the EDX register, the EAX register, or both registers (e.g., for a 64-bit memory address). The PCONFIG operations can then be performed in a similar manner as described above.

[0082] Additionally, in some embodiments, the PCONFIG operation can utilize wrapped object blobs for domain key programming. In this way, domain keys can be programmed without exposing the keys to the management software. In some embodiments, for example, an additional PCONFIG leaf function can be implemented to enable a key to be wrapped and then subsequently programmed to the memory protection controller 320 after being unwrapped.

[0083] The following provides example pseudo code for implementing the PCONFIG instruction:

[0084]

[0085]

[0086]

[0087]

[0088]

[0089]

[0090]

[0091]

[0092] Figure 4 A state machine 400 illustrating example embodiments of passworded memory protection. The state machine 400 illustrates the lifecycle of a domain protected using passworded memory protection. For example, the state machine 400 includes three protection states for a particular domain: an unprotected state 401, a default protection state 402, and a custom protection state 403. The state machine 400 transitions between these states based on key programming commands. For example, in some embodiments, the key programming commands associated with the key programming leaf of the PCONFIG instruction (e.g., as described in connection with Table 7) can be used to transition between the states of the state machine 400. Figure 3 and Table 7) can be used to transition between the states of the state machine 400.

[0093] After a system startup or reset, the initial state of the state machine 400 for a particular domain is the unprotected state 401, in which the domain is protected in plaintext (e.g., unencrypted) mode.

[0094] Once system active memory encryption is activated (e.g., using the memory encryption activation register (ME ACTIVATE MSR) of Table 2), the state machine 400 transitions to the default protection state 402, in which the domain is protected in default encrypted mode (e.g., using a default or global encryption key).

[0095] If a "set key" command (e.g., KD_SET_KEY_DIRECT or KD_SET_KEY_RANDOM of Table 7) is issued while in unprotected state 401 or default protection state 402, state machine 400 transitions to custom protection state 403 in which the domain is protected using a unique encryption key. If another "set key" command (e.g., KD_SET_KEY_DIRECT or KD_SET_KEY_RANDOM of Table 7) is issued while in custom protection state 403, a new key is programmed for the domain and state machine 400 remains in custom protection state 403.

[0096] If a "clear key" command (e.g., KD_CLEAR_KEY of Table 7) is issued while in custom protection state 403, the unique encryption key for the domain is cleared and state machine 400 transitions back to default protection state 402 in which the domain is protected in default encryption mode (e.g., using a default or global encryption key).

[0097] If a "no key" command (e.g., KD_NO_KEY of Table 7) is issued while in default protection state 402 or custom protection state 403, state machine 400 transitions back to unprotected state 401 in which the domain is protected in plaintext (e.g., unencrypted) mode.

[0098] Figure 5 A flow diagram 500 illustrating an example embodiment of password memory protection is shown. In some embodiments, flow diagram 500 can be implemented using the embodiments and functionality described throughout this disclosure.

[0099] The flow diagram can begin at block 502 with identifying a memory access operation for a particular memory location. The memory access operation, for example, can be a read operation to read data from the memory location, or a write operation to write data to the memory location.

[0100] The flowchart can then proceed to block 504 to determine whether the memory location is associated with a protected domain. For example, a "domain" can be viewed as a collection of resources associated with a particular workload or execution context, which can include any region of memory containing data associated with the workload. Moreover, in some cases, there can be multiple workloads associated with different tenants, users, and / or customers (e.g., customers of a cloud service provider). Thus, a protected domain can be defined as providing memory encryption protection for various workloads. Moreover, each protected domain can be configured using various protection modes, including a plaintext mode (e.g., unencrypted), a standard or default encryption mode (e.g., encrypted using a standard or default encryption key), and / or a custom encryption mode (e.g., encrypted using a unique encryption key). In this way, cryptographic isolation can be achieved for workloads of different tenants, users, and / or customers. In some embodiments, a protected domain can be created and / or configured using commands, instructions, and / or registers identifying the protection mode, encryption type, and / or encryption key for the protected domain.

[0101] If it is determined at block 504 that the memory location is not associated with a protected domain (and / or is protected using a plaintext mode), the flowchart can then proceed to block 512 to perform the memory access operation (e.g., as it would be normally performed).

[0102] If it is determined at block 504 that the memory location is associated with a protected domain (and / or is protected using a default or custom encryption mode), the flowchart can then proceed to block 506 to identify an encryption key associated with the protected domain. In some embodiments, an encryption type associated with the protected domain can also be identified.

[0103] The flowchart can then proceed to block 508 to perform a cryptographic operation (e.g., an encryption and / or decryption operation) on data associated with the memory location using the encryption key for the protected domain. For example, for a read operation, data can be obtained from the memory location and then decrypted using the identified encryption key. For a write operation, data to be written to the memory location can first be encrypted using the identified encryption key.

[0104] The flowchart can then proceed to block 510 to return a result of the cryptographic operation (e.g., the encryption and / or decryption operation), where the result of the cryptographic operation is used for the memory access operation. For example, decrypted data is returned for a read operation and encrypted data is returned for a write operation. The flowchart can then proceed to block 512 to perform the memory access operation (e.g., using the result of the cryptographic operation).

[0105] At this point, the flowchart can complete. However, in some embodiments, the flowchart can restart and / or can repeat certain blocks. For example, in some embodiments, the flowchart can restart at block 502 in order to continue processing additional memory access operations.

[0106] Example Computing Architecture

[0107] FIGS. 6-10 illustrate example computer architectures that can be used, in accordance with embodiments disclosed herein. For example, in embodiments, the computer architectures of FIGS. 6-10 can be used in conjunction with, and / or can be used to implement, the cryptographic memory protection engines, architectures, and functionality described throughout the present disclosure. Other computer architectures, system designs, and configurations known in the art for laptop computers, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a wide variety of systems or electronic devices capable of including a processor and / or other execution logic as disclosed herein are generally suitable.

[0108] Figure 6A FIG. 1 is a block diagram illustrating an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, according to embodiments of the application. Figure 6B FIG. 2 is a block diagram illustrating an exemplary embodiment of an in-order architecture core and an exemplary embodiment of a register renaming, out-of-order execution architecture core to be included in a processor, according to embodiments of the application. Figure 6A The solid lined boxes in the figure of -B illustrate a typical in-order pipeline and in-order core, while the dashed lined boxes represent a typical register renaming, out-of-order issue / execution pipeline and core. It should be noted that depending on the embodiment, various issues are made in sequence, in parallel, or in a different order, including but not limited to the order shown in this figure.

[0109] In Figure 6A In the processor pipeline 600 of -A, the processor pipeline 600 includes a fetch stage 602, a length decode stage 604, a decode stage 606, an allocation stage 608, a renaming stage 610, a scheduling (also known as dispatch or issue) stage 612, a register read / memory read stage 614, an execution stage 616, a write back / memory write stage 618, an exception handling stage 622, and a commit stage 624.

[0110] Figure 6BA processor core 690 is shown including a front end unit 630 coupled to an execution engine unit 650, both of which are coupled to a memory unit 670. The core 690 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 690 can be a special-purpose core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0111] The front end unit 630 includes a branch prediction unit 632 coupled to an instruction cache unit 634, which is coupled to an instruction translation lookaside buffer (TLB) 636, which is coupled to an instruction fetch unit 638, which is coupled to a decode unit 640. The decode unit 640 (or decoder) can decode instructions, and generate one or more micro-operations, microcode entries, microinstructions, other instructions, or other control signals from the decoded instructions as output. The decode unit 640 can be implemented with one or more logic, logic arrays, arrays of logic elements such as PALs, GALs, EPLDs, FPLAs, or other appropriate circuits. In one embodiment, the core 690 includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in the decode unit 640 or otherwise within the front end unit 630). The decode unit 640 is coupled to a rename / allocator unit 652 in the execution engine unit 650.

[0112] The execution engine unit 650 includes a rename / allocator unit 652 that is coupled to a retirement unit 654 and a set of one or more scheduler units 656. The scheduler units 656 are coupled to a physical register file unit 658. Each of the physical register file units 658 represents a set of one or more physical registers that store the values of integer, floating point, SIMD, and other data types. In one embodiment the physical register file units 658 also include a set of one or more vector registers for use in processing single instruction multiple data (SIMD) instructions. The scheduler unit 656 represents any number of different schedulers, including a central scheduler that receives and schedules instructions from various different execution units, a scheduler unit in each execution engine that receives and schedules instructions specifically for that execution engine, etc. The scheduler unit 656 is coupled to the physical register file unit 658 and a set of one or more execution units 660. Each of the execution units 660 is, in one embodiment, specialized in its operation. For instance, one execution unit can be configured to be a floating point unit capable of performing a wide range of integer and floating point operations using one or more of the physical registers. Another execution unit can be configured to be an integer only unit capable of performing only integer operations. Yet another execution unit can be configured to be a graphics and physics unit capable of performing graphics and physics operations. These are just examples of the many different configurations that the execution unit can have. The set of execution units 660 are coupled to a set of one or more memory access units 664. The memory access units 664 are coupled to the physical register file unit 658 and a memory object 670. The memory object 670 represents the entire system memory, some subset of the system memory, or a single memory. This memory object 670 is where data is stored prior to when a memory access instruction is processed against, where data is to be stored to once processed by a memory access instruction, etc.

[0113] The set of memory access units 664 is coupled to a memory unit 670, which includes a data TLB unit 672 coupled to a data cache unit 674, which is coupled to a level 2 (L2) cache unit 676. In one exemplary embodiment, the memory access units 664 can include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 672 in the memory unit 670. The instruction cache unit 634 is also coupled to the level 2 (L2) cache unit 676 in the memory unit 670. The L2 cache unit 676 is coupled to one or more other levels of cache, and ultimately to a main memory.

[0114] As an example, an exemplary register-renaming, out-of-order issue / execution core architecture can implement the pipeline 600 as follows: 1) the instruction fetch 638 performs the fetch and length decode stages 602 and 604, 2) the

[0115] The core 690 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set; and / or the ARM instruction set (with optional additional extensions such as NEON)). The core 690 can support a packed data instruction set extended (e.g., AVX1, AVX2) for use with the SSE datapath 615 in one embodiment.

[0116] It should be understood that a core can support multithreading (executing two or more parallel sets of threads) and can do so in any variety of ways including time sliced multithreading, simultaneous multithreading (where a single physical core provides virtual cores each time sliced between a number of threads in a given thread group), or a combination thereof (e.g., time sliced fetching and decoding and simultaneous multithreading at the execution level). Simultaneous multithreading is an example of hyperthreading technology.

[0117] Although register renaming is described in the context of out-of-order execution, it should be appreciated that register renaming can be used in in-order architectures. Although the processor shown in exhibits separate instruction and data cache units 634 / 674 and shared L2 cache unit 676, alternative embodiments can have a single internal cache for both instructions and data, such as for example a unified cache or multiple levels of cache between a processor and memory. In some embodiments, the system can include a combination of internal caches and external caches outside the core and / or processor. Or, all of the caching can be outside the core and / or processor.

[0118] In some embodiments, the platform configuration (PCONFIG) instructions described throughout this disclosure can be implemented using Figure 6A the processor architecture of Intel® Architecture Core®. For example, the instruction cache 634 can include PCONFIG instructions for configuring protected domains based on a particular memory region, protection mode, encryption key, and / or encryption type. Thus, the PCONFIG instructions can be fetched from the instruction cache 634 and decoded by the decoder 640, and the execution unit 662 can then program or configure the protected domains in the memory protection controller (e.g., the memory protection controller 206 of Intel® Architecture Core®). Figure 2

[0119] Figure 7 Figure 7 is a block diagram of a processor 700 that can have more than one core, that can have an integrated memory controller, and that can have integrated graphics according to embodiments of the application. Figure 7 The solid lined boxes in the figure represent a processor 700 with a single core 702A, a system agent 710, a set of one or more bus controller units 716, while the optional dashed lined boxes represent alternative processor 700 with additional cores 702A-N, a system agent unit 710, integrated memory controller units 714 in a set of one or more bus controller units 716, and optionally.

[0120] ​Thus, different implementations of the processor 700 can include: 1) a CPU with the special purpose logic 708 being integrated graphics and / or scientific (throughput) logic (which can include one or more cores), and the cores 702A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, combinations thereof); 2) a coprocessor with the cores 702A-N being a large number of special purpose cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor with the cores 702A-N being a large number of general purpose in-order cores. Thus, the processor 700 can be a general-purpose processor, coprocessor or a special-purpose processor, such as for example, a network or communication processor (NCP), compression engine, 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, and the like. The processor can be implemented on one or more chips. The processor 700 can be part of one or more buses of a

[0121] The memory hierarchy includes one or more levels of on-core cache, a set of shared cache units 706, and external memory (not shown) coupled to the set of integrated memory controller units 714. The set of shared cache units 706 can include one or more intermediate levels of cache, such as a level two (L2), level three (L3), level four (L4) or other level cache, a last level cache (LLC), and / or combinations thereof. Although the ring-based interconnect unit 712 interconnects the integrated graphics logic 708, the set of shared cache units 706, and the system agent unit 710 / integrated memory controller units 714 in one embodiment, alternative embodiments can use any number of publicly-known techniques to interconnect these units. In one embodiment, coherency is maintained between the one or more cache units 706 and the cores 702A-N.

[0122] In some embodiments, one or more of the cores 702A-N can enable multithreading. The system agent 710 includes those components coordinating and operating cores 702A-N. The system agent unit 710 can include for example a power control unit (PCU) and a display unit. The PCU can be or include the logic and components needed for adjusting the power state of the cores 702A-N, as well as the integrated graphics logic 708, and can include a built-in microcontroller that controls the power state of these components. The display unit is an on-board graphics processor that drives one or more externally connected displays.

[0123] The cores 702A-N can be homogeneous or heterogeneous in terms of architectural instruction sets; that is, two or more of the cores 702A-N can be capable of executing the same instruction set, while other cores can be capable of executing a subset or a different instruction set.

[0124] Referring now to the drawings Figure 8 illustrated is a block diagram of a system 800 in accordance with one embodiment of the present application. The system 800 can include one or more processors 810, 815, which are coupled to a controller hub 820. In one embodiment the controller hub 820 includes a graphics memory controller hub (GMCH) 890 and an input / output controller hub (IOH) 850, which can be separate chips. The GMCH 890 includes memory and graphics controllers to which are coupled memory 840 and a coprocessor 845 that are both external to the processor 810. The IOH 850 is coupled to the GMCH 890 and to an I / O device 860 that is also external to the processor 810. Alternatively, one or both of the memory and graphics controllers are integrated within the processor 810, memory 840 and coprocessor 845 are coupled to the processor 810 directly, and the controller hub 820 is a separate chip that is coupled to the processor 810 and to the IOH 850.

[0125] In Figure 8 optional nature of the additional processor 815 is illustrated in dashed line. Each processor 810, 815 can include one or more of the processing cores described herein and can be some version of the processor 700.

[0126] The memory 840 can be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of both. For at least one embodiment, the controller hub 820 communicates with the processor 810, 815 via a multi-lane bus, such as a frontside bus (FSB), point-to-point interface such as a QuickPath Interconnect (QPI), or similar communication link 895.

[0127] In one embodiment, the coprocessor 845 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, a GPGPU, embedded processor, etc. In one embodiment, controller hub 820 can include an integrated graphics accelerator.

[0128] There can be various differences between the physical resources 810, 815 in terms of micro-architecture, scheduling, priority levels, etc.

[0129] In one embodiment, the processor 810 executes instructions that control the general operation of the data processing unit. The instructions allocated to the processor 810 can include program instructions that promote processing of a coprocessor. The processor 810 recognizes these coprocessor instructions as a type that should be executed by the attached coprocessor 845. In response, the processor 810 issues these coprocessor instructions (or control signals that represent the coprocessor instructions) on a coprocessor bus or other interconnect, to the coprocessor 845. The coprocessor 845 receives and executes the received coprocessor instructions.

[0130] Referring now to the drawing figures in which Figure 9 , there is shown a block diagram of a more specific first exemplary system 900 in accordance with an embodiment of the present application. As Figure 9 indicated in FIG. 11C, the multiprocessor system 900 is a point-to-point interconnect system, and includes a first processor 970 and a second processor 980 coupled via a point-to-point interconnect 950. Each of the processors 970 and 980 can be some version of the processor 700. In one embodiment of the application, processors 970 and 980 are the processors 810 and 815, respectively, while the coprocessor 938 is the coprocessor 845. In another embodiment, processors 970 and 980 are the processor 810 and coprocessor 845, respectively.

[0131] The processors 970 and 980 are shown including integrated memory controller (IMC) units 972 and 982, respectively. The processor 970 also includes point-to-point (P-P) interfaces 976 and 978 as part of the bus controller units of the processor; similarly, the second processor 980 includes P-P interfaces 986 and 988. The processors 970, 980 can exchange information via a point-to-point (P-P) interface 950 using P-P interface circuits 978, 988. As Figure 9 indicated in FIG. 11C, the IMCs 972 and 982 couple the processors to respective memories, namely a memory 932 and a memory 934, which can be portions of main memory local to the respective processors.

[0132] The processors 970, 980 can each exchange information with a chipset 990 via individual P-P interfaces 952, 954 using point to point interface circuits 976, 994, 986, 998. Chipset 990 can optionally exchange information with a coprocessor 938 via a high-performance interface 939. In one embodiment, the coprocessor 938 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, etc.

[0133] A shared cache (not shown) can be included in either processor, or external to both processors but connected thereto via the P-P interconnect, such that if a processor is placed in a low power mode, the local cache information of either or both processors can be stored in the shared cache.

[0134] Chipset 990 can be coupled to first bus 916 via an interface 996. In one embodiment, first bus 916 can be a Peripheral Component Interconnect (PCI) bus or buses, or a bus using another communication protocol such as a processor bus, a

[0135] As Figure 9 shown in Figure 9 , various I / O devices 914 can be coupled to first bus 916 along with a bus bridge 918, which couples first bus 916 to second bus 920. In one embodiment, one or more additional processors 915 such as coprocessors, high throughput MIC processors, GPGPU's, accelerators such as, for example, graphics accelerators or digital signal processing (DSP) units, field programmable gate arrays, or any other processor, can be coupled to first bus 916. In one embodiment, second bus 920 can be a low pin count (LPC) bus. Various devices can be coupled to second bus 920 including, for example, a keyboard and / or mouse 922, communication device 927 and storage unit 928, which can include a disk drive or other mass storage device which can include instructions / code and data 930, for example. Further, an audio I / O 924 can be coupled to second bus 920. Note that other architectures are possible. For example, a system can implement a

[0136] Referring now to Figure 10 , shown is a block diagram of SoC 1000 in accordance with an embodiment of the present application. Figure 7 Like numbered items in Figure 10In this configuration, interconnect unit 1002 is coupled to: an application processor 1010, which includes a collection of one or more cores 1002A-N and a shared cache unit 1006; a system proxy unit 1010; a bus controller unit 1016; an integrated memory controller unit 1014; a group or one or more coprocessors 1020, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 1030; a direct memory access (DMA) unit 1032; and a display unit 1040 for coupling to one or more external displays. In one embodiment, coprocessor 1020 includes a dedicated processor, such as, for example, a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, or an embedded processor, etc.

[0137] The various embodiments of the mechanisms disclosed herein can be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the invention can be implemented as computer programs or program code executable on a programmable system including at least one processor, a storage system (including volatile and non-volatile memories and / or storage elements), at least one input device, and at least one output device.

[0138] Program code (such as, Figure 9 The code 930 shown is applied to input instructions 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 purposes of this application, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0139] The program code can be implemented using a high-level procedural programming language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used if needed. In fact, the mechanisms described in this document are not limited to any particular programming language. In any case, the language can be a compiled language or an interpreted language.

[0140] One or more aspects of at least one embodiment can be implemented by representational instructions stored on a machine-readable medium, representing various logics in a processor, which, when read by a machine, cause the machine to manufacture logic for performing the techniques described herein. Such representations, referred to as “IP cores,” can be stored on tangible machine-readable media and can be supplied to various customers or production facilities for loading into the manufacturing machines that actually manufacture the logic or processor.

[0141] Such machine-readable storage media can include, without limitation, non-transitory, tangible arrangements of articles 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 memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, phase change memories (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

[0142] Accordingly, embodiments of the application also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL), which defines structures, circuits, apparatuses, processors and / or system features described herein. Such embodiments can also be referred to as program products.

[0143] The flow and block diagrams in the multiple figures illustrate the architecture, functionality, and operations of possible implementations of systems, methods and computer program products according to aspects of the present disclosure. In this regard, each block in the flow and block diagrams can represent a code module, code segment, or code portion that comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block and combination of blocks in the block and flow diagrams can be implemented by a dedicated hardware-based system, or a combination of dedicated hardware and computer instructions.

[0144] The foregoing summary of the disclosure provides an overview of features of several embodiments so that a person of ordinary skill in the art can better understand aspects of the disclosure. Those of ordinary skill in the art will appreciate that they can readily use the disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and / or achieving the same results in a manner that is different from those expressly disclosed herein. Those of ordinary skill in the art will also recognize from the disclosure a large number of equivalent structures and functions, and equivalent solutions to problems mentioned herein. Such equivalents are intended to be encompassed by the spirit and scope of this disclosure.

[0145] All or portions of any hardware element(s) disclosed herein can be provided as a system on a chip (SoC) including a central processing unit (CPU) package. SoC refers to an integrated circuit (IC) that integrates the components of a computer or other electronic systems into a single chip. SoC can contain digital, analog, mixed-signal, and radio-frequency functions all provided on a single chip substrate. Other embodiments can include a multi-chip module (MCM), where multiple chips are located within a single electronic package and configured to interact closely with each other via the electronic package. In various other embodiments, the computing functionality disclosed herein can be implemented in one or more silicon cores in application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and other semiconductor chips.

[0146] As used throughout this specification, the term "processor" or "microprocessor" should be understood as including not only a traditional microprocessor (such as, for example, an Intel® x86 and x64 architecture leading the industry), but also a graphics processor, a matrix processor, and any ASIC, FPGA, microcontroller, digital signal processor (DSP), programmable logic device, programmable logic array (PLA), microcode, instruction set, emulated or virtual machine processor, or any similar "Turing-complete" device, combination of devices, or logic elements (hardware or software) that allow the execution of instructions. As used throughout this specification, the term "processor" or "microprocessor" should be understood as including not only a traditional microprocessor (such as, for example, an Intel® x86 and x64 architecture leading the industry), but also a graphics processor, a matrix processor, and any ASIC, FPGA, microcontroller, digital signal processor (DSP), programmable logic device, programmable logic array (PLA), microcode, instruction set, emulated or virtual machine processor, or any similar "Turing-complete" device, combination of devices, or logic elements (hardware or software) that allow the execution of instructions.

[0147] It should also be noted that in certain embodiments, some of the components can be omitted or consolidated. In a general sense, the arrangement depicted in the drawings should be understood as being illustrative only since other configurations can also be used, e.g., an SoC can be used in place of a CPU, etc. In general, the drawings and description are to be considered in a demonstrative sense only. Similarly, while the term "processor" can be used herein to refer to any hardware system, device, or sub-system that is configured to process data, the term should not be construed to refer only to traditional computers or processors as understood in an information technology (IT) context. Rather, a processor can include one or more semiconductor devices, such as a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a digital signal processor (DSP), a graphics processor, a matrix processor, a programmable logic device (PLD), a programmable logic array (PLA), a microcoded implementation, an instruction set, an emulated or virtual machine processor, or any similar "Turing-complete" device, combination of devices, or logic elements (hardware or software) that allow the execution of instructions.

[0148] In general terms, any suitably configured processor can execute instructions associated with data or microcode to perform the operations detailed herein. Any processor disclosed herein can transform an element or an article (for example, data) from one state or thing to another state or thing. In another example, some of the activities outlined herein can be implemented with fixed logic or programmable logic (for example, software and / or computer instructions executed by a processor) and the identified elements can be some type of a programmable processor, programmable digital logic (for example, a field programmable gate array (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM)) or an ASIC that includes digital logic, software, code, electronic instructions, flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or optical cards, other types of machine-readable media suitable for storing electronic instructions, any suitable combination thereof.

[0149] In operation, storage can store information in any suitable type of tangible, non-transitory storage medium (for example, random access memory (RAM), read only memory (ROM), a field programmable gate array (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), or microcode), software, hardware (for example, processor instructions or microcode), or any other suitable component, device, element, or object at a suitable time, based on a particular need or implementation. Additionally, information being tracked, sent, received, or stored in a processor can be provided to, in, or from any database, register, table, cache, queue, control list, or storage structure, all of which can be referenced at any suitable time. Any of the memory or storage elements disclosed herein should be construed as being encompassed within the broad term "memory" and "storage" as appropriate. Non-transitory storage media herein expressly include any non-transitory dedicated or programmable hardware configured to provide the disclosed operations or cause a processor to perform the disclosed operations. Non-transitory storage media also expressly include a processor having hardware encoded instructions stored thereon and optionally having microcode instructions or sequences encoded in hardware, firmware, or software.

[0150] Computer program logic implementing all or part of the functionality previously described herein can be embodied in various forms, including, but in no way limited to, a hardware description language, a source code form, a computer executable form, a machine instruction, or a plurality of machine instructions, and various intermediate forms (e.g., processed by an HDL processor, assembler, compiler, linker, or locator). In an example, source code includes a series of computer program instructions implemented in various programming languages, such as an object code, an assembly language, or a high-level language such as OpenCL, FORTRAN, C, C++, JAVA, or HTML for use with various operating systems or operating environments. The source code can define and use various data structures and communication messages. The source code can be in a computer executable form (e.g., via an interpreter), or the source code can be converted (e.g., via a translator, assembler, or compiler) into a computer executable form, or converted into an intermediate form (such as byte code) which is executed by an interpreter, or converted into a high-level language execution code which is executed by a virtual machine. Each of these forms can be generated from appropriate source code using tools from the appropriate stage of processing. Any of the above forms can be generated, stored, and executed by processing devices of suitable forms including, but in no way limited to, a digital signal processor, a parallel computer, a symmetric multiprocessor, a single-board computer, a microprocessor, a microcontroller, a processor array, a field programmable gate array, an application specific integrated circuit, or a programmable logic device. When a source code is generated, it can be assembled, compiled, or interpreted.

[0151] In one example, any number of the circuits in the figures can be implemented on a board of an associated electronic device. The board can be a general board that can hold various components of the internal electronic system of the electronic device and can further provide connectors for other peripheral devices. More specifically, the board can provide the electrical connections by which the other components of the system can communicate electrically. An appropriate processor and memory coupled to the board can be used to process and store data and instructions for the other components. Other components, such as external storage, additional sensors, controllers for audio / video displays, and peripheral devices can be attached via cables, as plug-in cards, or can be integrated to the board of the electronic device. In another example, the circuits in the figures can be implemented as a standalone module (e.g., a device having associated components and circuitry configured to perform a specific application or function) or implemented as plug-in modules into a specific hardware of an electronic device.

[0152] Note that for numerous examples provided herein, interaction can be described in terms of two, three, four, or more electrical components. However, this has been done for purposes of clarity and example only. It should be appreciated that the system can be consolidated in any suitable manner without deviating from the described example. With similar substitutions, any of the elements of the system illustrated in the figures can also be combined or re-arranged without deviating from the broad scope of the disclosure. In some cases, it can be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of electrical elements. It should be appreciated that the electrical circuits of the figures and the teachings thereof can be scaled as appropriate. As such, the examples provided should not limit the scope of electrical circuits potentially applied to a multitude of other architectures, both current and future. The examples provided should not limit the broad teachings of the electrical circuits as potentially applied to a multitude of other architectures within the scope of the disclosure.

[0153] Numerous other changes, modifications, variations, alterations, and permutations of the methods and apparatuses described herein can be made and will be apparent to those skilled in the art, and the disclosure encompasses each and every such change, modification, variation, alteration, and permutation.

[0154] Example Implementations

[0155] The following examples relate to embodiments described throughout the present disclosure.

[0156] One or more embodiments can include an apparatus comprising: a processor to execute one or more instructions, wherein the one or more instructions comprise a memory access operation associated with a memory location of a memory; a memory encryption controller to: identify the memory access operation associated with the memory location of the memory; determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identify an encryption key associated with the protected domain; perform a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

[0157] In one example embodiment of the apparatus: the memory access operation comprises a memory read operation; and the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to: obtain the data from the memory location of the memory; and decrypt the data based on the encryption key associated with the protected domain.

[0158] In one example embodiment of the apparatus: the memory access operation comprises a memory write operation; and the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to: encrypt the data based on an encryption key associated with the protected domain, wherein a result of the cryptographic operation is to be written to a memory location of the memory.

[0159] In one example embodiment of the apparatus, the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to: identify an encryption type associated with the protected domain, wherein a plurality of protected domains are associated with a plurality of encryption types; and perform the cryptographic operation based on the encryption type associated with the protected domain.

[0160] In one example embodiment of the apparatus, the plurality of protected domains comprises a plurality of execution contexts; and each of the plurality of protected domains comprises a particular execution context of the plurality of execution contexts.

[0161] In one example embodiment of the apparatus, the plurality of protected domains is further associated with a plurality of encryption keys; and each of the plurality of protected domains is associated with a particular encryption key of the plurality of encryption keys.

[0162] In one example embodiment of the apparatus, the plurality of protected domains is further associated with a plurality of users; and each of the plurality of protected domains is associated with a particular user of the plurality of users.

[0163] In one example embodiment of the apparatus, the memory encryption controller is further to: identify a command to add a second protected domain to the plurality of protected domains; identify a second protected memory region associated with the second protected domain; identify a second encryption key associated with the second protected domain; and configure the second protected domain based on the second protected memory region and the second encryption key.

[0164] In one example embodiment of the apparatus, the processor further comprises: an instruction cache comprising platform configuration instructions, wherein the platform configuration instructions comprise the command to add the second protected domain to the plurality of protected domains; a decoder to decode the platform configuration instructions; and an execution unit to program the second protected domain in the memory encryption controller.

[0165] In one example embodiment of the apparatus, the memory encryption controller is further to: determine a protection mode associated with the second protected domain; and configure the second protected domain based on the protection mode.

[0166] In one example embodiment of the apparatus, the protection mode includes: a clear mode; a default encryption mode; or a custom encryption mode.

[0167] One or more embodiments can include at least one machine accessible storage medium having instructions stored thereon, wherein when the instructions are executed on a machine, the instructions cause the machine to: identify a memory access operation associated with a memory location of a memory; determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identify an encryption key associated with the protected domain; perform a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

[0168] In one example embodiment of the storage medium: the memory access operation includes a memory read operation; and the instructions that cause the machine to perform a cryptographic operation on data associated with the memory access operation further cause the machine to: obtain the data from the memory location of the memory; and decrypt the data based on the encryption key associated with the protected domain.

[0169] In one example embodiment of the storage medium: the memory access operation includes a memory write operation; and the instructions that cause the machine to perform a cryptographic operation on data associated with the memory access operation further cause the machine to: encrypt the data based on the encryption key associated with the protected domain, wherein the result of the cryptographic operation is to be written to the memory location of the memory.

[0170] In one example embodiment of the storage medium, the instructions that cause the machine to perform a cryptographic operation on data associated with the memory access operation further cause the machine to: identify an encryption type associated with the protected domain, wherein the plurality of protected domains is associated with a plurality of encryption types; and perform the cryptographic operation based on the encryption type associated with the protected domain.

[0171] In one example embodiment of the storage medium, the plurality of protected domains includes a plurality of execution contexts; and each protected domain of the plurality of protected domains includes a particular execution context of the plurality of execution contexts.

[0172] In one example embodiment of the storage medium, the plurality of protected domains is further associated with a plurality of encryption keys; and each protected domain of the plurality of protected domains is associated with a particular encryption key of the plurality of encryption keys.

[0173] In one example embodiment of the storage medium: the plurality of protected domains is further associated with a plurality of users; and each protected domain of the plurality of protected domains is associated with a particular user of the plurality of users.

[0174] In one example embodiment of the storage medium, the instructions further cause the machine to: identify a command to add a second protected domain to the plurality of protected domains; identify a second protected memory region associated with the second protected domain; identify a second encryption key associated with the second protected domain; and configure the second protected domain based on the second protected memory region and the second encryption key.

[0175] In one example embodiment of the storage medium, the instructions further cause the machine to: determine a protection mode associated with the second protected domain; and configure the second protected domain based on the protection mode.

[0176] In one example embodiment of the storage medium, the protection mode comprises: a clear mode; a standard encryption mode; or a custom encryption mode.

[0177] One or more embodiments can include a system comprising: a memory; a processor to execute one or more instructions, wherein the one or more instructions comprise a memory access operation associated with a memory location of the memory; a memory encryption controller to: identify the memory access operation associated with the memory location of the memory; determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identify an encryption key associated with the protected domain; perform a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

[0178] In one example embodiment of the system: the plurality of protected domains is further associated with a plurality of users of a cloud service provider; and each protected domain of the plurality of protected domains is associated with a particular user of the plurality of users.

[0179] In one example embodiment of the system, the memory comprises a solid state memory to provide persistent data storage.

[0180] One or more embodiments can include a method comprising: identifying a memory access operation associated with a memory location of a memory; determining that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identifying a cryptographic key associated with the protected domain; performing a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the cryptographic key associated with the protected domain; and returning a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

[0181] In one example embodiment of the method, the method further comprises: identifying a command to add a second protected domain to the plurality of protected domains; identifying a second protected memory region associated with the second protected domain; identifying a second cryptographic key associated with the second protected domain; and configuring the second protected domain based on the second protected memory region and the second cryptographic key.

Claims

1. An apparatus comprising: a processor to execute one or more instructions, wherein the one or more instructions comprise a memory access operation associated with a memory location of a memory, wherein the processor comprises a plurality of configuration registers to configure usage of a memory encryption controller, wherein the plurality of configuration registers comprise at least: a first configuration register to specify at least a capability of the memory encryption controller, the capability comprising an indication of a supported encryption algorithm, a maximum number of keys, and a maximum number of bits per key identifier; a second configuration register to specify at least a read-only lock activation, a memory encryption enablement, and a default encryption algorithm; and a third configuration register to identify a memory address to be excluded from memory encryption protection; and the memory encryption controller to: identify the memory access operation associated with the memory location of the memory; determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identify an encryption key associated with the protected domain; perform a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

2. The apparatus of claim 1, wherein: the memory access operation comprises a memory read operation; and the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to: obtain the data from the memory location of the memory; and decrypt the data based on the encryption key associated with the protected domain.

3. The apparatus of claim 1, wherein: the memory access operation comprises a memory write operation; and the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to encrypt the data based on the encryption key associated with the protected domain, wherein the result of the cryptographic operation is to be written to the memory location of the memory.

4. The apparatus of claim 1, wherein, the memory encryption controller to perform the cryptographic operation on the data associated with the memory access operation is further to: identify an encryption type associated with the protected domain, wherein the plurality of protected domains are associated with a plurality of encryption types; and perform the cryptographic operation based on the encryption type associated with the protected domain.

5. The apparatus of claim 1, wherein: the plurality of protected domains comprise a plurality of execution contexts; and the first configuration register is to specify at least a capability of the memory encryption controller, the capability comprising an indication of a supported encryption algorithm, a maximum number of keys, and a maximum number of bits per key identifier. Each protected domain of the plurality of protected domains includes a particular execution context of the plurality of execution contexts.

6. The apparatus of claim 1, wherein: The plurality of protected domains are further associated with a plurality of encryption keys; and Each protected domain of the plurality of protected domains is associated with a particular encryption key of the plurality of encryption keys.

7. The apparatus of claim 6, wherein: The plurality of protected domains are further associated with a plurality of users; and Each protected domain of the plurality of protected domains is associated with a particular user of the plurality of users.

8. The apparatus of claim 1, wherein, The memory encryption controller is further to: identify a command to add a second protected domain to the plurality of protected domains; identify a second protected memory region associated with the second protected domain; identify a second encryption key associated with the second protected domain; and configure the second protected domain based on the second protected memory region and the second encryption key. The processor further includes:

9. The apparatus of claim 8, wherein, an instruction cache including platform configuration instructions, wherein the platform configuration instructions include the command to add the second protected domain to the plurality of protected domains; a decoder to decode the platform configuration instructions; and an execution unit to program the second protected domain in the memory encryption controller. The memory encryption controller is further to:

10. The apparatus of claim 8, wherein, determine a protection mode associated with the second protected domain; and configure the second protected domain based on the protection mode. The protection mode includes: a plaintext mode; a default encryption mode; or a custom encryption mode.

11. The apparatus of claim 10, wherein, 12. A system comprising: a memory; a processor to execute one or more instructions, wherein the one or more instructions include a memory access operation associated with a memory location of the memory, wherein the processor includes a plurality of configuration registers to configure use of a memory encryption controller, wherein the plurality of configuration registers includes at least: a first configuration register to specify at least a capability of the memory encryption controller, the capability including an indication of a supported encryption algorithm, a maximum number of keys, and a maximum number of bits for each key identifier; a second configuration register to specify at least a read-only lock activation, a memory encryption enable, and a default encryption algorithm; and a third configuration register to identify a memory address to exclude from memory encryption protection; and; a memory encryption controller to: identify the memory access operation associated with the memory location of the memory; determine that the memory location is associated with a protected domain, wherein the protected domain is associated with a protected memory region of the memory, and wherein the protected domain is identified from a plurality of protected domains associated with a plurality of protected memory regions of the memory; identify an encryption key associated with the protected domain; and configure the protected domain based on the encryption key. performing a cryptographic operation on data associated with the memory access operation, wherein the cryptographic operation is performed based on the encryption key associated with the protected domain; and returning a result of the cryptographic operation, wherein the result of the cryptographic operation is to be used for the memory access operation.

13. The system of claim 12, wherein, the plurality of protected domains are further associated with a plurality of users of a cloud service provider; and each protected domain of the plurality of protected domains is associated with a particular user of the plurality of users.

14. The system of claim 12, wherein, the memory comprises a solid state memory for providing persistent data storage.

Images