Cross-domain security in a password-partitioned cloud

Abstract

A solution for secure memory access in a computing platform includes a multi-key encryption (MKE) engine as part of a memory interface between a processor core and memory of the computing platform. The processor core executes workloads, each workload utilizing an allocated portion of memory. The MKE engine performs key-based cryptographic operations on data to isolate portions of memory from workloads that are not allocated to those portions of memory. A key mapping data repository is accessible to the MKE engine and contains associations between identifiers of portions of memory and corresponding key identification data from which cryptographic keys are obtained. A key tracking log is maintained by the MKE engine, and the MKE engine temporarily stores entries in the key tracking log during memory access operations to those portions of memory, the entries containing identifiers of the portions of memory and key identification data for those portions of memory.

Description

Technical Field

[0001] The embodiments described herein relate generally to information systems and computing architecture, and more particularly, to system architecture and operability for preventing information leakage and cross-domain attacks in cryptographically isolated domains in a secure public cloud. Background Art

[0002] Cloud computing and Software as a Service (SAAS) providers operate increasingly complex computer servers and server farms, where information security remains a top concern. Recent advances in security include cryptographic isolation between customer workloads, typically implemented as separate virtual machines (VMs) running on a common platform.

[0003] One secure approach involves using Multi-Key Total Memory Encryption (MKTME), where the hypervisor can distribute cryptographic keys to each customer workload running in its own VM. Each workload can use its key to protect the information it stores in the server's physical memory. A secure MKTME engine can be used as part of the memory access subsystem to perform encryption and decryption operations as part of providing secure memory access.

[0004] While MKTME has shown great promise as an effective component of server system architectures to improve isolation between client workloads, there are still some important challenges that need to be addressed. These include preventing specific types of attacks, such as hardware replay attacks and cross-domain injection attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the accompanying drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Similar numerals with different letter suffixes may represent different instances of similar components. In the following figures of the accompanying drawings, some embodiments are shown by way of example and not limitation.

[0006] Figure 1 is a diagram illustrating an example computing system including an edge device and a cloud service in which password memory protection can be implemented according to various embodiments.

[0007] Figure 2 is a high-level block diagram illustrating a host platform that can implement various embodiments. Figure 1 All or part of an edge device or cloud service.

[0008] Figure 3 is a diagram showing a computer system such as Figure 2 A diagram of an exemplary computing hardware and software architecture (as shown in ), showing the various interfaces between hardware components and software components.

[0009] Figure 4 is a functional diagram illustrating the operation of a multi-key memory encryption arrangement according to some embodiments.

[0010] Figure 5 is a partial system architecture diagram illustrating a machine-based implementation of a multi-key memory encryption arrangement according to various embodiments.

[0011] Figure 6 is a flow chart illustrating key tracking table (KTT) related operations performed by a multi-key encryption circuit in response to a memory read operation according to an example.

[0012] Figure 7 is a flow chart illustrating KTT-related operations performed by a multi-key encryption circuit in response to a memory write operation, according to an example.

[0013] Figure 8 is a flow chart illustrating operations performed by a multi-key encryption engine in cooperation with a processor core according to an embodiment, where, for example, salting techniques are utilized to defeat cross-domain replay attacks. DETAILED DESCRIPTION

[0014] Various aspects of the present disclosure relate to cryptographic memory protection. The described embodiments can be used to provide cryptographic memory protection, thereby providing an additional layer of security by plugging holes associated with unprotected or insecure memory. For example, in some embodiments, memory encryption can be provided by implementing a cryptographic engine or controller on a memory path or memory bus. In this way, data can be encrypted and protected while it resides in memory and during transmission to and from memory (e.g., when sent from memory to a processor via a memory bus or memory path, and vice versa). However, while memory encryption may be necessary for specific users or use cases, in certain circumstances, unified memory protection on a computing system may not be sufficient. For example, cloud service providers often host data, applications, or workloads for multiple customers or third parties. In addition, cloud service providers can use memory encryption (e.g., using a single encryption key) to provide unified protection for all hosted customer workloads. However, simply providing unified memory encryption protection for all hosted workloads without distinguishing between different customer workloads may not be sufficient. For example, a cloud service provider or its customers may not want to share the same encryption key for all customers. Instead, the cloud service provider or its customers may prefer to provide storage encryption on a per-tenant basis (e.g., per-customer or per-virtual machine) to ensure that each customer workload is individually protected and isolated using a unique encryption key.

[0015] Thus, aspects of the described embodiments provide memory encryption that supports multiple keys. For example, the number of supported keys may depend on the implementation. In an example, for example, a memory protection engine can be configured or programmed (e.g., via software) to use different encryption keys or algorithms to encrypt different regions or pages of memory. For example, in an example, a user or tenant (e.g., a cloud service provider or customer) can specify the protection mode for a specific region or page of memory as plaintext (e.g., unencrypted), standard or default encryption protection (e.g., encrypted using a default or global encryption key), or custom encryption protection (e.g., encrypted using a unique encryption key). In this way, memory encryption can be provided and configured separately for different tenants, customers, or protection domains. In an example, for example, a "domain" can be considered a collection of resources associated with a particular workload, which can include any memory area containing data associated with the workload. In addition, memory encryption can be configured separately for each domain, allowing each domain or workload to be protected using a separate encryption key. In this way, encryption isolation can be achieved for workloads of different tenants, customers, or users. In addition, workloads can also be isolated from management software (e.g., a hypervisor) (e.g., of a cloud service provider). Domains can also be configured in plaintext mode, as it may not be desirable to perform memory encryption on a particular domain in certain circumstances (e.g., to avoid the performance impact of memory encryption, share memory (and I / O) between different entities, reclaim memory, etc.).

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

[0017] Figure 1is a schematic diagram illustrating an exemplary computing system 100. In various embodiments, the system 100 or its underlying components may include the cryptographic memory protection functionality described throughout this disclosure. For example, a cloud service provider 120 may host workloads 130 (e.g., virtual machines) for multiple customers or third parties. Thus, in an example, the cloud service provider 120 may implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thereby ensuring that each customer workload 130 is individually protected and isolated using a unique encryption key. Cryptographic memory protection may also be implemented by other components of the system 100, such as the edge device 110.

[0018] The edge devices 110 may include any equipment or devices deployed or connected near the "edge" of the communication system 100. In the illustrated embodiment, the edge devices 110 include end-user devices 112 (e.g., desktop computers, laptop computers, mobile devices), Internet of Things (IoT) devices 114, and network devices 116 such as gateways or routers, among other examples. The edge devices 110 can communicate with each other or with other remote networks and services (e.g., cloud services 120) via one or more networks or communication protocols (e.g., communication network 150). Furthermore, in examples, particular edge devices 110 may include the cryptographic memory protection functionality described throughout this disclosure.

[0019] End-user devices 112 may include any device that enables or facilitates user interaction with computing system 100, including, for example, desktop computers, laptop computers, tablet computers, mobile phones and other mobile devices, as well as wearable devices (e.g., smart watches, smart glasses, headphones), etc.

[0020] IoT devices 114 may include any device capable of communicating or participating in an Internet of Things (IoT) system or network. An IoT system may refer to new or improved ad-hoc systems and networks composed of multiple different devices (e.g., IoT devices 114) that interoperate and collaborate for specific applications or use cases. Such ad-hoc systems are emerging as more products and devices become "smart," meaning they are controlled or monitored by computer processors and are capable of communicating with other devices. For example, IoT devices 114 may include computer processors or communication interfaces to allow interoperability with other components of system 100 (e.g., with cloud services 120 or other edge devices 110). IoT devices 114 may be "greenfield" devices developed with IoT capabilities from the ground up, or "brownfield" devices created by integrating IoT capabilities into existing legacy devices that were originally developed without IoT capabilities. For example, in some cases, IoT devices 114 may be constructed from sensors and communication modules integrated into or attached to "things," such as equipment, toys, tools, vehicles, living things (e.g., plants, animals, humans), and the like. Alternatively or additionally, a particular IoT device 114 may rely on an intermediary component, such as an edge gateway or router 116 , to communicate with the various components of the system 100 .

[0021] Cloud services 120 may include services hosted remotely over a network 150 or in the "cloud." In an example, cloud services 120 may be hosted remotely on a server (e.g., an application server or database server) in a data center. Cloud services 120 may include any service that can be used by or for edge devices 110, including, but not limited to, data and application hosting, computing services (e.g., data analysis, search, diagnostics, and fault management), security services (e.g., monitoring, alerting, user authentication), mapping and navigation, geolocation services, network or infrastructure management, IoT applications and management services, payment processing, audio and video streaming, messaging, social networking, news and weather, and the like. Furthermore, in an example, a particular cloud service 120 may include cryptographic memory protection functionality as described throughout this disclosure. For example, a cloud service provider 120 typically hosts workloads 130 (e.g., data or applications) for multiple customers or third parties. Thus, in an example, a cloud service provider 120 may implement multi-key cryptographic memory protection to provide memory encryption on a per-tenant basis, thereby ensuring that each customer workload 130 is individually protected and isolated using a unique encryption key.

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

[0023] The exemplary embodiments described herein may include logic or multiple components, modules, circuits or engines or operate on them, and for consistency, the above items will be referred to as engines, but it will be understood that these terms can be used interchangeably. An engine can be hardware, software or firmware that is communicatively coupled to one or more electronic circuits to perform the operations described herein. An engine includes hardware, and therefore an engine is a tangible entity that can perform specified operations and can be configured or arranged in any suitable manner. In an example, an electronic circuit can be arranged in a specified manner (e.g., internally or relative to an external entity such as other circuits) as an engine. In an example, all or part of one or more computer systems (e.g., independent, client or server computer systems) or one or more hardware processors can be configured by firmware or software (e.g., instructions, application parts or applications) as an engine that operates to perform specified operations. In an example, the software can reside on a machine-readable medium (e.g., a non-temporary storage medium, such as a hardware storage device). In an example, the software causes the hardware to perform specified operations when executed by the underlying hardware of the engine.

[0024] Thus, the term "engine" is understood to encompass a tangible entity that is physically constructed, specifically configured (e.g., hardwired) or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a specified manner or to perform some or all of any of the operations described herein. Considering the example of temporarily configured engines, it is not necessary to instantiate each engine at any one time. For example, an engine comprises a general-purpose hardware processor configured using software; the general-purpose hardware processor can be configured as a corresponding different engine at different times. Thus, software can configure a hardware processor, for example, to constitute a particular engine at one time and to constitute a different engine at a different time.

[0025] Figure 2 is a high-level block diagram illustrating a host platform that can implement various embodiments. Figure 1all or part of an edge device 110 or cloud service 120. In particular embodiments, programming of the computer system 200 according to one or more particular algorithms produces a special-purpose machine when the programming is executed. In a networked deployment, the host can operate in the capacity of a server or client machine in a server-client network environment, or it can act as a peer machine in a peer-to-peer (or distributed) network environment. The host can take any suitable form factor, such as a personal computer (PC) workstation, a server, whether rack-mounted or stand-alone, a mainframe computer, a cluster computing system, etc., a set-top box, and a mobile or portable computing system, such as a laptop / notebook PC, an onboard vehicle system, a wearable device, a tablet PC, a hybrid tablet computer, a personal digital assistant (PDA), a mobile phone, or more generally, any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by the machine.

[0026] The exemplary host 200 includes at least one processor 202 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both, a processor core, a computing node, etc.), a main memory 204, and a static memory 206, which communicate with each other via a link 208 (e.g., a bus). The host 200 may also include a video display unit 210, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one embodiment, the video display unit 210, the input device 212, and the UI navigation device 214 are incorporated into a touch screen display. The host 200 may also include a storage device 216 (e.g., a drive unit), a signal generating device 218 (e.g., a speaker), a network interface device (NID) 220, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors.

[0027] The storage device 216 includes a machine-readable medium 222 having stored thereon one or more sets of data structures and instructions 224 (e.g., software) embodying or used by any one or more of the methodologies or functionality described herein. The instructions 224 may also reside, completely or at least partially, in the main memory 204, static memory 206, or in the processor 202 during execution by the host 200, with the main memory 204, static memory 206, and processor 202 also constituting machine-readable media.

[0028] Although the machine-readable medium 222 is shown as a single medium in the exemplary embodiment, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that store one or more instructions 224. The term "machine-readable medium" should also be taken to include any tangible medium that can store, encode, or carry instructions for execution by a machine and enable the machine to perform any one or more of the methods of the present disclosure, or any tangible medium that can store, encode, or carry data structures used by or associated with such instructions. Thus, the term "machine-readable medium" should be taken to include, but is not limited to, solid-state memory, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including, but not limited to, for example, semiconductor memory devices, such as electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0029] NID 220, according to various embodiments, can take any suitable form factor. In one such embodiment, NID 220 takes the form of a network interface card (NIC) that interfaces with processor 202 via link 208. In one example, link 208 comprises a PCI Express (PCIe) interconnect, including a slot into which a NIC form factor can be removably interfaced. In another embodiment, NID 220 is a network interface circuit disposed on a motherboard along with local link circuitry, processor interface circuitry, other input / output circuitry, memory circuitry, storage devices, and peripheral controller circuitry. In another embodiment, NID 220 is a peripheral device that interfaces with link 208 via a peripheral input / output port (e.g., a universal serial bus (USB) port). NID 220 transmits and receives data via a transmission medium 226, which can be wired or wireless (e.g., radio frequency, infrared, or visible spectrum), fiber optic, or the like.

[0030] Figure 3 It shows that Figure 2, wherein the various interfaces between the hardware components and the software components are shown. As indicated by the "HW" label, the hardware components are represented below the dividing line, while the software components represented by the "SW" label are located above the dividing line. On the hardware side, each processing device 302 having one or more processor cores (which may include one or more microprocessors, digital signal processors, etc.) is coupled to a memory management device 304 and a system interconnect 306. The memory management device 304 provides a mapping between virtual memory used by the executing process and physical memory. The memory management device 304 can be an integral part of a central processing unit that also includes the processing device 302.

[0031] Interconnect 306 includes a backplane such as memory, data, and control lines, as well as interfaces with input / output devices such as PCI-e, USB, etc. Memory 308 (e.g., dynamic random access memory (DRAM)) and non-volatile memory 309 such as flash memory (e.g., electrically erasable read-only memory (EEPROM), NAND flash, NOR flash, etc.) interface with memory management device 304 and interconnect 306 via memory controller 310. I / O devices (including video and audio adapters, non-volatile storage devices, external peripheral links (e.g., USB), personal area networks (e.g., Bluetooth), etc., camera / microphone data capture devices, fingerprint readers and other biometric sensors, and network interface devices such as those communicating via Wi-Fi or LTE serial interfaces) are collectively represented as I / O devices and networks 312, which interface with interconnect 306 via corresponding I / O controllers 314.

[0032] In a related embodiment, the input / output memory management unit IOMMU 315 supports secure direct memory access (DMA) by peripheral components. The IOMMU 315 can provide memory protection by considering accesses to memory 308 from I / O devices 312. The IOMMU 315 can also provide DMA memory protection in a virtualized environment, where it allows specific computing hardware resources to be assigned to specific guest VMs running on the system and enforces isolation between other VMs and peripheral components not assigned to them.

[0033] On the software side, the pre-operating system (pre-OS) environment 316 executes during initial system boot and is responsible for initiating the boot of the operating system. A traditional example of a pre-OS environment 316 is the system basic input / output system (BIOS). In today's systems, the Unified Extensible Firmware Interface (UEFI) is implemented. The pre-OS environment 316 is responsible for initiating the boot of the operating system or virtual machine manager, but also provides an execution environment for embedded applications.

[0034] Hypervisor 318 is system software that creates and controls the execution of virtual machines (VMs) 320A and 320B. Hypervisor 318 can run directly on the hardware HW, as shown, or it can run as a hosted hypervisor under the control of an operating system. Each VM 320A, 320B includes a guest operating system 322A, 322B and application programs 324A, 324B.

[0035] Each guest operating system (OS) 322A, 322B provides a kernel that operates via resources provided by the hypervisor 318 to control hardware devices, manage memory access for programs in memory, coordinate tasks and facilitate multitasking, organize data to be stored, allocate storage space and other resources, load program binary code into memory, initiate execution of the corresponding application program, which then interacts with the user and the hardware devices, and detect and respond to various defined interrupts. In addition, each guest OS 322A, 322B provides device drivers and various common services, such as services that facilitate interfacing with peripheral components and networks, and provides abstractions for the corresponding application programs 324A, 324B so that the application does not need to be responsible for handling the details of such common operations. Each guest OS 322A, 322B can also provide a graphical user interface (GUI) that facilitates interaction with the user via peripheral devices (e.g., monitor, keyboard, mouse, microphone, camera, touch screen, etc.). In an example, the guest OS 322B can omit the GUI.

[0036] Each guest OS 322A, 322B may provide a runtime system that implements portions of the execution model, including operations such as placing parameters on a stack before a function call, disk input / output (I / O) behavior, and parallel execution-related behavior.

[0037] In addition, each guest OS 322A, 322B may provide a library comprising a set of program functions that provide further abstraction for the corresponding application, for example, these include shared libraries, dynamic link libraries (DLLs).

[0038] Application programs 324A, 324B are those programs that perform useful tasks for the user beyond those performed by the lower-level system programs that coordinate the basic operability of the computer system itself.

[0039] Figure 4is a functional diagram illustrating the operation of a multi-key memory encryption arrangement according to some embodiments. Workloads 402A and 402B can be implemented as isolated VMs. Each workload 402 will have its corresponding data optionally encrypted with its own cryptographic key so that other workloads (or any other entity) cannot decrypt the stored data.

[0040] The secure memory allocator 404 allocates memory addresses (e.g., which may be in units of memory pages 416 or other logical blocks of memory) to corresponding workloads 402. In an example, the secure memory allocator 404 associates each memory write operation with a secure / non-secure mode. In secure mode, the data to be written is encrypted; whereas in non-secure mode, the data to be written remains in plain text. In an example, the secure memory allocator 404 may be implemented using a hypervisor. In an example of operation, as Figure 4 As shown, secure memory allocator 404 allocates two memory pages to workload 402A and another two memory pages to workload 402b.

[0041] A multi-key encryption (MKE) engine 406 performs cryptographic operations and operations related to encrypting and decrypting data being written to and read from memory 418 (which may store pages 416). The MKE engine 406 may be implemented as an isolated execution environment.

[0042] Each allocated memory page will be associated with a key identifier (keyID) corresponding to a specific cryptographic key. Each keyID is a pointer or reference to a specific cryptographic key that is stored separately from the memory 418, secure memory allocator 404, and workload 402. In the example, Figure 4 As shown, the key lookup data store 408 can be contained in the memory 418, in the MKE engine 406, or elsewhere that the MKE engine 406 can effectively access, as will be described below. The key lookup data store 408 associates the keyID with the corresponding cryptographic key. The key lookup data store 408 can be implemented using any suitable data structure.

[0043] In a related embodiment, the keys stored in key lookup data store 408 are themselves encrypted (e.g., wrapped with a secret key known only to the hardware platform, or derived as a fuse key or physically unclonable function (PUF) circuit).

[0044] Note that in examples, a particular keyID may not be associated with any key. Memory requests received with such a keyID completely bypass the encryption engine. In examples, this bypass can be implemented to allow for performance benefits. In a related embodiment, a non-encrypted operating mode can be selected by secure memory allocator 404, in which case the MK encryption operation is completely bypassed to improve memory access performance.

[0045] The MKE engine 406 accesses the key lookup data store 408 to retrieve keys as needed to encrypt or decrypt data being written to or read from memory 418. In doing so, the MKE engine 406 can cache individual keys, assuming they will be reused for subsequent memory accesses, for faster retrieval. The key lookup data store 408 is indexed by the keyID of the corresponding key in the index entry. If a new key is added to the table or an existing key entry is modified, the cache for the key should be cleared and all processor translation lookaside buffer (TLB) states should be cleared.

[0046] The MKE engine 406 also accesses a key mapping data store 410. The key mapping data store 410 associates a keyID with a physical memory address or page. The key mapping data store 410 can be maintained in the memory 418 or other suitable storage location of the computing platform that the MKE engine 406 can efficiently access. The key mapping data store 410 can be implemented as a table or any other suitable data structure.

[0047] In an example, each entry in the key mapping data repository 410 table can be encrypted using the corresponding key domain key, thereby proving that the owner of the key confirms ownership of the associated memory page. This is the same key that the MKE engine 406 can use to encrypt (when writing to memory) or decrypt (when reading from memory) data to be written to or read from the associated memory page. In a related example, each entry in the key mapping data repository 410 has an unencrypted portion, the keyID (located at an index based on the page address). Each entry also has an encrypted portion that includes the memory address, an integrity check value (which can be a fixed value), and a version number.

[0048] When a workload accesses memory to perform a read or write operation, the MKE engine 406 uses the key mapping data store 410 to look up the keyID corresponding to the page-granularity address. In this example, keyIDs 408A1 and 408A2 are associated with page addresses 416A1 and 416A2, respectively, each corresponding to workload 402A. Similarly, keyIDs 408B1 and 408B2 are associated with page addresses 416B1 and 416B2, respectively, each corresponding to workload 402B.

[0049] Using each keyID 408, the MKE engine 406 looks up the corresponding cryptographic key from the key lookup data store 408 and uses the key to decrypt the encrypted portion of the P2K entry. If the entry address matches the memory address (page granularity) of the memory read / write, the key mapping is considered valid and the MKE engine 406 uses the key to decrypt / encrypt the data being read or written, as shown at 414.

[0050] MKE engine 406 also accesses key tracking log 412. Key tracking log 412 operates as a cache to contain addresses currently being manipulated by one or more workloads 402. Key tracking log 412 can be implemented as part of the hardware that makes up MKE engine 406, or as a set of circuits isolated from access by any workload 402. In response to a protected memory read operation, key tracking log 412 records the memory address or page and keyID of the data being read. Subsequently, when the same workload 402 continues to write data back to memory 418, the corresponding keyID write operation is looked up in key tracking log 412, rather than having to read key mapping data repository 410 from memory.

[0051] In the example, eviction of an entry from key tracking log 412 occurs under two conditions. One condition is in response to the eviction of an operated protected data line from the processor cache. This occurs when it is written with new secret data. The other condition is in response to a silent discard from the last-level cache (LLC). If the data has not been written, the replacement of the data line in the LLC will not be written back to memory because the data has not been updated. This may cause key tracking log 412 to fill up with read-only data.

[0052] Therefore, in a related embodiment, a DropReadData message is employed. This is a message sent from the core to the MKE engine 406 when silently discarding a read-only row. The DropReadData message contains the address of the entry being discarded. This message is terminated in the MKE engine, allowing it to discard the read-only data from the key tracking log 412, thereby enabling the log 412 to track only the contents of the core cache. Note that in this example, rows that were originally read from memory in a clear text state are not tracked in the key tracking log 412.

[0053] Figure 5 5 is a partial system architecture diagram illustrating a machine-based implementation of a multi-key memory encryption arrangement according to various embodiments. Memory structure 502 includes an adaptive interconnect that facilitates access to memory circuit 516 via memory controller 518 and MKE circuit 510. Data port 506 connects an immersion interconnect (IDI) agent (e.g., a processor core, a graphics engine) to memory structure 502. Input / output (I / O) port 508 connects an I / O controller to memory structure 502 to support direct memory access by I / O devices.

[0054] MKE circuit 510 implements the above ( Figure 4 ) discussed above. In an example, the MKE circuit 510 is implemented using dedicated hardware circuitry that may include an arithmetic logic unit (ALU) or dedicated logic optimized for cryptographic operations, data registers, local cache memory, data and address bus interfaces, etc. In one example, the MKE circuit 510 is implemented on a dedicated coprocessor. In the example shown, the MKE circuit 510 stores a key tracking table (KTT) 512 (which is a key table referenced above). Figure 4 ), and optionally, LLC mirror logic 514, which is discussed in more detail below.

[0055] Memory controller 518 facilitates the logical to physical memory interface, including maintaining data in DRAM devices and performing read and write operations. Memory controller 518 may include a static RAM buffer cache for faster operation than the higher density storage media (e.g., DRAM) that make up the majority of memory 516.

[0056] Memory 516 contains data pages that may be associated with various VMs or workloads. Additionally, memory 516 contains a physical memory to key (P2K) table 520 (which is referenced above). Figure 4524. The key lookup table 524 is an implementation of the key lookup data store 408 (described above with reference to FIG. Figure 4 discussed).

[0057] Figure 6 is a flow chart illustrating KTT-related operations performed by the MKE circuit 510 in response to a memory read operation, according to an example. At 602, the MKE circuit 510 receives a memory read instruction from a processor core. At 604, the MKE circuit 510 determines whether the read instruction is a protected read. A protected read is a read that requires decryption of the stored data being read. If the read operation does not require a protected read, the process proceeds to 606, where the MKE circuit 510 passes the read command to the memory controller 518, receives the data, and passes it to the processor core that issued the read instruction without performing any decryption. If the read operation is a protected read, the process proceeds to 608, where the MKE circuit 510 adds the physical address (PA) or a tag representing the PA and the applicable keyID from the P2K table 520 to the KTT 512. At 610, the MKE circuit 510 retrieves the cryptographic key associated with the keyID and uses the key to decrypt the data to produce the plaintext data. At 612 , the MKE circuit 510 passes the plaintext data to the processor core that issued the read command.

[0058] Figure 7 is a flow chart illustrating KTT-related operations performed by the MKE circuit 510 in response to a memory write operation according to an example. At 702, the MKE circuit 510 receives a memory write instruction from a processor core. Separately, at 704, the MKE circuit 510 may receive a DropReadData command from the processor core in place of the memory write instruction. At 706, the MKE circuit 510 reads the KTT 512 and determines whether the address associated with the write or DropReadData command exists in the KTT 512. If the address is not in the KTT 512, the process proceeds to 708, where the MKE circuit 510 passes the data to be written (if any) to the memory controller 518 without performing any encryption on the data. Otherwise, if the write address exists in the KTT 512, operation 710 reads the KTT entry and deletes the corresponding entry from the KTT 512. At 712, if there is data to be written, the MKE circuit 510 encrypts the data using the cryptographic key associated with the keyID obtained from the KTT 512 (now deleted in the KTT) to produce ciphertext data. At 714, the ciphertext data is passed to the memory controller 518 to be written to the memory 516.

[0059] return Figure 5 LLC mirroring logic 514 is an optional feature that tracks LLC state in MKE circuit 510, which is essentially equivalent to locally storing LLC tags and the KEYID associated with each data row in the memory provision of MKE circuit 510. LLC mirroring logic 514 allows KTT 512 to be managed by MKE circuit 510 without relying on DropReadData messaging.

[0060] The RMT 522 is used to determine whether the physical pages in the memory are assigned to the correct domain and whether their mapping to the guest physical addresses is correct. The RMT 522 is a table managed by the core that contains entries associating guest physical addresses (e.g., what each workload or VM presents), and the actual hardware physical address to which the guest physical address is mapped as understood by the memory controller 518, as well as the VM / workload to memory page assignments, and the read / write permissions associated with the addresses. The entries are encrypted with the domain key to allow domains to authorize memory mappings. On a TLB miss, the RMT 522 is looked up before the mapping is installed in the TLB. Any attack attempting to map pages belonging to a different domain is not allowed because the incorrect key will be used to decrypt the RMT entry and the implicit integrity maintained in each RMT entry will fail.

[0061] RMT 522 and P2K table 520 can be used together. In response to a memory read, MKE circuit 510 uses P2K table 520 to determine the keyID and then uses the keyID to look up the key for decrypting the data being read from memory. The key can be stored in key lookup table 524 in memory 516, wrapped with a key known only to MT encryption circuit 510. Similar to other memory accesses, when an RMT entry is read from RMT 522, P2K table 520 is looked up to obtain the associated keyID, and the correctly decrypted RMT entry verifies the guest physical address to hardware physical address mapping.

[0062] Figure 4-5 One advantage of the embodiments shown in is that they are immune to certain types of hacker attacks in which an attacker with hardware access to the system causes the workload / VM to leak plaintext information. According to a hardware replay attack, the attacker replays or modifies the key table stored in memory during a time window that falls between a read operation and a write operation. The attack causes the read operation to be decrypted with the correct key associated with the workload, but the operation bypasses the cryptographic protection (e.g., writes back the data in plaintext) under the guidance of the replayed key table in memory.

[0063] Advantageously, some embodiments described herein use a key tracking log 412 ( Figure 4 ) Identify and address the vulnerability window between read and write operations, which can be implemented as KTT 512 ( Figure 5 For example, the use of the key tracking log 412 or KTT 512 eliminates the need to re-read the P2K tables 410, 520 from the memory 418, 516 (which may be compromised by an attack) for a write operation following a read operation.

[0064] In addition to causing confidentiality leaks, an attacker can also cause cross-domain injection attacks. As an example, an attacker monitors memory accesses by a first workload / VM and records a copy of the physical page and the corresponding P2K table entry. Later, when the physical page is allocated to a second workload / VM, the attacker replays or replaces the page content and the P2K table entry corresponding to the page with the previously recorded copy of the page content and the P2K table entry. This will cause the data of the first workload or VM to be correctly decrypted and sent to the second workload / VM. In this attack, the second workload / VM remains unaware that it has been fed incorrect data.

[0065] According to related embodiments, salting technology is used to protect systems from cross-domain injection attacks. Salting workloads or VMs ensures that the processor core always knows the identity of the VM or workload it is executing. For each page created and associated with a workload, the processor core associates a random or quasi-random number. This random or quasi-random number is stored in the page's RMT and P2K entries. This unique random number associated with each workload is called the VM or workload salt.

[0066] Figure 8 is a diagram showing the process of generating a signal by an MKE engine (eg, MKE engine 406 ( Figure 4)) is a flowchart of operations performed in collaboration with a processor core. At 802, the processor core sends a read request to / from the MKE engine 406. At 804, the MK encryption 406 reads the P2K table 410 to obtain the keyID, physical address, and salt value from the P2K table. At 806, the MKE engine 406 decrypts the ciphertext data read from the memory 418 using the cryptographic key referenced by the keyID from the P2K table 410 to generate a plaintext version (PT) of the data. At 808, the MKE engine 406 calculates the XOR of the PT using the salt SALT_P2K from the P2K table to calculate the salted version PT_SALT of the data. At 810, the MKE engine 406 passes the salted plaintext data PT_SALT to the processor core requesting the read. At 812, the processor core retrieves the salt value SALT_RMT stored in the RMT entry. At 814, the processor core performs an XOR operation using SALT_RMT and the salted data PT_SALT received from the MKE engine to produce the final plaintext value FINAL_PT. If the cross-domain replay attack outlined above is attempted, the two salts from P2K and RMT will not match, and the final value FINAL_PT will result in garbage data, thereby resisting the attack.

[0067] An attacker could also attempt to modify the RMT to replace a current RMT entry with an older one. However, the RMT is managed by the core, and the core knows the identity of the currently executing VM or workload. Therefore, using an RMT entry from a different domain is not possible without detection. Furthermore, because the fields in the RMT are encrypted with implicit integrity, an attacker cannot modify parts of an RMT entry without detection. Therefore, any attempt to change the salt alone in an RMT entry without also changing the domain ID will be detected by the core because the implicit integrity check will fail.

[0068] Additional notes and examples:

[0069] Example 1 is an apparatus for secure memory access in a computing platform, the apparatus comprising: computing hardware including at least one processor core, memory, and a memory interface communicatively coupled to the at least one processor core, wherein the at least one processor core is used to execute multiple workloads, each workload utilizing an allocated portion of the memory, and wherein the memory interface includes a multi-key encryption (MKE) engine; a storage medium containing a key mapping data repository accessible to the MKE engine, the key mapping data repository containing associations between identifiers of portions of memory and corresponding key identification data; and a storage medium containing a key tracking log accessible to the MKE engine; wherein the MKE engine is used to: perform key-based cryptographic operations on data to be read from or written to memory to isolate specific portions of the portions of memory from workloads that are not allocated to those portions of memory; determine a cryptographic key for the cryptographic operations based on the key mapping data repository; and temporarily store entries in the key tracking log during memory access operations on portions of memory, the entries containing identifiers of the portions of memory and corresponding key identification data for those portions of memory.

[0070] In Example 2, the subject matter of Example 1 includes: wherein the MKE engine is used to: in response to a read operation requiring reading a first portion of a memory corresponding to a first memory portion identifier, store a first entry representing the first memory portion identifier and the corresponding first key identifier in a key tracking log; and in response to a subsequent write operation requiring writing to the first portion of the memory, read the first entry from the key tracking log to retrieve the first key identifier, and apply a first cryptographic key corresponding to the first key identifier to encrypt the data to be written to the first portion of the memory before writing the data.

[0071] In Example 3, the subject matter of Examples 1-2 includes wherein the MKE engine and the key tracking log are each isolated from access communications by the at least one processor core.

[0072] In Example 4, the subject matter of Examples 1-3 includes: wherein the MKE engine includes a data repository, and wherein the key tracking log is contained in the data repository of the MKE engine.

[0073] In Example 5, the subject matter of Examples 1-4 includes wherein each of the plurality of workloads is implemented as a virtual machine.

[0074] In Example 6, the subject matter of Examples 1-5 includes: wherein the key mapping data store is contained in the memory.

[0075] In Example 7, the subject matter of Examples 1-6 includes wherein the allocated portion of memory is a memory page.

[0076] In Example 8, the subject matter of Examples 1-7 includes a key lookup data store containing a set of cryptographic keys, each cryptographic key associated with a key identifier of key identification data contained in a key mapping data store.

[0077] In Example 9, the subject matter of Example 8 includes: wherein the key lookup data store is contained in the memory, and wherein each cryptographic key in the key lookup data store is encrypted such that only an MKE engine can recover the cryptographic key.

[0078] In Example 10, the subject matter of Examples 1-9 includes wherein the MKE engine is to receive a command from the at least one processor core to remove an entry from the key tracking log.

[0079] In Example 11, the subject matter of Examples 1-10 includes wherein the MKE engine is to store a copy of a last level cache (LLC) of the at least one processor core.

[0080] In Example 12, the subject matter of Examples 1-11 includes: wherein a unique salt value is associated with each workload and stored in a data repository managed by a processor core, and wherein a copy of each unique salt value associated with each workload is stored in a data repository managed by an MKE engine, and wherein each unique salt value is associated with an allocated portion of memory corresponding to each respective workload; and wherein, in response to a read operation by a first workload to retrieve a first set of data from memory, the MKE engine combines the first set of data with the associated first salt value from the data repository managed by the MKE engine to produce a first salted value, and thereafter passes the first salted data to at least one processor on which the first workload is executed.

[0081] In Example 13, the subject matter of Example 12 includes: wherein the MKE engine managed data repository and the processor core managed data repository are each contained within a memory.

[0082] In Example 14, the subject matter of Examples 12-13 includes: wherein, in response to receiving first salted data in response to a read operation, the at least one processor core combines the first salted data with an associated salt value from a data repository managed by the processor core to recover a first set of data.

[0083] Example 15 is a method for secure memory access in a computing platform, the method comprising: executing multiple workloads by at least one processor core of the computing platform, each workload utilizing an allocated portion of memory; and performing key-based encryption by a multi-key encryption (MKE) engine, including performing operations on data to be read from or written to portions of memory to isolate specific portions of the portions of memory from workloads that are not allocated to those portions of memory; maintaining a key mapping data repository accessible to the MKE engine, and the key mapping data repository containing associations between identifiers of portions of memory and corresponding key identification data, the MKE engine determining a cryptographic key based on the corresponding key identification data, and utilizing the cryptographic key to perform cryptographic isolation; and maintaining a key tracking log by the MKE engine, wherein the MKE engine is used to temporarily store entries in the key tracking log during memory access operations on portions of memory, the entries containing identifiers of the portions of memory and corresponding key identification data for those portions of memory.

[0084] In Example 16, the subject matter of Example 15 includes: wherein the MKE engine performs: in response to a read operation requiring reading a first portion of a memory corresponding to a first memory portion identifier, storing a first entry representing the first memory portion identifier and the corresponding first key identifier in a key tracking log; and in response to a subsequent write operation requiring writing to the first portion of the memory, reading the first entry from the key tracking log to retrieve the first key identifier, and applying a first cryptographic key corresponding to the first key identifier to encrypt the data to be written to the first portion of the memory before writing the data.

[0085] In Example 17, the subject matter of Examples 15-16 includes wherein the MKE engine and the key tracking log are each communicatively isolated from access by the at least one processor core.

[0086] In Example 18, the subject matter of Examples 15-17 includes: wherein each of the plurality of workloads is implemented as a virtual machine.

[0087] In Example 19, the subject matter of Examples 15-18 includes: wherein the key mapping data store is contained in the memory.

[0088] In Example 20, the subject matter of Examples 15-19 includes: wherein the allocated portion of memory is a memory page.

[0089] In Example 21, the subject matter of Examples 15-20 includes maintaining a key lookup data store containing a set of cryptographic keys, each cryptographic key associated with a key identifier of key identification data contained in a key mapping data store.

[0090] In Example 22, the subject matter of Example 21 includes: wherein the key lookup data store is contained in the memory, and wherein each cryptographic key in the key lookup data store is encrypted such that only an MKE engine can recover the cryptographic key.

[0091] In Example 23, the subject matter of Examples 15-22 includes wherein the MKE engine receives and processes a command from the at least one processor core to remove an entry from the key tracking log.

[0092] In Example 24, the subject matter of Examples 15-23 includes: wherein the MKE engine stores a copy of a last level cache (LLC) of the at least one processor core.

[0093] In Example 25, the subject matter of Examples 15-24 includes: wherein a unique salt value is associated with each workload and stored in a data repository managed by a processor core, and wherein a copy of each unique salt value associated with each workload is stored in a data repository managed by an MKE engine, and wherein each unique salt value is associated with an allocated portion of memory corresponding to each respective workload; and wherein, in response to a read operation performed by a first workload to retrieve a first set of data from memory, the MKE engine combines the first set of data with the associated first salt value from the data repository managed by the MKE engine to produce a first salted value, and thereafter passes the first salted data to at least one processor on which the first workload is executed.

[0094] In Example 26, the subject matter of Example 25 includes: wherein, in response to receiving first salted data in response to a read operation, the at least one processor core combines the first salted data with an associated salt value from a data repository managed by the processor core to recover a first set of data.

[0095] Example 27 is at least one machine-readable medium comprising instructions that, when executed by a computing platform, cause the computing platform to: execute multiple workloads by at least one processor core of the computing platform, each workload utilizing an allocated portion of memory; and perform key-based encryption by a multi-key encryption (MKE) engine, including performing operations on data to be read from or written to portions of memory to isolate specific portions of the portions of memory from workloads that are not allocated to those portions of memory; maintain a key mapping data repository accessible to the MKE engine, and the key mapping data repository contains associations between identifiers of portions of memory and corresponding key identification data, a cryptographic key determined by the MKE engine based on the corresponding key identification data to perform cryptographic isolation; and maintain a key tracking log by the MKE engine, and cause the MKE engine to temporarily store entries in the key tracking log during memory access operations on portions of memory, the entries containing identifiers of the portions of memory and corresponding key identification data for those portions of memory.

[0096] In Example 28, the subject matter of Example 27 includes: wherein the instructions cause the MKE engine of the computing platform to: in response to a read operation requiring reading a first portion of a memory corresponding to a first memory portion identifier, store a first entry representing the first memory portion identifier and the corresponding first key identifier in a key tracking log; and in response to a subsequent write operation requiring writing to the first portion of the memory, read the first entry from the key tracking log to retrieve the first key identifier, and apply a first cryptographic key corresponding to the first key identifier to encrypt the data to be written to the first portion of the memory before writing the data.

[0097] In Example 29, the subject matter of Examples 27-28 includes wherein the MKE engine and the key tracking log are each communicatively isolated from access by the at least one processor core.

[0098] In Example 30, the subject matter of Examples 27-29 includes: wherein each of the plurality of workloads is implemented as a virtual machine.

[0099] In Example 31, the subject matter of Examples 27-30 includes: wherein the key mapping data repository is contained in the memory.

[0100] In Example 32, the subject matter of Examples 27-31 includes: wherein the allocated portion of memory is a memory page.

[0101] In Example 33, the subject matter of Examples 27-32 includes: wherein the instructions cause the MKE engine to: maintain a key lookup data store containing a set of cryptographic keys, each cryptographic key associated with a key identifier of key identification data contained in a key mapping data store.

[0102] In Example 34, the subject matter of Example 33 includes: wherein the key lookup data store is contained in the memory, and wherein each cryptographic key in the key lookup data store is encrypted such that only an MKE engine can recover the cryptographic key.

[0103] In Example 35, the subject matter of Examples 27-34 includes wherein, according to the instructions, the MKE engine receives and processes a command from the at least one processor core to remove an entry from the key tracking log.

[0104] In Example 36, the subject matter of Examples 27-35 includes: wherein, according to the instruction, the MKE engine stores a copy of a last level cache (LLC) of the at least one processor core.

[0105] In Example 37, the subject matter of Examples 27-36 includes: wherein the instructions cause the computing platform to: associate a unique salt value with each workload and store it in a data repository managed by a processor core, wherein a copy of each unique salt value associated with each workload is stored in a data repository managed by an MKE engine, and wherein each unique salt value is associated with an allocated portion of memory corresponding to each respective workload; and in response to a read operation performed by a first workload to retrieve a first set of data from memory, the MKE engine combines the first set of data with the associated first salt value from the data repository managed by the MKE engine to produce a first salted value, and thereafter passes the first salted data to at least one processor on which the first workload is executed.

[0106] In Example 38, the subject matter of Example 37 includes: wherein the instructions cause at least one processor core of the computing platform to: in response to receiving first salted data in response to a read operation, combine the first salted data with an associated salt value from a data repository managed by the processor core to recover a first set of data.

[0107] Example 39 is a system for secure memory access in a computing platform, the system comprising: a unit for executing multiple workloads by at least one processor core of the computing platform, each workload utilizing an allocated portion of memory; and a unit for performing key-based encryption, comprising performing operations on data to be read from or written to portions of memory to isolate specific portions of the portions of memory from workloads that are not allocated to those portions of memory; a unit for maintaining, by the unit for performing key-based encryption, a key mapping data repository, the key mapping data repository containing associations between identifiers of portions of memory and corresponding key identification data, a cryptographic key determined based on the corresponding key identification data for use by the unit for performing key-based encryption to perform cryptographic isolation; and a unit for maintaining, by the unit for performing key-based encryption, a key tracking log, wherein the unit for performing key-based encryption temporarily stores entries in the key tracking log during memory access operations on portions of memory, the entries containing identifiers of the portions of memory and corresponding key identification data for those portions of memory.

[0108] In Example 40, the subject matter of Example 39 includes: wherein the unit for performing key-based encryption includes: a unit for storing a first entry representing the first memory portion identifier and the corresponding first key identifier in a key tracking log in response to a read operation requiring reading a first portion of a memory corresponding to a first memory portion identifier; and a unit for reading the first entry from the key tracking log to retrieve the first key identifier and applying a first cryptographic key corresponding to the first key identifier to encrypt the data to be written to the first portion of the memory before writing the data.

[0109] In Example 41, the subject matter of Examples 39-40 includes wherein the unit for performing key-based encryption and the key tracking log are each communicatively isolated from access by the at least one processor core.

[0110] In Example 42, the subject matter of Examples 39-41 includes: wherein each of the plurality of workloads is implemented as a virtual machine.

[0111] In Example 43, the subject matter of Examples 39-42 includes: wherein the key mapping data repository is contained in the memory.

[0112] In Example 44, the subject matter of Examples 39-43 includes: wherein the allocated portion of memory is a memory page.

[0113] In Example 45, the subject matter of Examples 39-44 includes maintaining a key lookup data store containing a set of cryptographic keys, each cryptographic key associated with a key identifier of key identification data contained in a key mapping data store.

[0114] In Example 46, the subject matter of Example 45 includes: wherein the key lookup data store is contained in the memory, and wherein each cryptographic key in the key lookup data store is encrypted such that only a unit for performing key-based encryption can recover the cryptographic key.

[0115] In Example 47, the subject matter of Examples 39-46 includes wherein the means for performing key-based encryption is to receive and process a command from the at least one processor core to remove an entry from the key tracking log.

[0116] In Example 48, the subject matter of Examples 39-47 includes: wherein the means for performing key-based encryption stores a copy of a last level cache (LLC) of the at least one processor core.

[0117] In Example 49, the subject matter of Examples 39-48 includes: wherein a unique salt value is associated with each workload and stored in a data repository managed by a processor core, and wherein a copy of each unique salt value associated with each workload is stored in a data repository for performing key-based cryptographic management, and wherein each unique salt value is associated with an allocated portion of memory corresponding to each respective workload; and wherein, in response to a read operation performed by a first workload to retrieve a first set of data from memory, the unit for performing key-based cryptographic management combines the first set of data with the associated first salt value from the data repository managed by the MKE engine to produce a first salted value, and thereafter passes the first salted data to at least one processor on which the first workload is executed.

[0118] In Example 50, the subject matter of Example 49 includes: wherein, in response to receiving first salted data in response to a read operation, the at least one processor core combines the first salted data with an associated salt value from a data repository managed by the processor core to recover a first set of data.

[0119] Example 51 is at least one machine-readable medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform operations to implement any of Examples 1-50.

[0120] Example 52 is a device comprising means for implementing any one of Examples 1-50.

[0121] Example 53 is a system for implementing any of Examples 1-50.

[0122] Example 54 is a method for implementing any one of Examples 1-50.

[0123] The above detailed description includes reference to the accompanying drawings, which form a part of the detailed description. The accompanying drawings illustrate specific embodiments that can be put into practice by way of illustration. These embodiments are also referred to as "examples" in this article. These examples may include elements other than those shown or described. However, it is also conceivable that examples include the elements shown or described. In addition, it is also contemplated that examples using any combination or permutation of those elements (or one or more aspects thereof) shown or described with respect to the specific examples (or one or more aspects thereof) shown or described herein or with respect to other examples (or one or more aspects thereof) are also contemplated.

[0124] In this document, the terms "a" or "an" are common in patent literature and include one or more than one, independent of any other instance or usage of "at least one" or "one or more." In this document, the term "or" is used to represent a non-exclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In the appended claims, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Furthermore, in the following claims, the terms "including" and "comprising" are open-ended, that is, systems, devices, articles, or processes that include elements other than the elements listed after such terms in a claim are still considered to fall within the scope of the claim. Furthermore, in the following claims, the terms "first," "second," and "third," etc., are used merely as labels and are not intended to imply a numerical order of their objects.

[0125] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more aspects thereof) may be used in combination with other examples. After reviewing the above description, other embodiments may be used by, for example, a person of ordinary skill in the art. The abstract is used to enable the reader to quickly determine the nature of the technical disclosure. It should be understood at the time of submission that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the above detailed description, various features may be combined together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein, as an embodiment may feature a subset of the features described. In addition, an embodiment may include fewer features than those disclosed in a particular example. Therefore, the following claims are hereby incorporated into the detailed description, with the claims themselves serving as separate embodiments. The scope of the embodiments disclosed herein will be determined with reference to the appended claims and the full scope of equivalents to which such claims are assigned.

Claims

1. An apparatus for secure memory access in a computing platform, the apparatus comprising: Computing hardware comprising at least one processor core, memory, and a memory interface communicatively coupled to the at least one processor core, wherein the at least one processor core is configured to execute a plurality of workloads, each workload utilizing a respective portion of an allocation of memory, and wherein the memory interface comprises a multi-key encryption (MKE) engine; a storage medium comprising a key mapping data repository accessible to the MKE engine, the key mapping data repository comprising associations between identifiers of portions of the memory and corresponding key identification data; and a storage medium containing a key tracking log accessible to the MKE engine; The MKE engine is used to: performing a key-based cryptographic operation on data to be read from or written to the memory to isolate a specific portion of the portion of the memory from a workload not allocated the specific portion of the memory; determining a cryptographic key for the cryptographic operation based on the key mapping data store; and temporarily storing an entry in the key tracking log during a memory access operation to the particular portion of memory, the entry comprising an identifier of the portion of memory and corresponding key identification data for the particular portion of memory, The identifier of the portion of the memory comprises at least one of a physical memory address or a memory page.

2. The device according to claim 1, wherein The MKE engine is used to: In response to a read operation requesting a read of a first portion of memory corresponding to a first memory portion identifier, storing a first entry in the key tracking log representing the first memory portion identifier and a corresponding first key identifier; as well as In response to a subsequent write operation requiring a write to the first portion of the memory, the first entry is read from the key tracking log to retrieve the first key identifier, and a first cryptographic key corresponding to the first key identifier is applied to encrypt the data before writing the data to be written to the first portion of the memory.

3. The device according to claim 1, wherein The MKE engine and the key tracking log are each communicatively isolated from access by the at least one processor core.

4. The device according to claim 1, wherein The MKE engine includes a data repository, and wherein the key tracking log is contained in the data repository of the MKE engine.

5. The device according to claim 1, wherein The key mapping data repository is contained in the memory.

6. The apparatus according to claim 1, further comprising: A key lookup data store contains a set of cryptographic keys, each of the cryptographic keys being associated with a key identifier of the key identification data contained in the key mapping data store.

7. The device according to claim 6, wherein The key lookup data store is contained in the memory, and wherein each of the cryptographic keys in the key lookup data store is encrypted such that only the MKE engine can recover the cryptographic key.

8. The device according to claim 1, wherein The MKE engine is configured to receive a command from the at least one processor core to remove an entry from the key tracking log.

9. The device according to any one of claims 1 to 8, wherein: The MKE engine is configured to store a copy of a last level cache (LLC) of the at least one processor core.

10. The device according to any one of claims 1 to 8, wherein A unique salt value is associated with each workload and stored in a data store managed by the processor core, and wherein a copy of each unique salt value associated with each workload is stored in a data store managed by the MKE engine, and wherein each unique salt value is associated with a respective portion of an allocation of memory corresponding to each respective workload; and In which, in response to a read operation performed by a first workload to retrieve a first set of data from the memory, the MKE engine is used to combine the first set of data with an associated first salt value from a data repository managed by the MKE to generate a first salted value, and then pass the first salted data to at least one processor on which the first workload is executed.

11. The device according to claim 10, wherein The data storage repository managed by the MKE and the data storage repository managed by the processor core are each contained in the memory.

12. The device according to claim 10, wherein In response to receiving first salted data in response to a read operation, the at least one processor core is operable to combine the first salted data with an associated salt value from a data repository managed by the processor core to recover the first set of data.

13. A method for secure memory access in a computing platform, the method comprising: executing, by at least one processor core of the computing platform, a plurality of workloads, each workload utilizing a respective portion of the allocation of memory; as well as performing, by a multi-key encryption (MKE) engine, key-based encryption, including performing operations on data to be read from or written to the portions of the memory to isolate specific ones of the portions of the memory from workloads not allocated the specific portions of the memory; maintaining, by the MKE engine, a key mapping data store containing associations between identifiers of portions of the memory and corresponding key identification data, cryptographic keys being determined based on the corresponding key identification data for use by the MKE engine in performing cryptographic isolation; as well as maintaining a key tracking log by the MKE engine, wherein the MKE engine is to temporarily store an entry in the key tracking log during a memory access operation to the particular portion of memory, the entry comprising an identifier of the portion of memory and corresponding key identification data for the particular portion of memory, The identifier of the portion of the memory comprises at least one of a physical memory address or a memory page.

14. The method according to claim 13, wherein The MKE engine performs: In response to a read operation requesting a read of a first portion of memory corresponding to a first memory portion identifier, storing a first entry in the key tracking log representing the first memory portion identifier and a corresponding first key identifier; as well as In response to a subsequent write operation requiring a write to the first portion of the memory, the first entry is read from the key tracking log to retrieve the first key identifier, and a first cryptographic key corresponding to the first key identifier is applied to encrypt the data before writing the data to be written to the first portion of the memory.

15. The method according to claim 13, wherein A unique salt value is associated with each workload and stored in a data store managed by the processor core, and wherein a copy of each unique salt value associated with each workload is stored in a data store managed by the MKE engine, and wherein each unique salt value is associated with a respective portion of an allocation of memory corresponding to each respective workload; and In which, in response to a read operation performed by a first workload to retrieve a first set of data from the memory, the MKE engine combines the first set of data with an associated first salt value from a data repository managed by the MKE to generate a first salted value, and then passes the first salted data to at least one processor on which the first workload is executed.

16. The method according to claim 15, wherein In response to receiving first salted data in response to a read operation, the at least one processor core combines the first salted data with an associated salt value from a data repository managed by the processor core to recover the first set of data.

17. A machine-readable medium comprising instructions that, when executed by a computing platform, cause the computing platform to: executing, by at least one processor core of the computing platform, a plurality of workloads, each workload utilizing a respective portion of the allocation of memory; as well as performing, by a multi-key encryption MKE engine, key-based encryption including operations on data to be read from or written to the portion of the memory to isolate a specific portion of the portion of the memory from a workload not allocated the specific portion of the memory; maintaining, by the MKE engine, a key mapping data repository containing associations between identifiers of portions of the memory and corresponding key identification data, cryptographic keys determined based on the corresponding key identification data for use by the MKE engine in performing cryptographic isolation; as well as maintaining a key tracking log by the MKE engine, wherein the MKE engine is to temporarily store an entry in the key tracking log during a memory access operation to the particular portion of memory, the entry comprising an identifier of the portion of memory and corresponding key identification data for the particular portion of memory, The identifier of the portion of the memory comprises at least one of a physical memory address or a memory page.

18. A machine-readable medium according to claim 17, wherein: The instructions cause the MKE engine of the computing platform to: In response to a read operation requesting a read of a first portion of memory corresponding to a first memory portion identifier, storing a first entry in the key tracking log representing the first memory portion identifier and a corresponding first key identifier; as well as In response to a subsequent write operation requiring a write to the first portion of the memory, the first entry is read from the key tracking log to retrieve the first key identifier, and a first cryptographic key corresponding to the first key identifier is applied to encrypt the data to be written to the first portion of the memory before writing the data.

19. A machine-readable medium according to claim 17, wherein: The key mapping data repository is contained in the memory.

20. A machine-readable medium according to any one of claims 17 to 19, wherein: The instructions cause the MKE engine to: A key lookup data store is maintained containing a set of cryptographic keys, each of the cryptographic keys being associated with a key identifier of key identification data contained in the key mapping data store.

21. A machine-readable medium according to claim 20, wherein: The key lookup data store is contained in the memory, and wherein each of the cryptographic keys in the key lookup data store is encrypted such that only the MKE engine can recover the cryptographic key.

22. A machine-readable medium according to any one of claims 17 to 19, wherein: According to the instructions, the MKE engine receives and processes commands from the at least one processor core to remove entries from the key tracking log.

23. A machine-readable medium according to any one of claims 17 to 19, wherein: In accordance with the instructions, the MKE engine stores a copy of a last level cache (LLC) of the at least one processor core.

24. A machine-readable medium according to any one of claims 17 to 19, wherein: The instructions cause the computing platform to: associate a unique salt value with each workload and store it in a data store managed by a processor core, wherein a copy of each unique salt value associated with each workload is stored in a data store managed by an MKE engine, and wherein each unique salt value is associated with a respective portion of an allocation of memory corresponding to each respective workload; and In response to a read operation performed by a first workload to retrieve a first set of data from the memory, the MKE engine is configured to combine the first set of data with an associated first salt value from a data repository managed by the MKE to generate a first salted value, and then pass the first salted data to at least one processor on which the first workload is executed.

25. A machine-readable medium according to claim 24, wherein: The instructions cause at least one processor core of the computing platform to, in response to receiving first salted data in response to a read operation, combine the first salted data with an associated salt value from a data repository managed by the processor core to recover the first set of data.

Images