US20190004973A1 - Multi-key cryptographic memory protection - Google Patents

Multi-key cryptographic memory protection Download PDF

Info

Publication number
US20190004973A1
US20190004973A1 US15/635,548 US201715635548A US2019004973A1 US 20190004973 A1 US20190004973 A1 US 20190004973A1 US 201715635548 A US201715635548 A US 201715635548A US 2019004973 A1 US2019004973 A1 US 2019004973A1
Authority
US
United States
Prior art keywords
memory
protected
encryption
domain
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US15/635,548
Other languages
English (en)
Inventor
Siddhartha Chhabra
Hormuzd M. Khosravi
Gideon Gerzon
Barry E. Huntley
Gilbert Neiger
Ido Ouziel
Baiju Patel
Ravi L. Sahita
Amy L. Santoni
Ioannis T. Schoinas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Priority to US15/635,548 priority Critical patent/US20190004973A1/en
Assigned to INTEL CORPORATION reassignment INTEL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHHABRA, Siddhartha, OUZIEL, IDO, GERZON, GIDEON, HUNTLEY, BARRY E., SAHITA, RAVI L., KHOSRAVI, HORMUZD M., NEIGER, GILBERT, SANTONI, AMY L., SCHOINAS, IOANNIS T., PATEL, BAIJU
Priority to DE102018004290.2A priority patent/DE102018004290A1/de
Priority to CN201810622316.2A priority patent/CN109145611A/zh
Priority to CN202211117534.3A priority patent/CN115470530A/zh
Publication of US20190004973A1 publication Critical patent/US20190004973A1/en
Priority to US17/222,722 priority patent/US20210224202A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement

Definitions

  • This disclosure relates in general to the field of computer security, and more particularly, though not exclusively, to cryptographic memory protection.
  • disk encryption can be used to protect data residing on a persistent disk storage device
  • network encryption can be used to protect data transmitted over a network.
  • Data residing in system memory is often stored and/or transmitted in plaintext and thus may be vulnerable to attacks.
  • FIG. 1 illustrates a schematic diagram of an example computing system in accordance with certain embodiments.
  • FIG. 2 illustrates an example embodiment of a multi-key cryptographic memory protection system.
  • FIG. 3 illustrates an example of configuring a protected domain using a processor instruction.
  • FIG. 4 illustrates a state machine for an example embodiment of cryptographic memory protection.
  • FIG. 5 illustrates a flowchart for an example embodiment of cryptographic memory protection.
  • FIGS. 6A-B , 7 , 8 , 9 , and 10 illustrate example computer architectures that can be used in accordance with embodiments disclosed herein.
  • disk encryption can be used to protect data residing on a persistent disk storage device
  • network encryption can be used to protect data transmitted over a network.
  • Data residing in system memory is often stored and/or transmitted in plaintext and thus may be vulnerable to attacks.
  • attackers can use a variety of techniques to maliciously access data stored in memory, such as bus scanning and/or memory scanning, among other examples.
  • these malicious techniques could be used to access memory locations containing encryption keys that are stored in plaintext, such as encryption keys used for disk encryption, thus facilitating further unauthorized access to other data that is protected by encryption.
  • this disclosure describes various embodiments of cryptographic memory protection.
  • the described embodiments can be used to provide memory encryption protection, thus providing an additional layer of security by plugging the hole associated with unprotected or insecure memory.
  • memory encryption may be provided by implementing a cryptographic engine or controller on the memory path or memory bus. In this manner, data can be encrypted and protected while residing in memory and during transmission to and from memory (e.g., when transmitted from memory to a processor, and vice versa, via the memory bus or memory path).
  • memory encryption may be a necessity for certain users and/or use cases, uniform memory protection across a computing system may be insufficient in certain circumstances.
  • a cloud service provider often hosts data and/or applications—or workloads—for multiple customers or third parties.
  • the cloud service provider could use memory encryption to provide uniform protection of all hosted customer workloads, for example, using a single encryption key.
  • a cloud service provider and/or its customers may be averse to sharing the same encryption key for all customers. Rather, the cloud service provider and/or its customers may prefer to have memory encryption provided on a per-tenant basis (e.g., per customer or per virtual machine) to ensure that each customer workload is separately protected and isolated using a unique encryption key.
  • 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.
  • a user or tenant e.g., a cloud service provider or customer
  • memory encryption can be provided and configured separately for different tenants, customers, or protection domains.
  • a “domain” may be viewed as a collection of resources associated with a particular workload, which may include any regions of memory containing data associated with the workload.
  • memory encryption can be configured separately for each domain, thus allowing each domain or workload to be protected using a separate encryption key.
  • cryptographic isolation can be achieved for workloads of different tenants, customers, or users.
  • the workloads can also be isolated from management software (e.g., of a cloud service provider), such as a virtual machine manager.
  • Domains can also be configured in plaintext mode, as it may be undesirable in certain circumstances to perform memory encryption for a particular domain (e.g., to avoid performance impacts of memory encryption, share memory (and I/O) between different entities, reclaim memory, and so forth).
  • 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 (NVDIMM), direct access storage (DAS) memory, and so forth).
  • SCM storage class memory
  • NVDIMM non-volatile dual in-line memory modules
  • DAS direct access storage
  • the described embodiments may be used to protect data using memory encryption when memory is used for persistent data storage.
  • the described embodiments provide numerous features and advantages, including cryptographic memory protection (e.g., via a cryptographic engine on the memory path), multi-key encryption support, and software programmable configurability and flexibility. These features enable isolated encryption protection using separate keys for different domains, memory regions, workloads, tenants, and/or customers, thus providing support for multiple cryptographically-isolated protection domains. In this manner, the described embodiments can be used to satisfy heightened 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 leverage the performance benefits of using memory for persistent data storage (e.g., NVDIMM or other storage class memory (SCM)) without sacrificing security.
  • NVDIMM persistent data storage
  • SCM storage class memory
  • RAM random access memory
  • SDRAM synchronous dynamic RAM
  • SRAM static RAM
  • non-volatile memory e.g., storage class memory (SCM), direct access storage (DAS) memory, non-volatile dual in-line memory modules (NVDIMM), and/or other forms of flash or solid-state storage
  • SCM storage class memory
  • DAS direct access storage
  • NVDIMM non-volatile dual in-line memory modules
  • 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 in the future as desired.
  • the described embodiments could be scaled to provide multi-domain memory encryption for a computing system with 64 terabytes (TB) of addressable physical memory.
  • the described embodiments could be scaled even further, for example, through extensions to physical addresses (PAs) and/or cache tagging.
  • PAs physical addresses
  • FIG. 1 illustrates a schematic diagram of an example computing system 100 .
  • system 100 and/or its underlying components may include the cryptographic memory protection functionality described throughout this disclosure.
  • a cloud service provider 120 often hosts workloads 130 (e.g., data and/or applications) for multiple customers or third parties.
  • workloads 130 e.g., data and/or applications
  • a cloud service provider 120 may implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thus ensuring that each customer workload 130 is separately 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 . Example embodiments of cryptographic memory protection are described further throughout this disclosure in connection with the remaining FIGURES.
  • Edge devices 110 may include any equipment and/or devices deployed or connected near the “edge” of a communication system 100 .
  • 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 other examples.
  • Edge devices 110 may 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 .
  • certain edge devices 110 may include the cryptographic memory protection functionality described throughout this disclosure.
  • End-user devices 112 may include any device that enables or facilitates user interaction with computing system 100 , including, for example, desktop computers, laptops, tablets, mobile phones and other mobile devices, and wearable devices (e.g., smart watches, smart glasses, headsets), among other examples.
  • desktop computers laptops, tablets, mobile phones and other mobile devices
  • wearable devices e.g., smart watches, smart glasses, headsets
  • IoT devices 114 may include any device capable of communicating and/or participating in an Internet-of-Things (IoT) system or network.
  • IoT systems may refer to new or improved ad-hoc systems and networks composed of multiple different devices (e.g., IoT devices 114 ) interoperating and synergizing for a particular application or use case.
  • Such ad-hoc systems are emerging as more and more products and equipment evolve to become “smart,” meaning they are controlled or monitored by computer processors and are capable of communicating with other devices.
  • an IoT device 114 may include a computer processor and/or communication interface to allow interoperation with other components of system 100 , such as with cloud services 120 and/or other edge devices 110 .
  • IoT devices 114 may be “greenfield” devices that are developed with IoT capabilities from the ground-up, or “brownfield” devices that are created by integrating IoT capabilities into existing legacy devices that were initially developed without IoT capabilities.
  • IoT devices 114 may be built from sensors and communication modules integrated in or attached to “things,” such as equipment, toys, tools, vehicles, living things (e.g., plants, animals, humans), and so forth.
  • certain IoT devices 114 may rely on intermediary components, such as edge gateways or routers 116 , to communicate with the various components of system 100 .
  • IoT devices 114 may include various types of sensors for monitoring, detecting, measuring, and generating sensor data and signals associated with characteristics of their environment.
  • a given sensor may be configured to detect one or more respective characteristics, such as movement, weight, physical contact, biometric properties, temperature, wind, noise, light, position, humidity, radiation, liquid, specific chemical compounds, battery life, wireless signals, computer communications, and bandwidth, among other examples.
  • Sensors can include physical sensors (e.g., physical monitoring components) and virtual sensors (e.g., software-based monitoring components).
  • IoT devices 114 may also include actuators to perform various actions in their respective environments.
  • an actuator may be used to selectively activate certain functionality, such as toggling the power or operation of a security system (e.g., alarm, camera, locks) or household appliance (e.g., audio system, lighting, HVAC appliances, garage doors), among other examples.
  • a security system e.g., alarm, camera, locks
  • household appliance e.g., audio system, lighting, HVAC appliances, garage doors
  • IoT devices 114 may include, for example, any type of equipment and/or devices associated with any type of system 100 and/or industry, including transportation (e.g., automobile, airlines), industrial manufacturing, energy (e.g., power plants), telecommunications (e.g., Internet, cellular, and television service providers), medical (e.g., healthcare, pharmaceutical), food processing, and/or retail industries, among others.
  • transportation e.g., automobile, airlines
  • industrial manufacturing e.g., energy (e.g., power plants)
  • telecommunications e.g., Internet, cellular, and television service providers
  • medical e.g., healthcare, pharmaceutical
  • food processing e.g., food processing, and/or retail industries, among others.
  • IoT devices 114 may include equipment and devices associated with aircrafts, automobiles, or vessels, such as navigation systems, autonomous flight or driving systems, traffic sensors and controllers, and/or any internal mechanical or electrical components that are monitored by sensors (e.g., engines). IoT devices 114 may also include equipment, devices, and/or infrastructure associated with industrial manufacturing and production, shipping (e.g., cargo tracking), communications networks (e.g., gateways, routers, servers, cellular towers), server farms, electrical power plants, wind farms, oil and gas pipelines, water treatment and distribution, wastewater collection and treatment, and weather monitoring (e.g., temperature, wind, and humidity sensors), among other examples.
  • shipping e.g., cargo tracking
  • communications networks e.g., gateways, routers, servers, cellular towers
  • server farms electrical power plants
  • wind farms oil and gas pipelines
  • water treatment and distribution e.g., water treatment and distribution
  • wastewater collection and treatment e.g., temperature, wind, and humidity sensors
  • IoT devices 114 may also include, for example, any type of “smart” device or system, such as smart entertainment systems (e.g., televisions, audio systems, videogame systems), smart household or office appliances (e.g., heat-ventilation-air-conditioning (HVAC) appliances, refrigerators, washers and dryers, coffee brewers), power control systems (e.g., automatic electricity, light, and HVAC controls), security systems (e.g., alarms, locks, cameras, motion detectors, fingerprint scanners, facial recognition systems), and other home automation systems, among other examples.
  • IoT devices 114 can be statically located, such as mounted on a building, wall, floor, ground, lamppost, sign, water tower, or any other fixed or static structure.
  • IoT devices 114 can also be mobile, such as devices in vehicles or aircrafts, drones, packages (e.g., for tracking cargo), mobile devices, and wearable devices, among other examples.
  • an IoT device 114 can also be any type of edge device 110 , including end-user devices 112 and edge gateways and routers 116 .
  • Edge gateways and/or routers 116 may be used to facilitate communication to and from edge devices 110 .
  • gateways 116 may provide communication capabilities to existing legacy devices that were initially developed without any such capabilities (e.g., “brownfield” IoT devices).
  • Gateways 116 can also be utilized to extend the geographical reach of edge devices 110 with short-range, proprietary, or otherwise limited communication capabilities, such as IoT devices 114 with Bluetooth or ZigBee communication capabilities.
  • gateways 116 can serve as intermediaries between IoT devices 114 and remote networks or services, by providing a front-haul to the IoT devices 114 using their native communication capabilities (e.g., Bluetooth, ZigBee), and providing a back-haul to other networks 150 and/or cloud services 120 using another wired or wireless communication medium (e.g., Ethernet, Wi-Fi, cellular).
  • a gateway 116 may be implemented by a dedicated gateway device, or by a general purpose device, such as another IoT device 114 , end-user device 112 , or other type of edge device 110 .
  • gateways 116 may also implement certain network management and/or application functionality (e.g., IoT management and/or IoT application functionality for IoT devices 114 ), either separately or in conjunction with other components, such as cloud services 120 and/or other edge devices 110 .
  • network management and/or application functionality e.g., IoT management and/or IoT application functionality for IoT devices 114
  • configuration parameters and/or application logic may be pushed or pulled to or 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.
  • Cloud services 120 may include services that are hosted remotely over a network 150 , or in the “cloud.” In some embodiments, for example, cloud services 120 may be remotely hosted on servers in datacenter (e.g., application servers or database servers). Cloud services 120 may include any services that can be utilized by or for edge devices 110 , including but not limited to, data and application hosting, computational services (e.g., data analytics, searching, diagnostics and fault management), security services (e.g., surveillance, alarms, user authentication), mapping and navigation, geolocation services, network or infrastructure management, IoT application and management services, payment processing, audio and video streaming, messaging, social networking, news, and weather, among other examples. Moreover, in some embodiments, certain cloud services 120 may include the cryptographic memory protection functionality described throughout this disclosure.
  • a cloud service provider 120 often hosts workloads 130 (e.g., data and/or applications) for multiple customers or third parties. Accordingly, in some embodiments, a cloud service provider 120 may implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thus ensuring that each customer workload 130 is separately protected and isolated using a unique encryption key.
  • workloads 130 e.g., data and/or applications
  • a cloud service provider 120 may implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thus ensuring that each customer workload 130 is separately protected and isolated using a unique encryption key.
  • Network 150 may be used to facilitate communication between the components of computing system 100 .
  • edge devices 110 such as end-user devices 112 and IoT devices 114 , may use network 150 to communicate with each other and/or access one or more remote cloud services 120 .
  • Network 150 may 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.
  • Any, all, or some of the computing devices of system 100 may be adapted to execute any operating system, including Linux or other UNIX-based operating systems, Microsoft Windows, Windows Server, MacOS, Apple iOS, Google Android, or any customized and/or proprietary operating system, along with virtual machines adapted to virtualize execution of a particular operating system.
  • any operating system including Linux or other UNIX-based operating systems, Microsoft Windows, Windows Server, MacOS, Apple iOS, Google Android, or any customized and/or proprietary operating system, along with virtual machines adapted to virtualize execution of a particular operating system.
  • FIG. 1 is described as containing or being associated with a plurality of elements, not all elements illustrated within system 100 of FIG. 1 may be utilized in each alternative implementation of the present disclosure. Additionally, one or more of the elements described in connection with the examples of FIG. 1 may be located external to system 100 , while in other instances, certain elements may be included within or as a portion of one or more of the other described elements, as well as other elements not described in the illustrated implementation. Further, certain elements illustrated in FIG. 1 may be combined with other components, as well as used for alternative or additional purposes in addition to those purposes described herein.
  • FIG. 2 illustrates an example embodiment of a multi-key cryptographic memory protection system 200 .
  • memory protection system 200 includes processor 202 , system agent 204 , and memory 210 .
  • memory protection system 200 provides cryptographic protection of data stored on memory 210 .
  • Processor 202 may 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 logic or processing elements operable to execute instructions, whether loaded from memory or implemented directly in hardware, such as a microprocessor, digital signal processor, field-programmable gate array (FPGA), graphics processing unit (GPU), programmable logic array (PLA), or application-specific integrated circuit (ASIC), among other examples.
  • processor 202 and/or memory protection system 200 may be implemented using the computer architectures of FIGS. 6-10 .
  • Memory 210 may be used to store information, such as code and/or data used by processor 202 during execution, and/or persistent data associated with an application or user of system 200 .
  • Memory 210 may include any type or combination of components 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 storage (DAS) memory, non-volatile dual in-line memory modules (NVDIMM), and/or other forms of flash or solid-state storage).
  • RAM random access memory
  • DRAM dynamic RAM
  • SDRAM synchronous dynamic RAM
  • SRAM static RAM
  • non-volatile memory e.g., storage class memory (SCM), direct access storage (DAS) memory, non-volatile dual in-line memory modules (NVDIMM), and/or other forms of flash or solid-state storage.
  • SCM storage class memory
  • System agent 204 may be used to provide various functions for processor 202 , such as managing access to memory 210 and/or other resources of system 200 .
  • system agent 204 includes a memory controller 208 to control and/or manage access to memory 210 of system 200 .
  • system agent 204 also includes a memory protection controller 206 to protect data stored on memory 210 .
  • system agent 204 may also provide an interface between processor 202 and other components of system 200 (e.g., using a direct media interface (DMI) and/or PCI-Express bridge).
  • DMI direct media interface
  • PCI-Express bridge PCI-Express bridge
  • system agent 204 may include any combination of logic elements configured to perform functionality of system agent 204 described herein, whether loaded from memory or other non-transitory computer readable medium, or implemented directly in hardware, including by way of non-limiting examples: a microprocessor, digital signal processor (DSP), field-programmable gate array (FPGA), graphics processing unit (GPU), programmable logic array (PLA), application-specific integrated circuit (ASIC), and/or virtual machine (VM) processor.
  • DSP digital signal processor
  • FPGA field-programmable gate array
  • GPU graphics processing unit
  • PDA programmable logic array
  • ASIC application-specific integrated circuit
  • VM virtual machine
  • System agent 204 may be integrated with processor 202 , or alternatively, system agent 204 may be implemented on a separate chip communicatively coupled or connected to processor 202 .
  • Memory controller 208 may be used to control and/or manage access to memory 210 of system 200 .
  • memory controller 208 may be implemented using any combination of hardware and/or software logic, including a microprocessor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic array (PLA), virtual machine (VM), and/or any other type of circuitry or logic.
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate array
  • PDA programmable logic array
  • VM virtual machine
  • system 200 provides cryptographic memory protection for memory 210 .
  • cryptographic memory protection may be implemented by extending and/or modifying a particular computer architecture.
  • cryptographic memory protection may be implemented by extending the functionality of a processor 202 and/or introducing a memory protection controller 206 .
  • processor 202 is extended to support control registers 203 and processor instruction(s) that can be used to enable and/or configure cryptographic memory protection
  • memory protection controller 206 is implemented to provide the cryptographic memory protection.
  • 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 may be integrated together or alternatively may be implemented as separate components.
  • memory protection controller 206 may be implemented using any combination of hardware and/or software logic, including a microprocessor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic array (PLA), virtual machine (VM), and/or any other type of circuitry or logic.
  • ASIC application-specific integrated circuit
  • FPGA field-programmable gate array
  • PDA programmable logic array
  • VM virtual machine
  • Memory protection controller 206 uses memory encryption to protect data stored on memory 210 .
  • memory protection controller 206 may be implemented on the memory path or memory bus to allow encryption of data transmitted to and from, and/or stored on, memory 210 .
  • memory protection controller 206 may be configurable or programmable, and may include support for multiple encryption keys. Accordingly, memory protection controller 206 may 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.
  • memory protection controller 206 may be used to define various secured or protected domains that can be separately configured and protected using memory encryption.
  • a “domain” may be viewed as a collection of resources associated with a particular workload (e.g., a workload of a particular user or application), and may include any regions of memory containing data associated with the workload.
  • a protected domain for a customer workload of a cloud service provider may include resources (e.g., memory) associated with an operating system (O/S), virtual machine (VM) (e.g., a VM running on a virtual machine manager (VMM)), and/or any ring- 3 applications running on the O/S or VM.
  • O/S operating system
  • VM virtual machine
  • VMM virtual machine manager
  • Memory protection controller 206 may allow the protected domains to be configured and protected separately, thus 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 manner, the workloads of different users, customers, and/or tenants can be cryptographically isolated by defining different protection domains for the various workloads.
  • the cryptographic memory protection of system 200 may be discovered and configured using processor instructions and/or hardware registers.
  • a processor instruction may be used to determine whether cryptographic memory protection is supported by system 200 , such as a CPU identification (CPUID) instruction used by software to identify the capabilities of a particular processor.
  • CPU identification CPUID
  • control registers 203 may include various model-specific registers (MSRs) that allow software to discover, enable, and/or configure the cryptographic memory protection capabilities of system 200 .
  • MSRs model-specific registers
  • control registers 203 may include a memory encryption capability register, a memory encryption activation register, and/or one or more memory encryption exclusion registers, as described further below.
  • the memory encryption capability register may be used to allow software to discover the memory encryption capabilities of system 200 .
  • software can read the ME_CAPABILITY_MSR (e.g., using a read MSR (RDMSR) instruction) to identify the supported encryption types and/or algorithms, the maximum number of encryption keys that can be used concurrently, and so forth.
  • RMSR read MSR
  • TABLE 1 illustrates an example embodiment of the memory encryption capability register (ME_CAPABILITY_MSR).
  • ME_CAPABILITY_MSR Memory Encryption Capability Register
  • ME_CAPABILITY_MSR BIT FIELD INDEX DESCRIPTION SUPPORTED 0:15 This field is used to identify supported ENCRYPTION encryption algorithms or encryption types. ALGORITHMS Each bit of this field (if used) corresponds to a particular encryption algorithm. For example, bit 0 may correspond to AES-XTS 128-bit encryption, bit 1 may correspond to AES-XTS 256-bit encryption, and so forth. A particular encryption algorithm is supported if the corresponding bit has a value of 1, and is unsupported if the corresponding bit has a value of 0. RESERVED 16:31 These bits are unused and/or reserved (e.g., reserved for functionality extensions and/or other purposes).
  • the value of this field is 0 if multi-key memory encryption is not supported.
  • RESERVED 51:63 These bits are unused and/or reserved (e.g., reserved for functionality extensions and/or other purposes).
  • the memory encryption activation register (ME_ACTIVATE_MSR) may be used to activate the cryptographic memory protection of system 200 (e.g., by setting the appropriate values in the register fields).
  • TABLE 2 illustrates an example embodiment of the memory encryption activation register (ME_ACTIVATE_MSR).
  • ME_ACTIVATE_MSR Memory Encryption Activation Register
  • ME_ACTIVATE_MSR BIT FIELD INDEX DESCRIPTION READ-ONLY LOCK 0
  • This field is used to activate a read-only lock on the memory encryption configuration registers after memory encryption has been activated.
  • the lock may be activated after memory encryption has been activated through a write to the ME_ACTIVATE_MSR register (e.g., using a write MSR or WRMSR instruction).
  • the lock can be enabled by setting this bit field to 1, and the lock can be disabled by setting this bit field to 0.
  • the lock is applied to the ME_ACTIVATE_MSR, ME_EXCLUDE_BASE_MSR, and ME_EXCLUDE_MASK_MSR registers.
  • SAVE KEY FOR 3 This field is used to specify whether the key used for STANDBY default encryption mode should be saved in order to allow the key to be restored after resuming from standby. If this bit field is set to 1, the key is saved. If this bit field is set to 0, the key is not saved. ENCRYPTION 4:7 This field can be used to specify the encryption ALGORITHM FOR algorithm to use for default encryption mode. DEFAULT MODE The value of this field identifies the bit index in the ME_CAPABILITY_MSR register that corresponds to the selected encryption algorithm. For example, the supported encryption algorithms are identified by bits 0:15 of the ME_CAPABILITY_MSR register.
  • bit index 0 of the ME_CAPABILITY_MSR register may correspond to AES-XTS 128-bit encryption
  • bit index 1 may correspond to AES-XTS 256-bit encryption
  • bit index 0 (binary 0000)
  • the encryption algorithm corresponding to bit index 0 of the ME_CAPABILITY_MSR register is selected, which would be AES-XTS 128-bit encryption.
  • the present field has a value of 1 (binary 0001)
  • the encryption algorithm corresponding to bit index 1 of the ME_CAPABILITY_MSR register is selected, which would be AES-XTS 256-bit encryption.
  • the encryption algorithm selected using this field must be supported (e.g., its corresponding bit index in the ME_CAPABILITY_MSR register must be set to 1).
  • RESERVED 8:31 These bits are unused and/or reserved (e.g., reserved for functionality extensions and/or other purposes).
  • # OF KEY ID BITS 32:35 This field is used to identify the number of bits that (ME_KEYID_BITS) are used for key identifiers. More specifically, the value of this field represents the number of higher order bits of a memory address that are used as a key or domain identifier for memory encryption.
  • ENCRYPTION 48:63 This field can be used to restrict the encryption RESTRICTION algorithms that can be used for multi-key BITMASK encryption.
  • the supported encryption algorithms are identified in the ME_CAPABILITY_MSR register (bits 0:15).
  • the bits in the present field correspond to the bits of the ME_CAPABILITY_MSR register that are used to identify the supported encryption algorithms. In this manner, a supported encryption algorithm can be restricted from being used for multi-key encryption by clearing the corresponding bit in the present field (or alternatively, setting the corresponding bit).
  • the memory encryption exclusion registers may be used to exclude certain memory regions from the cryptographic memory protection provided by system 200 .
  • the exclusion registers may be used to identify a base memory address, and memory encryption may then be bypassed for memory addresses matching the base address (e.g., allowing the excluded or bypassed memory addresses to be accessed in plaintext mode).
  • TABLE 3 illustrates an example embodiment of the memory encryption exclusion mask register (ME_EXCLUDE_MASK_MSR), and TABLE 4 illustrates an example embodiment of the memory encryption exclusion base register (ME_EXCLUDE_BASE_MSR).
  • ME_EXCLUDE_MASK_MSR Memory Encryption Exclusion Mask Register
  • ME_EXCLUDE_MASK_MSR FIELD BIT INDEX DESCRIPTION RESERVED 0:10 These bits are unused and/or reserved (e.g., reserved for functionality extensions and/or other purposes).
  • ENABLE 11 This field can be used to enable or disable EXCLUSION exclusions from memory encryption protection. When this field is set to 0, no memory addresses are excluded from memory encryption protection. When this field is set to 1, the ME_EXCLUDE_MASK_MSR and ME_EXCLUDE_BASE_MSR registers are used to define a memory range that is excluded from memory encryption protection.
  • EXCLUSION 12 (MAX ADDRESS This field is used to identify the bits of a memory MASK SIZE-1) address that must match the EXCLUSION BASE (defined in the ME_EXCLUDE_BASE_MSR register) in order to qualify as an excluded memory range. For example, when accessing a particular memory address, the memory address can be AND-ed with the EXCLUSION MASK, and if the result matches the EXCLUSION BASE, memory encryption is bypassed for that memory address.
  • RESERVED (MAX ADDRESS These bits are unused and/or reserved (e.g., SIZE):63 reserved for functionality extensions and/or other purposes).
  • EXCLUDE_BASE_MSR Memory Encryption Exclusion Base Register
  • RESERVED 0:11 These bits are unused and/or reserved (e.g., reserved for functionality extensions and/or other purposes).
  • RESERVED MAX ADDRESS These bits are unused and/or reserved (e.g., SIZE):63 reserved for functionality extensions and/or other purposes).
  • memory protection controller 206 maintains an internal domain key table 207 to identify protected domains that have been configured in system 200 .
  • the key table 207 may be implemented using any form of memory or storage (e.g., RAM), and may also be implemented directly on memory protection controller 206 , in memory 210 , and/or using another memory component.
  • each entry 207 a - d of domain key table 207 each correspond to a different protected domain.
  • each entry 207 a - d includes a key or domain identifier (ID), a protection mode, and an associated encryption key (if applicable).
  • a key ID may represent the higher order bits of the memory addresses that are within the associated protected domain.
  • the ME_KEYID_BITS field of the ME_ACTIVATE_MSR register specifies the number of bits used for key IDs.
  • each key ID in domain key table 207 is represented using 5 bits. Accordingly, the protected domain associated with a given key ID covers all memory addresses whose highest order 5 bits match the key ID.
  • the key ID is stored as a field in key table 207 , but in alternative embodiments, the key ID may be used as an index into key table 207 rather than being stored directly in key table 207 .
  • multiple protection modes may be supported, and each protected domain may be protected using a particular protection mode.
  • the supported protection modes may include plaintext mode (e.g., unencrypted), standard or default encryption mode (e.g., encrypted using a standard or default encryption key), and/or custom encryption mode (e.g., encrypted using a unique encryption key).
  • key table 207 may identify the protection mode associated with each protected domain or key ID.
  • domain key table 207 includes four entries.
  • the first entry identifies a protected domain corresponding to key ID 00000 (thus covering all memory addresses that contain 00000 in the highest order 5 bits), which is protected in default encryption mode using key “ABC.”
  • the second entry identifies a protected domain corresponding to key ID 00001 (thus covering all memory addresses that contain 00001 in the highest order 5 bits), which 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 (thus covering all memory addresses that contain 00010 in the highest order 5 bits), which is protected in custom encryption mode using key “XYZ.”
  • the fourth entry identifies a protected domain corresponding to key ID 00011 (thus covering all memory addresses that contain 00011 in the highest order 5 bits), which is protected in default encryption mode using key “ABC.”
  • the domain protected using custom encryption mode has a unique key (“XYZ”)
  • the domains protected using default encryption mode share an encryption key (“ABC”)
  • the domain protected in plaintext mode is unencrypted and thus has no associated key.
  • protected domains may be defined and/or configured using a processor instruction implemented by processor 202 , such as the “platform configuration” (PCONFIG) instruction described in connection with FIG. 3 and throughout this disclosure.
  • the PCONFIG instruction may be used to define and/or configure a protected domain by programming a new entry—or modifying an existing entry—in key table 207 of memory protection controller 206 .
  • protected domains can be defined and configured programmatically (e.g., by management software) using the PCONFIG instruction.
  • FIG. 3 illustrates an example 300 of configuring a protected domain using a processor instruction.
  • a processor may implement an instruction that can be used to configure the protected domains associated with a memory protection system.
  • the processor instruction could be a “platform configuration” (PCONFIG) instruction, a “trusted platform action supervisor” (TPAS) instruction, and/or any other suitable type of instruction.
  • PCONFIG platform configuration
  • TPAS trusted platform action supervisor
  • a “platform configuration” (PCONFIG) instruction may be used to define and/or configure a protected domain by programming a new entry—or modifying an existing entry ⁇ in a domain key table of a memory protection controller (e.g., domain key table 207 of memory protection controller 206 from FIG. 2 ).
  • protected domains can be defined and configured programmatically using the PCONFIG instruction.
  • memory addresses associated with the protected domain are protected in the manner specified by the configuration for the protected domain. For example, when using encryption protection, data is encrypted before being written to memory addresses within the protected domain, and data read from memory addresses within the protected domain is decrypted before being returned to the requesting processor.
  • the PCONFIG instruction may require a certain privilege level or privilege ring.
  • the processor may support a hierarchy of privilege levels or privilege rings to restrict access to certain resources.
  • privilege ring 0 may be the least restrictive level, while privilege rings with higher numbers may be increasingly more restrictive.
  • privilege ring 0 may be used for system management software (e.g., the operating system kernel and device drivers), while privilege ring 3 may be used for userland applications.
  • the PCONFIG instruction may be a ring- 0 instruction that can only be used by software executing in the highest privilege ring (e.g., management software used to configure protected domains).
  • the PCONFIG instruction may be a ring- 3 instruction that can be used by any userland application to configure its own protected domain.
  • FIG. 3 illustrates an example call flow 300 associated with the PCONFIG instruction.
  • the illustrated example identifies the call flow 300 between software 310 performing domain configuration using the PCONFIG instruction and a memory protection controller 320 .
  • Memory protection controller 320 may include any engine, controller, or other component that provides cryptographic memory protection (e.g., memory protection controller 206 of FIG. 2 ).
  • Software 310 may include any software used to configure the domains protected by memory protection controller 320 , such as a virtual machine manager and/or other management software.
  • the illustrated call flow begins by software 310 selecting a key programming mode for programming an encryption key for a particular domain (call 302 a ). For example, as discussed further below, software 310 may directly specify a key for the domain, or may request that a random key be generated.
  • Software 310 may then invoke the PCONFIG processor instruction to perform the domain configuration (call 302 b ).
  • memory protection controller 320 programs the key and protection mode for the particular domain (call 302 c ).
  • Memory protection controller 320 then returns a status code to software 310 (call 302 d ), and the status code is then processed by software 310 (call 302 e ).
  • the PCONFIG instruction may support various leaf functions for configuring and managing protected domains.
  • the particular leaf function to invoke may be specified in a hardware register (e.g., the EAX register).
  • the parameters used by a particular leaf function may also be specified in hardware registers (e.g., the RBX/RCX/RDX registers).
  • TABLE 5 illustrates an example of PCONFIG leaf encodings that could be used to enable support for multiple leaf functions. Although only one leaf function is defined (the KEY_PROGRAM leaf), additional leaf functions can be defined using the reserved leaf encodings in order to extend the functionality of the PCONFIG instruction.
  • the key program leaf function (KEY_PROGRAM) of the PCONFIG instruction can be used to program a key for a protected domain.
  • the parameters used by the key program leaf function may be specified in a key program structure (KEY_PROGRAM_STRUCT), and the address of the key program structure may be specified in a hardware register (e.g., the RBX register).
  • TABLE 6 illustrates an example embodiment of the key program structure (KEY_PROGRAM_STRUCT).
  • KEYID 1 This field identifies the key ID of a domain that is being programmed.
  • KEYID_CMD 1 This field identifies a key programming command.
  • KEYID_ENC_ALG 2 This field may be used to select an encryption algorithm to use for the domain (based on the available encryption algorithms).
  • KEYID_KEY 16 This field may identify an encryption key for the domain.
  • KEYID_TWEAK_KEY 16 This field may identify a tweak key value.
  • the key program structure identifies the key ID of the particular domain being programmed, and it also specifies a key programming command.
  • the key program leaf function may support multiple key programming commands, and the desired command may be specified in the key program structure.
  • the key program structure may also include reserved field(s) that can be used for subsequent extensions to the key program leaf function.
  • TABLE 7 illustrates examples of key programming commands that may be supported by the key program leaf function.
  • KD KEY DOMAIN
  • KD_SET_KEY_DIRECT This command sets the key for a domain (KD_SET_KEY_DIRECT) directly using the key specified in the key program structure (KEY_PROGRAM_STRUCT).
  • the key is provided by the software that initiates this key programming command.
  • the domain is then protected in custom encryption mode.
  • Set Key Random 1 This command sets the key for a domain (KD_SET_KEY_RANDOM) using a randomly generated key. For example, a key may be randomly generated by a processor and/or a random number generator, and thus may not be known by (or shared with) the software that initiates the key programming command.
  • the domain is then protected in custom encryption mode.
  • a return value or status code may be specified in a hardware register to indicate whether the key program function was successful.
  • TABLE 8 illustrates examples of the status codes that may be returned by the key program leaf function.
  • domain configuration may be performed using hardware registers.
  • a PCONFIG model-specific register MSR
  • MSR PCONFIG model-specific register
  • certain parameters for the PCONFIG operation may be passed in hardware registers.
  • the address of the key program structure (KEY_PROGRAM_STRUCT) can be passed in a hardware register, such as the EDX register, EAX register, or both of those registers (e.g., for 64-bit memory addresses).
  • a hardware register such as the EDX register, EAX register, or both of those registers (e.g., for 64-bit memory addresses).
  • the PCONFIG operation can then be performed in a similar manner as described above.
  • a PCONFIG operation may utilize wrapped blobs for domain key programming.
  • domain keys can be programmed without revealing the keys to management software.
  • additional PCONFIG leaf functions may be implemented to enable keys to be wrapped and then subsequently programmed to memory protection controller 320 after being unwrapped.
  • FIG. 4 illustrates a state machine 400 for an example embodiment of cryptographic memory protection.
  • State machine 400 illustrates the lifecycle of a domain protected using cryptographic memory protection.
  • state machine 400 includes three protection states for a particular domain: the unprotected state 401 , the default protection state 402 , and the custom protection state 403 .
  • State machine 400 transitions between these states based on key programming commands.
  • the key programming commands associated with the key program leaf of the PCONFIG instruction (e.g., as described in connection with FIG. 3 and TABLE 7) may be used to transition between states of state machine 400 .
  • the initial state of state machine 400 for a particular domain is the unprotected state 401 , where the domain is protected in plaintext (e.g., unencrypted) mode.
  • plaintext e.g., unencrypted
  • state machine 400 transitions to the default protection state 402 , where the domain is protected in default encryption mode (e.g., using a default or global encryption key).
  • ME_ACTIVATE_MSR memory encryption activation register
  • a “set key” command (e.g., KD_SET_KEY_DIRECT or KD_SET_KEY_RANDOM of TABLE 7) is issued while in the unprotected state 401 or the default protection state 402 , state machine 400 transitions to the custom protection state 403 , where 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 the custom protection state 403 , a new key is programmed for the domain and state machine 400 remains in the custom protection state 403 .
  • KD_SET_KEY_DIRECT or KD_SET_KEY_RANDOM of TABLE 7 is issued while in the custom protection state 403 .
  • a “clear key” command (e.g., KD_CLEAR_KEY of TABLE 7) is issued while in the custom protection state 403 , the unique encryption key for the domain is cleared, and state machine 400 transitions back to the default protection state 402 , where the domain is protected in default encryption mode (e.g., using a default or global encryption key).
  • a “no key” command (e.g., KD_NO_KEY of TABLE 7) is issued while in the default protection state 402 or the custom protection state 403 , state machine 400 transitions back to the unprotected state 401 , where the domain is protected in plaintext (e.g., unencrypted) mode.
  • FIG. 5 illustrates a flowchart 500 for an example embodiment of cryptographic memory protection.
  • Flowchart 500 may be implemented, in some embodiments, using the embodiments and functionality described throughout this disclosure.
  • the flowchart may begin at block 502 by identifying a memory access operation for a particular memory location.
  • the memory access operation for example, could be a read operation to read data from the memory location, or a write operation to write data to the memory location.
  • a “domain,” for example, may be viewed as a collection of resources associated with a particular workload or execution context, which may include any regions of memory containing data associated with the workload.
  • each protected domain can be configured using various modes of protection, including plaintext mode (e.g., unencrypted), standard or default encryption mode (e.g., encrypted using a standard or default encryption key), and/or custom encryption mode (e.g., encrypted using a unique encryption key).
  • plaintext mode e.g., unencrypted
  • standard or default encryption mode e.g., encrypted using a standard or default encryption key
  • custom encryption mode e.g., encrypted using a unique encryption key.
  • cryptographic isolation can be achieved for workloads of different tenants, users, and/or customers.
  • a protected domain may be created and/or configured using a command, instruction, and/or register to identify a protection mode, encryption type, and/or encryption key for the protected domain.
  • the flowchart may then proceed to block 512 to perform the memory access operation (e.g., as it would normally be performed).
  • the flowchart may then proceed to block 506 to identify an encryption key associated with the protected domain.
  • an encryption type associated with the protected domain may also be identified.
  • the flowchart may then proceed to block 508 to perform a cryptography operation (e.g., an encrypt and/or decrypt operation) on data associated with the memory location using the encryption key for the protected domain.
  • a cryptography operation e.g., an encrypt and/or decrypt operation
  • data may be obtained from the memory location and may then be decrypted using the identified encryption key.
  • data that is to be written to the memory location may first be encrypted using the identified encryption key.
  • the flowchart may then proceed to block 510 to return a result of the cryptography operation (e.g., an encrypt and/or decrypt operation), wherein the result of the cryptography operation is to be 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 may then proceed to block 512 to perform the memory access operation (e.g., using the result of the cryptography operation).
  • the flowchart may be complete. In some embodiments, however, the flowchart may restart and/or certain blocks may be repeated. For example, in some embodiments, the flowchart may restart at block 502 to continue processing additional memory access operations.
  • FIGS. 6-10 illustrate example computer architectures that can be used in accordance with embodiments disclosed herein.
  • the computer architectures of FIGS. 6-10 may be used in conjunction with, and/or may be used to implement, the cryptographic memory protection engine, architecture, and functionality described throughout this disclosure.
  • Other computer architectures, system designs, and configurations known in the arts for laptops, desktops, 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.
  • DSPs digital signal processors
  • 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.
  • a huge variety of systems or electronic devices capable of incorporating a processor and/or other execution logic as disclosed herein are generally suitable.
  • FIG. 6A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to embodiments of the invention.
  • FIG. 6B is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to embodiments of the invention.
  • the solid lined boxes in FIGS. 6A-B illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue/execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.
  • a 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 a dispatch or issue) stage 612 , a register read/memory read stage 614 , an execute stage 616 , a write back/memory write stage 618 , an exception handling stage 622 , and a commit stage 624 .
  • FIG. 6B shows processor core 690 including a front end unit 630 coupled to an execution engine unit 650 , and both are coupled to a memory unit 670 .
  • the core 690 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type.
  • the core 690 may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like.
  • GPGPU general purpose computing graphics processing unit
  • 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) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions.
  • the decode unit 640 may be implemented using various different mechanisms.
  • the core 690 includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in 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 .
  • the execution engine unit 650 includes the rename/allocator unit 652 coupled to a retirement unit 654 and a set of one or more scheduler unit(s) 656 .
  • the scheduler unit(s) 656 represents any number of different schedulers, including reservations stations, central instruction window, etc.
  • the scheduler unit(s) 656 is coupled to the physical register file(s) unit(s) 658 .
  • Each of the physical register file(s) units 658 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc.
  • the physical register file(s) unit 658 comprises a vector registers unit, a write mask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers.
  • the physical register file(s) unit(s) 658 is overlapped by the retirement unit 654 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using a register maps and a pool of registers; etc.).
  • the retirement unit 654 and the physical register file(s) unit(s) 658 are coupled to the execution cluster(s) 660 .
  • the execution cluster(s) 660 includes a set of one or more execution units 662 and a set of one or more memory access units 664 .
  • the execution units 662 may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions.
  • the scheduler unit(s) 656 , physical register file(s) unit(s) 658 , and execution cluster(s) 660 are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster—and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s) 664 ). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.
  • the set of memory access units 664 is coupled to the memory unit 670 , which includes a data TLB unit 672 coupled to a data cache unit 674 coupled to a level 2 (L2) cache unit 676 .
  • the memory access units 664 may 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 further coupled to a 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 eventually to a main memory.
  • the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline 600 as follows: 1) the instruction fetch 638 performs the fetch and length decoding stages 602 and 604 ; 2) the decode unit 640 performs the decode stage 606 ; 3) the rename/allocator unit 652 performs the allocation stage 608 and renaming stage 610 ; 4) the scheduler unit(s) 656 performs the schedule stage 612 ; 5) the physical register file(s) unit(s) 658 and the memory unit 670 perform the register read/memory read stage 614 ; the execution cluster 660 perform the execute stage 616 ; 6) the memory unit 670 and the physical register file(s) unit(s) 658 perform the write back/memory write stage 618 ; 7) various units may be involved in the exception handling stage 622 ; and 8) the retirement unit 654 and the physical register file(s) unit(s) 658 perform the commit stage 624 .
  • the core 690 may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.), including the instruction(s) described herein.
  • the core 690 includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2), thereby allowing the operations used by many multimedia applications to be performed using packed data.
  • a packed data instruction set extension e.g., AVX1, AVX2
  • the core may support multithreading (executing two or more parallel sets of operations or threads), and may do so in a variety of ways including time sliced multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that physical core is simultaneously multithreading), or a combination thereof (e.g., time sliced fetching and decoding and simultaneous multithreading thereafter such as in the Intel® Hyperthreading technology).
  • register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture.
  • the illustrated embodiment of the processor also includes separate instruction and data cache units 634 / 674 and a shared L2 cache unit 676 , alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a Level 1 (L1) internal cache, or multiple levels of internal cache.
  • the system may include a combination of an internal cache and an external cache that is external to the core and/or the processor. Alternatively, all of the cache may be external to the core and/or the processor.
  • the platform configuration (PCONFIG) instruction described throughout this disclosure may be implemented using the processor architecture of FIGS. 6A-B .
  • instruction cache 634 may contain a PCONFIG instruction for configuring a protected domain based on a particular memory region, protection mode, encryption key, and/or encryption type.
  • the PCONFIG instruction may be retrieved from instruction cache 634 and decoded by decoder 640 , and execution unit 662 may then program or configure the protected domain in a memory encryption controller (e.g., memory protection controller 206 of FIG. 2 ).
  • FIG. 7 is a block diagram of a processor 700 that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to embodiments of the invention.
  • the solid lined boxes in FIG. 7 illustrate a processor 700 with a single core 702 A, a system agent 710 , a set of one or more bus controller units 716 , while the optional addition of the dashed lined boxes illustrates an alternative processor 700 with multiple cores 702 A-N, a set of one or more integrated memory controller unit(s) 714 in the system agent unit 710 , and special purpose logic 708 .
  • different implementations of the processor 700 may include: 1) a CPU with the special purpose logic 708 being integrated graphics and/or scientific (throughput) logic (which may include one or more cores), and the cores 702 A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two); 2) a coprocessor with the cores 702 A-N being a large number of special purpose cores intended primarily for graphics and/or scientific (throughput); and 3) a coprocessor with the cores 702 A-N being a large number of general purpose in-order cores.
  • the special purpose logic 708 being integrated graphics and/or scientific (throughput) logic
  • the cores 702 A-N being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, a combination of the two)
  • a coprocessor with the cores 702 A-N being a large number of special purpose core
  • the processor 700 may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), a high-throughput many integrated core (MIC) coprocessor (including 30 or more cores), embedded processor, or the like.
  • the processor may be implemented on one or more chips.
  • the processor 700 may be a part of and/or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.
  • the memory hierarchy includes one or more levels of cache within the cores, a set or one or more 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 may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.
  • LLC last level cache
  • a 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 unit(s) 714
  • alternative embodiments may use any number of well-known techniques for interconnecting such units.
  • coherency is maintained between one or more cache units 706 and cores 702 -A-N.
  • the system agent 710 includes those components coordinating and operating cores 702 A-N.
  • the system agent unit 710 may include for example a power control unit (PCU) and a display unit.
  • the PCU may be or include logic and components needed for regulating the power state of the cores 702 A-N and the integrated graphics logic 708 .
  • the display unit is for driving one or more externally connected displays.
  • the cores 702 A-N may be homogenous or heterogeneous in terms of architecture instruction set; that is, two or more of the cores 702 A-N may be capable of execution the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set.
  • the system 800 may include one or more processors 810 , 815 , which are coupled to a controller hub 820 .
  • the controller hub 820 includes a graphics memory controller hub (GMCH) 890 and an Input/Output Hub (IOH) 850 (which may be on separate chips);
  • the GMCH 890 includes memory and graphics controllers to which are coupled memory 840 and a coprocessor 845 ;
  • the IOH 850 is couples input/output (I/O) devices 860 to the GMCH 890 .
  • one or both of the memory and graphics controllers are integrated within the processor (as described herein), the memory 840 and the coprocessor 845 are coupled directly to the processor 810 , and the controller hub 820 in a single chip with the IOH 850 .
  • processors 815 may include one or more of the processing cores described herein and may be some version of the processor 700 .
  • the memory 840 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two.
  • the controller hub 820 communicates with the processor(s) 810 , 815 via a multi-drop bus, such as a frontside bus (FSB), point-to-point interface such as QuickPath Interconnect (QPI), or similar connection 895 .
  • a multi-drop bus such as a frontside bus (FSB), point-to-point interface such as QuickPath Interconnect (QPI), or similar connection 895 .
  • 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, GPGPU, embedded processor, or the like.
  • controller hub 820 may include an integrated graphics accelerator.
  • the processor 810 executes instructions that control data processing operations of a general type. Embedded within the instructions may be coprocessor instructions. The processor 810 recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor 845 . Accordingly, the processor 810 issues these coprocessor instructions (or control signals representing coprocessor instructions) on a coprocessor bus or other interconnect, to coprocessor 845 . Coprocessor(s) 845 accept and execute the received coprocessor instructions.
  • 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 .
  • processors 970 and 980 may be some version of the processor 700 .
  • processors 970 and 980 are respectively processors 810 and 815
  • coprocessor 938 is coprocessor 845
  • processors 970 and 980 are respectively processor 810 coprocessor 845 .
  • Processors 970 and 980 are shown including integrated memory controller (IMC) units 972 and 982 , respectively.
  • Processor 970 also includes as part of its bus controller units point-to-point (P-P) interfaces 976 and 978 ; similarly, second processor 980 includes P-P interfaces 986 and 988 .
  • Processors 970 , 980 may exchange information via a point-to-point (P-P) interface 950 using P-P interface circuits 978 , 988 .
  • IMCs 972 and 982 couple the processors to respective memories, namely a memory 932 and a memory 934 , which may be portions of main memory locally attached to the respective processors.
  • Processors 970 , 980 may 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 may optionally exchange information with the coprocessor 938 via a high-performance interface 939 .
  • 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, or the like.
  • a shared cache (not shown) may be included in either processor or outside of both processors, yet connected with the processors via P-P interconnect, such that either or both processors' local cache information may be stored in the shared cache if a processor is placed into a low power mode.
  • first bus 916 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present invention is not so limited.
  • PCI Peripheral Component Interconnect
  • various I/O devices 914 may be coupled to first bus 916 , along with a bus bridge 918 which couples first bus 916 to a second bus 920 .
  • one or more additional processor(s) 915 such as coprocessors, high-throughput MIC processors, GPGPU's, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus 916 .
  • second bus 920 may be a low pin count (LPC) bus.
  • Various devices may be coupled to a second bus 920 including, for example, a keyboard and/or mouse 922 , communication devices 927 and a storage unit 928 such as a disk drive or other mass storage device which may include instructions/code and data 930 , in one embodiment.
  • a storage unit 928 such as a disk drive or other mass storage device which may include instructions/code and data 930 , in one embodiment.
  • an audio I/O 924 may be coupled to the second bus 920 .
  • FIG. 9 a system may implement a multi-drop bus or other such architecture.
  • FIG. 10 shown is a block diagram of a SoC 1000 in accordance with an embodiment of the present invention. Similar elements in FIG. 7 bear like reference numerals. Also, dashed lined boxes are optional features on more advanced SoCs. In FIG. 10 , shown is a block diagram of a SoC 1000 in accordance with an embodiment of the present invention. Similar elements in FIG. 7 bear like reference numerals. Also, dashed lined boxes are optional features on more advanced SoCs. In FIG.
  • an interconnect unit(s) 1002 is coupled to: an application processor 1010 which includes a set of one or more cores 1002 A-N and shared cache unit(s) 1006 ; a system agent unit 1010 ; a bus controller unit(s) 1016 ; an integrated memory controller unit(s) 1014 ; a set or one or more coprocessors 1020 which may include integrated graphics logic, an image processor, an audio processor, and a video processor; an 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.
  • the coprocessor(s) 1020 include a special-purpose processor, such as, for example, a network or communication processor, compression engine, GPGPU, a high-throughput MIC processor, embedded processor, or the like.
  • Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches.
  • Embodiments of the invention may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.
  • Program code such as code 930 illustrated in FIG. 9
  • Program code may be applied to input instructions to perform the functions described herein and generate output information.
  • the output information may be applied to one or more output devices, in known fashion.
  • a processing system includes any system that has a processor, such as, for example; a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • the program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system.
  • the program code may also be implemented in assembly or machine language, if desired.
  • the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.
  • IP cores may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.
  • Such machine-readable storage media may 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 rewritable's (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), flash memories, electrically erasable programmable read-only memories (EEPROMs), phase change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
  • 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 rewritable's (CD-RWs), and magneto
  • embodiments of the invention 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.
  • HDL Hardware Description Language
  • Such embodiments may also be referred to as program products.
  • each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
  • the functions noted in the block may 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 may sometimes be executed in the reverse order or alternative orders, depending upon the functionality involved.
  • SoC system-on-a-chip
  • CPU central processing unit
  • An SoC represents an integrated circuit (IC) that integrates components of a computer or other electronic system into a single chip.
  • the SoC may contain digital, analog, mixed-signal, and radio frequency functions, all of which may be provided on a single chip substrate.
  • Other embodiments may include a multi-chip-module (MCM), with a plurality of chips located within a single electronic package and configured to interact closely with each other through the electronic package.
  • MCM multi-chip-module
  • the computing functionalities disclosed herein may be implemented in one or more silicon cores in Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and other semiconductor chips.
  • ASICs Application Specific Integrated Circuits
  • FPGAs Field Programmable Gate Arrays
  • processor or “microprocessor” should be understood to include not only a traditional microprocessor (such as Intel's® industry-leading x86 and x64 architectures), but also graphics processors, matrix processors, 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 permit the execution of instructions.
  • DSP digital signal processor
  • PLA programmable logic device
  • microcode instruction set
  • emulated or virtual machine processor or any similar “Turing-complete” device, combination of devices, or logic elements (hardware or software) that permit the execution of instructions.
  • any suitably-configured processor can execute instructions associated with data or microcode to achieve the operations detailed herein.
  • Any processor disclosed herein could transform an element or an article (for example, data) from one state or thing to another state or thing.
  • some activities outlined herein may be implemented with fixed logic or programmable logic (for example, software and/or computer instructions executed by a processor) and the elements identified herein could 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)), 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 mediums suitable for storing electronic instructions, or any suitable combination thereof.
  • FPGA field programmable gate array
  • EPROM erasable programmable read only memory
  • EEPROM electrically eras
  • a storage may store information in any suitable type of tangible, non-transitory storage medium (for example, random access memory (RAM), read only memory (ROM), field programmable gate array (FPGA), erasable programmable read only memory (EPROM), electrically erasable programmable ROM (EEPROM), or microcode), software, hardware (for example, processor instructions or microcode), or in any other suitable component, device, element, or object where appropriate and based on particular needs.
  • RAM random access memory
  • ROM read only memory
  • FPGA field programmable gate array
  • EPROM erasable programmable read only memory
  • EEPROM electrically erasable programmable ROM
  • microcode software, hardware (for example, processor instructions or microcode), or in any other suitable component, device, element, or object where appropriate and based on particular needs.
  • the information being tracked, sent, received, or stored in a processor could be provided in any database, register, table, cache, queue, control list, or storage structure, based on particular needs and implementations,
  • a non-transitory storage medium herein is expressly intended to include any non-transitory special-purpose or programmable hardware configured to provide the disclosed operations, or to cause a processor to perform the disclosed operations.
  • a non-transitory storage medium also expressly includes a processor having stored thereon hardware-coded instructions, and optionally microcode instructions or sequences encoded in hardware, firmware, or software.
  • Computer program logic implementing all or part of the functionality described herein is embodied in various forms, including, but in no way limited to, hardware description language, a source code form, a computer executable form, machine instructions or microcode, programmable hardware, and various intermediate forms (for example, forms generated by an HDL processor, assembler, compiler, linker, or locator).
  • 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, or in hardware description languages such as Spice, Verilog, and VHDL.
  • the source code may define and use various data structures and communication messages.
  • the source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form, or converted to an intermediate form such as byte code.
  • any of the foregoing may be used to build or describe appropriate discrete or integrated circuits, whether sequential, combinatorial, state machines, or otherwise.
  • any number of electrical circuits of the FIGURES may be implemented on a board of an associated electronic device.
  • the board can be a general circuit board that can hold various components of the internal electronic system of the electronic device and, further, provide connectors for other peripherals. More specifically, the board can provide the electrical connections by which the other components of the system can communicate electrically.
  • Any suitable processor and memory can be suitably coupled to the board based on particular configuration needs, processing demands, and computing designs.
  • Other components such as external storage, additional sensors, controllers for audio/video display, and peripheral devices may be attached to the board as plug-in cards, via cables, or integrated into the board itself.
  • the electrical circuits of the FIGURES may be implemented as stand-alone modules (e.g., a device with associated components and circuitry configured to perform a specific application or function) or implemented as plug-in modules into application specific hardware of electronic devices.
  • One or more embodiments may 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 cryptography operation on data associated with the memory access operation, wherein the cryptography operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptography operation, wherein the result of the cryptography operation is to be used for the memory access operation.
  • the memory access operation comprises a memory read operation
  • the memory encryption controller to perform the cryptography 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.
  • the memory access operation comprises a memory write operation
  • the memory encryption controller to perform the cryptography 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 cryptography operation is to be written to the memory location of the memory.
  • the memory encryption controller to perform the cryptography 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 is associated with a plurality of encryption types; and perform the cryptography operation based on the encryption type associated with the protected domain.
  • the plurality of protected domains comprises a plurality of execution contexts; and each protected domain of the plurality of protected domains comprises a particular execution context of the plurality of execution contexts.
  • 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.
  • 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.
  • 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 comprises an instruction cache comprising a platform configuration instruction, wherein the platform configuration instruction comprises the command to add the second protected domain to the plurality of protected domains; a decoder to decode the platform configuration instruction; and an execution unit to program the second protected domain in the memory encryption controller.
  • 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.
  • the protection mode comprises: plaintext mode; default encryption mode; or custom encryption mode.
  • One or more embodiments may include at least one machine accessible storage medium having instructions stored thereon, wherein the instructions, when executed on a machine, 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 cryptography operation on data associated with the memory access operation, wherein the cryptography operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptography operation, wherein the result of the cryptography operation is to be used for the memory access operation.
  • the memory access operation comprises a memory read operation
  • the instructions that cause the machine to perform the cryptography operation on the 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.
  • the memory access operation comprises a memory write operation
  • the instructions that cause the machine to perform the cryptography operation on the 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 cryptography operation is to be written to the memory location of the memory.
  • the instructions that cause the machine to perform the cryptography operation on the 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 cryptography operation based on the encryption type associated with the protected domain.
  • the plurality of protected domains comprises a plurality of execution contexts; and each protected domain of the plurality of protected domains comprises a particular execution context of the plurality of execution contexts.
  • 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.
  • 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.
  • 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.
  • 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.
  • the protection mode comprises: plaintext mode; standard encryption mode; or custom encryption mode.
  • One or more embodiments may 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 cryptography operation on data associated with the memory access operation, wherein the cryptography operation is performed based on the encryption key associated with the protected domain; and return a result of the cryptography operation, wherein the result of the cryptography operation is to be used for the memory access operation.
  • 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.
  • the memory comprises solid-state memory for providing persistent data storage.
  • One or more embodiments may 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 an encryption key associated with the protected domain; performing a cryptography operation on data associated with the memory access operation, wherein the cryptography operation is performed based on the encryption key associated with the protected domain; and returning a result of the cryptography operation, wherein the result of the cryptography operation is to be used for the memory access operation.
  • 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 encryption key associated with the second protected domain; and configuring the second protected domain based on the second protected memory region and the second encryption key.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
US15/635,548 2017-06-28 2017-06-28 Multi-key cryptographic memory protection Abandoned US20190004973A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US15/635,548 US20190004973A1 (en) 2017-06-28 2017-06-28 Multi-key cryptographic memory protection
DE102018004290.2A DE102018004290A1 (de) 2017-06-28 2018-05-29 Kryptographischer Speicherschutz mit Mehrfachschlüssel
CN201810622316.2A CN109145611A (zh) 2017-06-28 2018-06-15 多密钥密码存储器保护
CN202211117534.3A CN115470530A (zh) 2017-06-28 2018-06-15 多密钥密码存储器保护
US17/222,722 US20210224202A1 (en) 2017-06-28 2021-04-05 Multi-key cryptographic memory protection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/635,548 US20190004973A1 (en) 2017-06-28 2017-06-28 Multi-key cryptographic memory protection

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/222,722 Continuation US20210224202A1 (en) 2017-06-28 2021-04-05 Multi-key cryptographic memory protection

Publications (1)

Publication Number Publication Date
US20190004973A1 true US20190004973A1 (en) 2019-01-03

Family

ID=64662038

Family Applications (2)

Application Number Title Priority Date Filing Date
US15/635,548 Abandoned US20190004973A1 (en) 2017-06-28 2017-06-28 Multi-key cryptographic memory protection
US17/222,722 Pending US20210224202A1 (en) 2017-06-28 2021-04-05 Multi-key cryptographic memory protection

Family Applications After (1)

Application Number Title Priority Date Filing Date
US17/222,722 Pending US20210224202A1 (en) 2017-06-28 2021-04-05 Multi-key cryptographic memory protection

Country Status (3)

Country Link
US (2) US20190004973A1 (de)
CN (2) CN115470530A (de)
DE (1) DE102018004290A1 (de)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190342093A1 (en) * 2019-06-28 2019-11-07 Siddhartha Chhabra Converged cryptographic engine
CN111130784A (zh) * 2019-12-25 2020-05-08 成都海光集成电路设计有限公司 一种密钥生成方法、装置、cpu芯片及服务器
US20200174950A1 (en) * 2017-06-28 2020-06-04 Arm Limited Realm management unit-private memory regions
US11151262B2 (en) * 2018-06-24 2021-10-19 Hex Five Security, Inc. Configuring, enforcing, and monitoring separation of trusted execution environments
NL2029297A (en) * 2020-11-02 2022-06-17 Intel Corp Graphics security with synergistic encryption, content-based and resource management technology
US11397692B2 (en) 2018-06-29 2022-07-26 Intel Corporation Low overhead integrity protection with high availability for trust domains
US11687654B2 (en) 2017-09-15 2023-06-27 Intel Corporation Providing isolation in virtualized systems using trust domains

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12034860B2 (en) * 2020-08-26 2024-07-09 Micron Technology, Inc. Memory write access control
CN115421174B (zh) * 2022-08-31 2023-05-12 杭州数聚链科技有限公司 一种基于时空信息的无人机运动轨迹识别系统及方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050188173A1 (en) * 2004-02-24 2005-08-25 Robert Hasbun Physical domain separation
US7434068B2 (en) * 2001-10-19 2008-10-07 Intel Corporation Content protection in non-volatile storage devices
US20120328105A1 (en) * 2001-09-20 2012-12-27 CloudByte,Inc. Techniques for achieving tenant data confidentiality from cloud service provider administrators
US20130238907A1 (en) * 2011-09-15 2013-09-12 Maxim Integrated Products, Inc. Systems and methods for managing cryptographic keys in a secure microcontroller
US20140283010A1 (en) * 2013-03-15 2014-09-18 International Business Machines Corporation Virtual key management and isolation of data deployments in multi-tenant environments
US20150350200A1 (en) * 2014-05-30 2015-12-03 Verizon Patent And Licensing Inc. Biometric framework allowing independent application control
US20150358300A1 (en) * 2014-06-05 2015-12-10 Stmicroelectronics (Grenoble 2) Sas Memory encryption method compatible with a memory interleaved system and corresponding system
US20160077966A1 (en) * 2014-09-16 2016-03-17 Kove Corporation Dynamically provisionable and allocatable external memory
US10013364B1 (en) * 2015-06-26 2018-07-03 EMC IP Holding Company LLC Securing data using per tenant encryption keys

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7627617B2 (en) * 2004-02-11 2009-12-01 Storage Technology Corporation Clustered hierarchical file services
JP4885629B2 (ja) * 2006-06-29 2012-02-29 フェリカネットワークス株式会社 金融カードシステム、通信デバイス、認証端末、認証方法、及びプログラム。
US9712495B2 (en) * 2011-05-03 2017-07-18 International Business Machines Corporation Methods and systems for selective encryption and secured extent quota management for storage servers in cloud computing
US9607177B2 (en) * 2013-09-30 2017-03-28 Qualcomm Incorporated Method for securing content in dynamically allocated memory using different domain-specific keys
US10049001B1 (en) * 2015-03-27 2018-08-14 Amazon Technologies, Inc. Dynamic error correction configuration
US10447659B2 (en) * 2016-03-02 2019-10-15 Google Llc Sharing protected user content between devices
US10296757B2 (en) * 2016-07-29 2019-05-21 Sap Se Appended key ID for key identification during data encryption

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120328105A1 (en) * 2001-09-20 2012-12-27 CloudByte,Inc. Techniques for achieving tenant data confidentiality from cloud service provider administrators
US7434068B2 (en) * 2001-10-19 2008-10-07 Intel Corporation Content protection in non-volatile storage devices
US20050188173A1 (en) * 2004-02-24 2005-08-25 Robert Hasbun Physical domain separation
US20130238907A1 (en) * 2011-09-15 2013-09-12 Maxim Integrated Products, Inc. Systems and methods for managing cryptographic keys in a secure microcontroller
US20140283010A1 (en) * 2013-03-15 2014-09-18 International Business Machines Corporation Virtual key management and isolation of data deployments in multi-tenant environments
US20150350200A1 (en) * 2014-05-30 2015-12-03 Verizon Patent And Licensing Inc. Biometric framework allowing independent application control
US20150358300A1 (en) * 2014-06-05 2015-12-10 Stmicroelectronics (Grenoble 2) Sas Memory encryption method compatible with a memory interleaved system and corresponding system
US20160077966A1 (en) * 2014-09-16 2016-03-17 Kove Corporation Dynamically provisionable and allocatable external memory
US10013364B1 (en) * 2015-06-26 2018-07-03 EMC IP Holding Company LLC Securing data using per tenant encryption keys

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200174950A1 (en) * 2017-06-28 2020-06-04 Arm Limited Realm management unit-private memory regions
US11874778B2 (en) * 2017-06-28 2024-01-16 Arm Limited Realm management unit-private memory regions
US11687654B2 (en) 2017-09-15 2023-06-27 Intel Corporation Providing isolation in virtualized systems using trust domains
US11151262B2 (en) * 2018-06-24 2021-10-19 Hex Five Security, Inc. Configuring, enforcing, and monitoring separation of trusted execution environments
US11397692B2 (en) 2018-06-29 2022-07-26 Intel Corporation Low overhead integrity protection with high availability for trust domains
US20190342093A1 (en) * 2019-06-28 2019-11-07 Siddhartha Chhabra Converged cryptographic engine
EP3757848A1 (de) * 2019-06-28 2020-12-30 INTEL Corporation Konvergierte kryptografische engine
CN111130784A (zh) * 2019-12-25 2020-05-08 成都海光集成电路设计有限公司 一种密钥生成方法、装置、cpu芯片及服务器
NL2029297A (en) * 2020-11-02 2022-06-17 Intel Corp Graphics security with synergistic encryption, content-based and resource management technology
EP4237983A4 (de) * 2020-11-02 2024-11-06 Intel Corp Grafiksicherheit mit synergistischer verschlüsselung, inhaltsbasierter und ressourcenverwaltungstechnologie

Also Published As

Publication number Publication date
CN115470530A (zh) 2022-12-13
US20210224202A1 (en) 2021-07-22
DE102018004290A1 (de) 2019-01-03
CN109145611A (zh) 2019-01-04

Similar Documents

Publication Publication Date Title
US20210224202A1 (en) Multi-key cryptographic memory protection
TWI770689B (zh) 用於記憶體位址範圍的支持可組態安全性級別的處理器、方法及電腦可讀取非暫態儲存媒體
US11755500B2 (en) Cryptographic computing with disaggregated memory
US20220159081A1 (en) Secure reporting of platform state information to a remote server
US8819455B2 (en) Parallelized counter tree walk for low overhead memory replay protection
KR20240081462A (ko) 신뢰 도메인들을 사용한 가상화된 시스템들에서의 격리 제공
EP3757839B1 (de) Skalierbarer betrieb einer virtuellen maschine innerhalb einer vertrauensdomäne innerhalb einer vertrauensdomänenarchitektur
KR20170033891A (ko) 보호 영역에서의 메모리 초기화
US8935775B2 (en) Method and apparatus for dishonest hardware policies
BR102020019667A2 (pt) método e aparelho para criptografia de memória total multichave baseada em derivação de chave dinâmica
US11360910B2 (en) Prevention of trust domain access using memory ownership bits in relation to cache lines
US11403005B2 (en) Cryptographic memory ownership
US20220121447A1 (en) Hardening cpu predictors with cryptographic computing context information
CN114692177A (zh) 完好性受保护的访问控制机制
US10171500B2 (en) Systems, apparatuses, and methods for enforcing security on a platform
US10795829B2 (en) Device, method and system to selectively provide data validation functionality
US12143501B2 (en) ISA support for programming hardware over untrusted links
EP4020882A1 (de) Isa-unterstützung zur programmierung von hardware über nicht vertrauenswürdige verbindungen
US10579335B2 (en) Multiplier circuit for accelerated square operations

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTEL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHHABRA, SIDDHARTHA;KHOSRAVI, HORMUZD M.;GERZON, GIDEON;AND OTHERS;SIGNING DATES FROM 20170611 TO 20170621;REEL/FRAME:043021/0809

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION