Technology for memory replay prevention using compression encryption

Abstract

Techniques for memory replay prevention using compressed encryption are disclosed. Systems and methods for memory isolation are provided. The method includes: receiving a request to write a row of data to a physical memory address, wherein the physical memory address includes a key identifier; selecting an encryption key from a key table based on the key identifier of the physical memory address; determining whether the row of data is compressible; in response to determining that the row of data is compressible, compressing the row of data to generate a compressed row, wherein the compressed row includes compression metadata and compressed data; adding encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key; in response to adding the encryption metadata, encrypting a portion of the compressed row using the encryption key to generate an encrypted row; and writing the encrypted row to a memory device at the physical memory address. Other embodiments are described and claimed.

Description

Background Art

[0001] Multiple virtual machines can operate in a shared environment within a public cloud system. In such a shared environment, data updated by one or more virtual machines (VMs) (e.g., in the form of virtual memory) should be protected from unprivileged external users. In addition, such memory should be protected from internal or privileged users. A common technique for protecting one VM from another VM in the same environment is to apply VM isolation techniques by cryptographically isolating the VMs from each other and from any host virtual machine manager (VMM). Memory encryption techniques that encrypt the memory of all VMs can be extended to provide encryption keys for access to memory by the VMs. Despite memory encryption, if a privileged entity (e.g., a VMM or another VM in the cloud environment) has access to the encrypted memory, the privileged entity can modify and replay the VM's memory. Certain additional techniques can use additional data variables (e.g., version numbers or integrity values) stored in a separate location such as a table, where the data variables are checked to authenticate the VM attempting to read the memory, thereby controlling access to the memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] In the accompanying drawings, the concepts described herein are illustrated by way of example and not by way of limitation. For simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. Where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding or similar elements.

[0003] Figure 1 is a simplified block diagram of at least one embodiment of a computing device for memory replay prevention using compressed encryption;

[0004] Figure 2 It can be done by Figure 1 A simplified block diagram of at least one embodiment of an environment established by a computing device;

[0005] Figure 3A and Figure 3B is a simplified flow chart of at least one embodiment of a method for memory replay prevention using compressed encryption, which may be performed by Figure 1 and Figure 2 The computing device executes to write a row of data to the memory;

[0006] Figure 4 The diagram can be Figure 1 and Figure 2 Schematic diagram of various memory states generated by a computing device;

[0007] Figure 5A and Figure 5Bis a simplified flow chart of at least one embodiment of a method for memory replay prevention using compressed encryption, which may be performed by Figure 1 and Figure 2 The computing device executes to read a row of data from the memory;

[0008] Figure 6A and Figure 6B is a simplified flow chart of at least one embodiment of a method for memory replay prevention using compressed encryption, which may be performed by Figure 1 and Figure 2 The computing device executes to write a row of data to the memory;

[0009] Figure 7 The diagram can be Figure 1 and Figure 2 A schematic diagram of various memory states generated by a computing device; and

[0010] Figure 8A and Figure 8B is a simplified flow chart of at least one embodiment of a method for memory replay prevention using compressed encryption, which may be performed by Figure 1 and Figure 2 The computing device executes to read the data line from the memory. DETAILED DESCRIPTION

[0011] While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments of the present disclosure have been shown by way of example in the drawings and will be described in detail herein. However, it should be understood that there is no intention to limit the concepts of the present disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

[0012] References in the specification to "one embodiment," "an embodiment," "an exemplary embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may or may not include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described. Additionally, it should be understood that terms included in a list in the form of "at least one of A, B, and C" may mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of "at least one of A, B, or C" may mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).

[0013] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transient or non-transient machine-readable (e.g., computer-readable) storage medium that can be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure (e.g., volatile or non-volatile memory, media disk, or other media device) for storing or transmitting information in a form that can be read by a machine.

[0014] In the accompanying drawings, some structural or method features may be shown in a particular arrangement and / or order. However, it should be understood that such a particular arrangement and / or order may not be required. Rather, in some embodiments, such features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of a structural or method feature in a particular drawing is not meant to imply that such feature is required in all embodiments, and in some embodiments, such feature may not be included, or such feature may be combined with other features.

[0015] Now refer to Figure 1 In the illustrative embodiment, the illustrative computing device 100 includes a central processing unit (CPU) 120, a main memory 140, an input / output (I / O) subsystem 142, and communication circuitry 146. Of course, in other embodiments, the computing device 100 may include other or additional components, such as those commonly found in computers (e.g., data storage, a display, etc.). Furthermore, in some embodiments, one or more of the illustrative components may be incorporated into another component or may otherwise form part of another component. For example, in some embodiments, the main memory 140 or a portion thereof may be incorporated into the CPU 120. In use, as further described below, the computing device 100 is configured to perform various methods of compression, encryption, replay prevention, and access control. In embodiments of the present disclosure, when a virtual machine stores data in a memory resource shared by multiple virtual machines, the computing device 100 may, in addition to encrypting the data, compress the data to prevent access and replay by another virtual machine that has access to the encrypted data / memory. In addition, the computing device 100 can also manipulate the data (e.g., insert encryption metadata, insert compression metadata, insert compression indicators, and / or insert conflict indicators) to prevent memory access or replay by another virtual machine. Thus, the computing device 100 can provide robust memory isolation beyond that of encryption-only techniques. In addition, the computing device 100 provides a memory access control and replay prevention scheme that does not incur additional performance overhead compared to encryption-only techniques.

[0016] The CPU 120 may be embodied as any type of processor capable of performing the functions described herein. For example, the CPU 120 may be embodied as a (multiple) single-core or multi-core processor, a microcontroller, or other processor or processing / control circuitry. The CPU 120 may include multiple levels of cache between the memory encryption engine and the processor, data and / or instruction caches, shared caches, and / or processor-exclusive caches. In some embodiments, the CPU 120 may be embodied as, include, or be coupled to a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a graphics processing unit (GPU), reconfigurable hardware or hardware circuitry, or other specialized hardware to facilitate the execution of the functions described herein. In an illustrative embodiment, the CPU 120 is embodied as a processor comprising a plurality of cores 124, 126, 128, 130, 132, 134, 136, and 138. Although in Figure 1 100. In some embodiments, the main memory 140 may include eight cores, but it should be understood that in other embodiments, the CPU 120 may include a different number of cores. Similarly, the main memory 140 may be embodied as any type of volatile (e.g., dynamic random access memory (DRAM), etc.) or non-volatile memory or data storage (e.g., NVRAM) capable of performing the functions described herein. In some embodiments, all or a portion of the main memory 140 may be integrated into the CPU 120. In operation, the main memory 140 may store various data and software used during operation of the computing device 100, such as packet data, operating systems, applications, programs, libraries, and drivers.

[0017] In addition, the CPU 120 also includes a compression / encryption support block 122. The compression / encryption support block 122 may be embodied as any functional block, digital logic, microcode, or other component capable of performing memory protection techniques using compression encryption as described herein. More specifically, the compression / encryption support block 122 may be embodied as a block capable of performing a reference Figures 3A-8B Any component of the memory replay prevention scheme described.

[0018] The I / O subsystem 142 may be embodied as circuitry and / or components for facilitating input / output operations with the CPU 120, main memory 140, and other components of the computing device 100. In some embodiments, the main memory 140 may be connected to the CPU 120 via a bus separate from the bus used for the I / O subsystem 142. For example, the I / O subsystem 142 may be embodied as or otherwise include a memory controller hub, an input / output control hub, an integrated sensor hub, a firmware device, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and / or other components and subsystems for facilitating input / output operations. In some embodiments, the I / O subsystem 142 may form part of a system on a chip (SoC) and may be incorporated on a single integrated circuit chip along with one or more of the CPU 120, main memory 140, and other components of the computing device 100.

[0019] The communication circuit 146 may be embodied as any communication circuit, device, or collection thereof that enables communication between the computing device 100 and other remote devices. The communication circuit 146 may be configured to use any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., Ethernet, WiMAX, etc.) to implement such communications. The illustrative communication circuitry 146 includes a network interface controller (NIC) 148 to connect to other computing devices or to another computing device 100. The network interface controller (NIC) 148 can be embodied as one or more plug-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that can be used by the computing device 100. In some embodiments, the NIC 148 can be embodied as part of a system on a chip (SoC) that includes one or more processors, or the NIC 148 can be included on a multi-chip package that also includes one or more processors. In some embodiments, the NIC 148 can include a local processor (not shown) and / or local memory (not shown) both located locally on the NIC 148. In such embodiments, the local processor of the NIC 148 may be capable of performing one or more of the functions of the CPU 120 described herein. Additionally or alternatively, in such embodiments, the local memory of the NIC 148 can be integrated into one or more components of the computing device 100 at the board level, socket level, chip level, and / or other levels.

[0020] The computing device 100 may additionally include a data storage device 150, which may be embodied as one or more devices of any type for short-term or long-term storage of data, such as, for example, memory devices and circuits, memory cards, hard drives, solid-state drives, or other data storage devices. In alternative embodiments, the systems and methods described herein may also be applied to the data storage device 150. The data storage device 150 may include a system partition that stores data and firmware code for the computing device 100. The data storage device 150 may also include an operating system partition that stores data files and executable programs for the operating system of the computing device 100.

[0021] In addition, the computing device 100 may include a display 152. The display 152 may be embodied as or otherwise use any suitable display technology, including, for example, a liquid crystal display (LCD), a light emitting diode (LED) display, a cathode ray tube (CRT) display, a plasma display, and / or other displays that may be used in computing devices. The display may include a touch screen sensor that uses any suitable touch screen input technology to detect a user's tactile selection of information displayed on the display, including but not limited to a resistive touch screen sensor, a capacitive touch screen sensor, a surface acoustic wave (SAW) touch screen sensor, an infrared touch screen sensor, an optical imaging touch screen sensor, an acoustic touch screen sensor, and / or other types of touch screen sensors. Additionally or alternatively, the computing device 100 may include one or more peripheral devices 154. Such peripheral devices 154 may include any type of peripheral device commonly found in computing devices, such as a speaker, a mouse, a keyboard, and / or other input / output devices, interface devices, and / or other peripheral devices.

[0022] Now see Figure 2In the illustrative embodiment, the computing device 100 establishes an environment 200 during operation. The illustrative environment 200 includes a memory manager 202, a key manager 204, a compression manager 206, an encryption manager 208, and a conflict manager 210. The components of the environment 200 may be embodied as hardware, firmware, software, or a combination thereof. Thus, in some embodiments, one or more of the components of the environment 200 may be embodied as circuitry or a collection of circuitry of an electronic device (e.g., memory manager circuitry 202, key manager circuitry 204, compression manager circuitry 206, encryption manager circuitry 208, and / or conflict manager circuitry 210). It should be understood that in such embodiments, one or more of the memory manager circuitry 202, key manager circuitry 204, compression manager circuitry 206, encryption manager circuitry 208, and / or conflict manager circuitry 210 may form part of the processor 120, I / O subsystem 142, main memory 140, or data storage device 150 of the computing device 100. Additionally, in some embodiments, one or more of the illustrative components may form part of another component, and / or one or more of the illustrative components may be independent of each other.

[0023] The memory manager 202 is configured to receive a request to write a row of data to a physical memory address. The physical memory address includes a key identifier selected by a processor or hardware (e.g., associated with a virtual machine) that generates the request to write the row of data. The memory manager 202 is further configured to write an encrypted row generated from the row of data to the memory 140 at the physical memory address. The memory manager 202 is also configured to receive a request to read the encrypted row from the physical memory address of the computing device. The memory manager 202 is further configured to forward the row of data generated from the encrypted row to the processor 120.

[0024] The key manager 204 is configured to select an appropriate encryption key from the key table 212 based on the key identifier of the physical memory address. The same encryption key can be used for both encryption and decryption operations. In some embodiments, the key manager 204 can be configured to select a decryption key from the key table 212 based on the beginning of the encrypted row in response to determining that the beginning of the encrypted row does not match a conflict indicator, as described below.

[0025] The compression manager 206 is configured to determine, in response to a write request, whether a data row is compressible, and if so, compress the data row to generate a compressed row. The compressed row contains compression metadata and compressed data. In some embodiments, the compression manager 206 may be further configured to add a compression indicator to the compressed row. The compression indicator includes a predetermined bit pattern. In those embodiments, the compression manager 206 may be configured to determine, in response to a read request, whether the beginning of an encrypted row matches the compression indicator. In those embodiments, the compression manager 206 is further configured to decompress the compressed data to generate the data row in response to determining that the encryption metadata of the compressed row is verified. Additionally or alternatively, in some embodiments, the compression manager 206 may be configured to decompress the compressed data to generate the data row in response to determining that the integrity metadata of the compressed row is verified against the compressed data.

[0026] The encryption manager 208 is configured to add encryption metadata to a compressed row in response to a write request. The encryption metadata indicates an encryption key. The encryption manager 208 is further configured to encrypt a portion of the compressed row using the encryption key in response to the addition of the encryption metadata to generate an encrypted row. In some embodiments, the encryption manager 208 may be further configured to decrypt the portion of the encrypted row using the decryption key in response to a read request to generate a compressed row in response to determining that the beginning of the encrypted row matches a compression indicator. The compressed row may include compression metadata, encryption metadata, and compressed data. The encryption manager 208 may be further configured to determine whether the encryption metadata is verified against the decryption key. The encryption manager 208 may be further configured to generate a verification error in response to determining that the encryption metadata is not verified.

[0027] Additionally or alternatively, in some embodiments, encryption manager 208 may be further configured to add integrity metadata to the compressed row. In those embodiments, the integrity metadata may include an integrity check value based on the compressed data, and the encryption metadata may include a key identifier. The integrity check value may also be calculated based on other data, such as the compressed data and compression metadata and / or the uncompressed data row. In those embodiments, the compression metadata, integrity metadata, and compressed data may be encrypted. Encryption manager 208 may be further configured to, in response to a read request, decrypt a portion of the encrypted row using a decryption key to generate a compressed row. The compressed row contains the compression metadata, integrity metadata, and compressed data. Encryption manager 208 may also be configured to determine whether the integrity metadata is verified against the compressed data. Encryption manager 208 may also be configured to: if the integrity metadata is verified against the compressed data, determine whether the start of the encrypted row matches the key identifier of the physical memory address; and generate a verification error if the start of the encrypted row does not match the key identifier of the physical memory address.

[0028] The conflict manager 210 can be configured to encrypt a row of data with an encryption key in response to a write request to generate an encrypted row when the row of data is incompressible, and to determine whether the beginning of the encrypted row matches a compression indicator or a conflict indicator. The conflict indicator can include a predetermined bit pattern that is different from the compression indicator. The conflict manager 210 can also be configured to update an entry of the conflict table 214 corresponding to the physical memory address based on the beginning of the encrypted row if the beginning of the encrypted row matches the compression indicator or the conflict indicator. The conflict table 214 can also be stored at the main memory 140. The conflict manager 210 can be configured to replace the beginning of the encrypted row with the conflict indicator if the beginning of the encrypted row matches the compression indicator or the conflict indicator. In response to a read request, the conflict manager 210 may be configured to: if the start of the encrypted row does not match the compression indicator, determine whether the start of the encrypted row matches the conflict indicator; and if the start of the encrypted row matches the conflict indicator, replace the start of the encrypted row with the compression indicator based on a value from the conflict table corresponding to the physical memory address of the encrypted row. The conflict manager 210 may be further configured to decrypt the entire encrypted row using a decryption key to generate a data row.

[0029] Additionally or alternatively, in some embodiments, conflict manager 210 can be configured to: encrypt a data row using an encryption key in response to a write request to generate an encrypted row when the data row is incompressible; select a test encryption key from key table 212 based on the start of the encrypted row; and decrypt the remainder of the encrypted row using the test encryption key to generate a test compressed row. The test compressed row includes test compression metadata, test integrity metadata, and test compression data. Conflict manager 210 can be further configured to: determine whether the test integrity metadata is valid based on the test compression data; if the test integrity metadata is valid, update an entry of conflict table 214 corresponding to the physical memory address with the start of the encrypted row; and if the test integrity metadata is valid, replace the start of the encrypted row with a conflict indicator.

[0030] In some embodiments, the conflict manager 210 can be configured to: in response to a read request, determine whether the beginning of the encrypted row matches the conflict indicator; if the beginning of the encrypted row matches the conflict indicator, replace the beginning of the encrypted row with a value from the conflict table 214 corresponding to the physical memory address of the encrypted row; if the integrity metadata is not verified against the compressed data, select a decryption key from the key table 212 based on a key identifier of the physical memory address; and decrypt the entire encrypted row with the decryption key to generate a data row.

[0031] See also Figure 3A In use, the computing device 100 may perform the method 300 for writing a row of data using compression encryption replay prevention. In an illustrative embodiment, Figure 3A and Figure 3B A method for embedding a compression indicator in a compressed and encrypted data row is described. Method 300 begins at block 302, where computing device 100 monitors for any requests to write a data row to memory. For example, a write request may be generated by a core of processor 120 in response to executing a store instruction and / or by a cache subsystem of processor 120. In the illustrative embodiment, method 300 proceeds to block 304, where computing device 100 determines whether a write request has been detected. If not, method 300 loops back to block 302 to continue monitoring for write requests. If a write request is detected, method 300 proceeds to block 306.

[0032] In block 306, the computing device 100 selects an encryption key from the key table. In one embodiment, the encryption key is selected based on a key identifier included in the memory address supplied with the write request. In another embodiment, the key identifier may be defined using additional metadata accessible from the cache. The memory address identifies the memory location to which the data row is requested to be written. The key identifier may be embodied as one or more bits of the memory address that are reserved or otherwise not used to identify the memory location. For example, in some embodiments, the memory address may be embodied as a 64-bit value, but only the lower 48 bits may be used to identify the memory location. In that embodiment, a portion of the upper 16 bits (e.g., three bits) may be used as the key identifier. The key identifier may be used to index the key table in memory to select the encryption key. In the illustrative embodiment, the key table is also encrypted using a key table encryption key that is referenced only by the central processing unit 120. Therefore, when a key from the key table is to be accessed, the key table is decrypted using a key table decryption key. Additionally or alternatively, the key table may be stored on-die, on the package, or otherwise so that the encryption key is not exposed to software. The key identifier (also known as a color bit, tag bit, or protection key) may be configured by privileged software of the computing device 100 and may therefore be used to partition memory within a non-privileged process such as a virtual machine or application. In an alternative embodiment, the computing device 100 may set the key identifier in a memory address while a virtual machine possessing the associated encryption key is operating.

[0033] Method 300 proceeds to block 308, in which computing device 100 determines whether the data row is compressible. Computing device 100 may use any compression algorithm or other technique to determine whether the data row is compressible. For example, computing device 100 may determine whether the data row includes any repeated words (e.g., 16-bit values) or other repeated data. In block 310, computing device 100 checks whether the data row is compressible. If not, method 300 branches to block 330 shown in FIG. 3 and described below. If the data row is compressible, method 300 proceeds to block 312, in which computing device 100 compresses the data row to generate a compressed row. In an illustrative embodiment, the data row may be compressed using any commonly available lossless compression algorithm. In some embodiments, in block 314, as part of the compression process, computing device 100 generates a compressed row and also generates compression metadata. In one embodiment, the compressed metadata may include a 5-bit value indicating the position of the first repeated 16-bit word and a 4-bit value indicating the distance from the first repeated word to the second repeated word, wherein the distance may wrap to the beginning of the data row. In that embodiment, by removing the repeated words, the compressed data may be 16 bits shorter than the original uncompressed data row. In a related embodiment, computing device 100 may be configured to identify additional repeated words to free up additional space for additional metadata. For example, an additional 4-bit value may identify the position of the third repeated word, and a 3-bit value may identify the distance to the fourth repeated word, and so on.

[0034] The method 300 proceeds to block 316, where the computing device 100 adds a compression indicator and encryption metadata to the compressed row. The compression indicator may be specified as a predetermined binary value, such as a four-bit binary value corresponding to the hexadecimal value 'xC'. In some embodiments, in block 318, the encryption metadata includes a key identifier. For example, a three-bit key identifier value from a memory address may be added to the compressed row. In some embodiments, in block 320, the encryption metadata includes an integrity check value based on the encryption key. For example, the integrity check value may be generated as a hash, a secure hash function (e.g., SHA3), or as part of a hash of the data. The compressed row including the compression indicator, encryption metadata, compression metadata, and compressed data has the same length as the original uncompressed row of data (e.g., 512 bits).

[0035] The method proceeds to block 322, where computing device 100 encrypts a portion of the compressed row using an encryption key (e.g., using a technique such as ciphertext stealing) to generate an encrypted row. Computing device 100 may leave the portion of the compressed row, including the metadata, in plain text. More specifically, at block 324, in some embodiments, computing device 100 may encrypt the compressed metadata and compressed data of the compressed row. In those embodiments, computing device 100 may leave the compression indicator and encryption metadata (e.g., a key identifier or integrity check value) in plain text. Additionally or alternatively, at block 326, computing device 100 may also encrypt the encryption metadata. In those embodiments, the compression indicator may remain in plain text. Note that when compression is combined with encryption, compression is performed before encryption when data is being written to memory, and decompression is performed after decryption when data is being read from memory. This is because encryption produces a pseudo-random sequence of ciphertext bits that is less likely to be compressed after encryption.

[0036] In some embodiments, ciphertext stealing techniques can be used to gain additional security. For example, a block cipher (e.g., a cipher such as AES in ECB or XTS mode operating with a 128-bit block size) can overlap the last encrypted block with the ciphertext of the first encrypted block (e.g., a block containing compression metadata after it was encrypted as part of the first encrypted block), doubly encrypting a portion of the first encrypted block as part of the last encrypted block to accommodate the unencrypted compression indicator value and / or encryption metadata (e.g., a key identifier). Then, during a memory read operation, the encrypted compressed block is decrypted by decrypting the last encrypted block that overlaps with a portion of the first encrypted block; then decrypting the third encrypted block, the second encrypted block, and finally decrypting the first encrypted block that includes the decrypted overlapping portion of the first block (decrypting the four 128-bit blocks in reverse order). This technique also prevents replay of data because using the wrong encryption key to decrypt compressed data will result in data corruption in a memory read attempt, which will then produce incompressible data in a subsequent memory write operation, thereby destroying the original data in memory and preventing it from being replayed when the original (correct) encryption key is used to read it again. The encryption metadata (e.g., the key identifier) can also indicate that the wrong physical address bits were used to access a compressed row because its key identifier does not match the physical address bits. Therefore, verifying that the key identifier in the memory read address and the key identifier in the encryption metadata are the same value provides an access control mechanism that prevents the erroneous entity (e.g., a VM or application) from reading memory that does not belong to it. The error can then be indicated to the processor 120, the security subsystem, and / or the software.

[0037] After encrypting the row of data, method 300 proceeds to block 328 where computing device 100 writes the encrypted row to the destination memory address specified by the write request. After writing the encrypted row to memory, method 300 loops back to block 302 to continue monitoring for write requests.

[0038] Referring back to block 310, if the data row is not compressible, the method 300 branches to block 330 as shown in FIG. Figure 3B Now refer to Figure 3B , in box 330, the computing device 100 encrypts the entire data row (which is not compressed) with the encryption key to generate an encrypted row. At box 332, the computing device 100 determines whether the beginning of the encrypted row is equal to the compression indicator or the collision indicator. As described above, the compression indicator can be embodied as a predetermined binary value, such as, a value corresponding to four bits of hexadecimal "xC". Similarly, the collision indicator can be embodied as a different predetermined binary value, such as, a value corresponding to four bits of hexadecimal "xD". Therefore, in an illustrative embodiment, the computing device 100 can determine whether the first four bits of the encrypted row are equal to "xC" or "xD". In box 334, the computing device 100 checks whether the beginning of the encrypted row matches the compression indicator or the collision indicator. If not, the method 300 branches to Figure 3A , to write the encrypted row to memory. If the beginning of the encrypted row matches the compression indicator or the conflict indicator, the method 300 proceeds to block 336.

[0039] In box 336, the computing device 100 replaces the start of the encrypted row with a conflict indicator (e.g., "xD"). Of course, if the encrypted row already starts with a conflict indicator, the computing device 100 may not change the encrypted row. In box 338, the computing device 100 updates the conflict table 208 to indicate the original value of the start of the encrypted row (e.g., "xC" or "xD"). The conflict table 208 may include a table entry for each possible memory address corresponding to the data row (similar to a memory page table). Each conflict table 208 entry may include a Boolean value or other value that indicates whether the encrypted row originally started with "xC" or "xD". As described below in conjunction with Figure 5A and Figure 5B As further described, the conflict table 208 entries can be used to decrypt the encrypted row when reading. After updating the conflict table, the method 300 branches to Figure 3A328 to write the encrypted row to memory. Some embodiments may reduce the compression indicator to just one bit (e.g., 1b indicates compressed and 0b indicates uncompressed), in which case the conflict table 208 will always be queried in the 0b (uncompressible) condition to determine the value of the original bit. In such embodiments, the conflict table 208 may also include metadata such as a key identifier and / or an integrity check value, thereby allowing access control to uncompressible rows by verifying that the key identifier in the address matches the key identifier or integrity check value assigned to the row in the conflict table 208, otherwise reporting an error.

[0040] refer to Figure 4 , block diagram 400 illustrates various memory states generated as a result of a replay prevention scheme as disclosed herein. Memory address 402 shows a physical address 410 adjacent to a key identifier 404. The key identifier 404 may also be referred to as a color, a memory tag, or a protection key. The physical address 410 identifies the memory location where a row of data is read or written. As shown, the physical address 410 includes an identifier (e.g., a pointer) to a conflict row 406 and a conflict bit 408. The conflict row 406 and the conflict bit 408 may be used to index into the conflict table 208, as described above in conjunction with Figure 3B as described in box 338 of .

[0041] Memory block 412 shows a 512-bit row of data. In the illustrative embodiment, the encryption and compression process described herein is applied to a 512-bit memory block, such as memory block 412. Memory block 414 shows a compressed row including a compression indicator 416 (equal to "xC"), a key identifier 404, compression metadata 418, and compressed data 420. Any publicly available compression algorithm can be used to compress the row of data to generate compressed data 420. Compression metadata used or required by the algorithm is stored as compression metadata 418.

[0042] Memory block 422a illustrates one potential embodiment of memory block 414 after encryption. In the illustrative embodiment, only a portion of memory block 414 is encrypted. For example, as shown in memory block 422a, only compression metadata 418 and compressed data 420 are encrypted to generate encrypted data 424a. Key identifier 404 remains unencrypted. Similarly, compression indicator 416 is also unencrypted.

[0043] Memory block 422b illustrates another potential embodiment of memory block 414 after encryption. Memory block 422b now includes encrypted data 424b and compression indicator 416. In the embodiment illustrated here, the entirety of memory block 141 is encrypted except for compression indicator 416 (i.e., key identifier 404, compression metadata 418, and compressed data 420 are encrypted).

[0044] Memory block 426 shows the incompressible memory block 412 after encryption. Memory block 426 includes encrypted data 428, which is generated by encrypting the entire memory block 412. As shown, encrypted data 428 includes a beginning portion 430, which is illustratively four bits. Beginning portion 430 of memory block 426 can be any value that is not equal to the compression indicator or the conflict indicator (e.g., not equal to "xC" or "xD"). Similarly, memory block 432 shows the incompressible memory block 412 after encryption. Memory block 432 also includes encrypted data 428, which is generated by encrypting the entire memory block 412. However, the beginning 434 of the encrypted row 432 is equal to the compression indicator or the conflict indicator and is therefore replaced by the conflict indicator "xD". Therefore, the illustrative memory block 432 only includes the last 508 bits of encrypted data 428. As described above, the original beginning of the encrypted row 432 is stored or otherwise indicated in the conflict table 208.

[0045] See also Figure 5A In use, the computing device 100 may perform a method 500 for reading a row of data that has been protected from writes using compression replay. The method 500 begins at block 502, where the computing device 100 monitors for read requests. For example, a read request may be generated by a core of the processor 120 in response to executing a load instruction and / or by a cache subsystem of the processor 120. The read request identifies a physical address of the row of data, which is also referred to herein as a source physical address. In block 504, the computing device 100 determines whether a read has been requested. If not, the method 500 loops back to block 502 to continue monitoring for reads. If a read has been requested, the method 500 proceeds to block 506.

[0046] In block 506, computing device 100 selects an encryption key from a key table using the key identifier retrieved from the requested memory address. As described above, the key identifier can be embodied as one or more bits of a memory address that are reserved or not otherwise used to identify a storage location. The key identifier (e.g., a three-bit value) can be used to index the key table in memory to select an encryption key.

[0047] The method 500 proceeds to block 508, where the computing device 100 retrieves the encrypted row from the memory 140 at the requested memory address. The computing device 100 determines whether the beginning of the encrypted row matches the compression indicator. As described above, the compression indicator may be embodied as a predetermined binary value, such as a four-bit binary value corresponding to the hexadecimal value "xC". In block 510, the computing device 100 checks whether the beginning of the encrypted row matches the compression indicator. If not, the method 500 branches to Figure 5B If there is a match between the start of the encrypted row and the compression indicator, the method 500 proceeds to block 512.

[0048] In block 512, computing device 100 decrypts the encrypted row using the encryption key to generate a compressed row. Computing device 100 may not decrypt the portion of the encrypted row that is in plain text. More specifically, in some embodiments, computing device 100 may decrypt the compressed data and compression metadata generated as part of the compression process at block 514. In those embodiments, the encryption metadata may have been included as plain text in the encrypted row. In some embodiments, computing device 100 may also decrypt the encryption metadata at block 516.

[0049] After decryption, the method 500 proceeds to box 518, where the computing device 100 verifies the encryption metadata associated with the compressed row. More specifically, the computing device 100 verifies that the key identifier or integrity check value stored with the compressed row matches the encryption key selected using the key identifier of the memory address. When writing, the key identifier of the memory address used to write the data row is associated with the virtual machine or other protection domain in which the data is stored. Therefore, the stored key identifier or integrity check value is associated with the virtual machine or other protection domain requesting the write. In some embodiments, in box 522, the computing device 100 may compare the stored key identifier in the compressed row with the key identifier in the memory address, which key identifier corresponds to the key identifier of the virtual machine requesting to read the compressed row. In some embodiments, in box 524, the computing device 100 may compare the stored integrity check value of the compressed row with the integrity check value generated based on the uncompressed data row or the compressed row. As described above with respect to Figure 3A and Figure 3B The integrity check value may be a value generated using the encryption key rather than the key identifier itself. For example, the integrity check value may be a cyclic redundancy value or a hash of the encryption key calculated using a hash algorithm.

[0050] At block 524, the computing device 100 determines whether the encryption metadata was successfully verified. If the encryption metadata was not verified, the method 500 branches to block 530, where the computing device 100 generates a verification error, for example, by sending a poison bit, an error bit, an interrupt, or an error message to the central processing unit 120. More specifically, the compression / encryption support block can send a poison bit to the central processing unit 120 to indicate that the memory read attempt failed, which may be due to an unauthorized memory replay attempt. The central processing unit 120 can be configured to notify an operator, log the memory replay attempt, or take cautionary measures to identify the unauthorized virtual machine and prevent further attempts. After generating the error, the method 500 completes, for example, by aborting the memory read request.

[0051] Referring back to block 524, if the encryption metadata is successfully verified, method 500 proceeds to block 526, where computing device 100 decompresses the compressed row to recover the data row in uncompressed form. In a related embodiment, computing device 100 decompresses the compressed row to recover the data row and then verifies the integrity check value before continuing. Method 500 continues to block 528, where computing device 100 forwards the uncompressed data row to the cache and / or processor 120 (which in turn provides access to the virtual machine requesting the data row). After forwarding the data row, method 500 loops back to block 502 to continue monitoring for additional read requests.

[0052] Referring back to block 510, if there is no match between the start of the encrypted line and the compression indicator, the method 500 branches to Figure 5B As shown in box 532. Figure 3A and Figure 3B As mentioned above, if the encrypted row does not begin with a compression indicator, the data row was not compressed before being encrypted and stored. Figure 5B In block 532, computing device 100 determines whether the beginning of the encrypted row matches the collision indicator. As described above, the collision indicator can be embodied as a predetermined binary value different from the collision indicator, such as a four-digit value corresponding to hexadecimal "xD". In block 534, computing device 100 checks whether the beginning of the encrypted row matches the collision indicator. If not, method 500 jumps to block 540, described below. If a match is found in block 534, method 500 proceeds to block 536.

[0053] In block 536, the computing device 100 looks up the conflict bit in the conflict table 208 based on the memory address of the requested data row. For example, the computing device 100 may use a portion of the physical memory address to index the conflict row within the conflict table 208, and the remainder of the memory address to index the conflict bit within the conflict row. Based on the conflict bit, the computing device 100 replaces the beginning of the encrypted row with a compression indicator in block 538. For example, if the conflict bit is set, the computing device 100 may replace the beginning of the encrypted row with "xC", and if the conflict bit is not set, the computing device 100 may not change the beginning of the encrypted row. The method then proceeds to block 540, where the computing device 100 decrypts the entire encrypted row with the encryption key to generate the data row. After decryption, the method 500 branches to Figure 5A Block 528 is shown to forward the line of data to the cache.

[0054] See also Figure 6A In use, the computing device 100 may perform the method 600 for writing a row of data using compression replay prevention. In an illustrative embodiment, Figure 6A and 6B The method 600 illustrates the use of integrity metadata values generated from compressed rows rather than predetermined compression indicators. Method 600 begins at block 602, where computing device 100 monitors for any requests to write a row of data to memory. As described above, a write request may be generated, for example, by a core of processor 120 in response to executing a store instruction and / or by a cache subsystem of processor 120. In the illustrative embodiment, the method proceeds to block 604, where computing device 100 determines whether a write request has been detected. If not, method 600 loops back to block 602 to continue monitoring for write requests. If a write request has been detected, method 600 proceeds to block 606.

[0055] In block 606, computing device 100 selects an encryption key from the key table. More specifically, the encryption key is selected based on a key identifier included in a memory address along with the write request. The memory address identifies the memory location to which the data row is requested to be written. As described above, the key identifier may be embodied as one or more bits of the memory address that are reserved or not otherwise used to identify a storage location. The key identifier may be used to index the key table in memory to select the encryption key.

[0056] Method 600 proceeds to block 608, where computing device 100 determines whether the data row is compressible. As described above, computing device 100 may use any compression algorithm or other technique to determine whether the data row is compressible. For example, computing device 100 may determine whether the data row includes any repeated words (e.g., 16-bit values) or other repeated data. In block 610, computing device 100 checks whether the data row is compressible. If not, method 600 branches to Figure 6B 6 and described below. If the data row is compressible, the method 600 proceeds to block 612, where the computing device 100 compresses the data row to generate a compressed row. In an illustrative embodiment, any generally available lossless compression algorithm can be used to compress the data row. In some embodiments, in block 614, as part of the compression process, the computing device 100 generates the compressed row and also generates compression metadata. As described above, in one embodiment, the compression metadata can include a 5-bit value indicating the position of the first repeated 16-bit word and a 4-bit value indicating the distance from the first repeated word to the second repeated word, where the distance can wrap to the beginning of the data row.

[0057] Method 600 then proceeds to block 616, where computing device 100 adds a key identifier to the compressed row. As described above, the key identifier can be embodied as a three-bit value copied from the memory address. At block 618, computing device 100 also adds integrity metadata to the compressed row. The integrity metadata includes a value generated using the compressed row. In one embodiment, the integrity metadata can include an authentication value generated using a block authentication encryption cipher performed on each block of the compressed row. For example, computing device 100 can employ an AES / XTS block cipher with 128 bits per block and can spread the AES blocks across the row using a reduced round technique or other spreading technique to allow the integrity value to represent the entire cache line. Of course, in some embodiments, computing device 100 can use a wider block cipher, such as 3Fish. Additionally or alternatively, in some embodiments, the computing device can distribute the integrity value across the entire cache line so that a representative portion of the integrity value is present in each block. Similarly, the integrity value can be a hash (e.g., a SHA3 hash) of the contents of the entire plaintext data row.

[0058] Method 600 proceeds to block 620, where computing device 100 encrypts the partially compressed row with the encryption key to generate an encrypted row. More specifically, at block 622, computing device 100 encrypts the compression metadata, the compressed data, and the integrity metadata. Computing device 100 leaves the key identifier in plain text.

[0059] After generating the encrypted row, the method 600 proceeds to block 624 where the computing device 100 writes the encrypted row to the destination memory address specified by the write request. After writing the encrypted row to memory, the method 600 loops back to block 602 to continue monitoring for write requests.

[0060] Referring back to block 610, if the data row is not compressible, the method 600 branches to block 626, as shown in FIG. Figure 6B Now refer to Figure 6B At block 626, computing device 100 encrypts the entire data row (which is uncompressed) with the encryption key to generate an encrypted row. At block 628, computing device 100 selects a test encryption key using the beginning of the encrypted row as a test key identifier. For example, computing device 100 may treat the first three digits of the encrypted row as a test key identifier and associate a key table with the test key identifier to select a test encryption key. As described further below, the test encryption key is used to test for anomalies in which the first three digits of the encrypted row (which are substantially random) still select an encryption key that generates valid integrity metadata.

[0061] At box 630, computing device 100 uses the test key identifier to decrypt the remainder of the encrypted row to generate a test data row. For example, computing device 100 may decrypt all encrypted rows starting after the first three digits. At box 632, computing device 100 determines whether the integrity metadata for the test data row is valid. For example, computing device 100 may treat a particular field of the test data row as an authentication value and another field as compressed data and determine whether the test authentication value is valid for the test compressed data. Of course, these values are generated by decrypting the encrypted row with the wrong encryption key and are therefore essentially random; therefore, the test authentication value is only rarely valid. At box 634, computing device 100 checks whether the integrity metadata for the test data row is valid. If not, method 600 branches to Figure 6A 6. If the integrity metadata for the test data row is valid, the method 600 proceeds to block 636.

[0062] In block 636, computing device 100 sets the start of the encrypted row as a collision indicator. The collision indicator may be embodied as a predetermined binary value of the same length as the key identifier (e.g., three bits). The collision identifier may not be used as a valid key identifier value. Additionally, in block 638, computing device 100 updates collision table 208 to include the original start of the encrypted row (i.e., the start bits of the encrypted row used as the test key identifier). As described below in conjunction with Figure 8A and Figure 8BAs further described, the conflict table 208 can be used to decrypt the encrypted row when reading. After updating the conflict table, the method 600 branches to Figure 6A Block 624 is shown to write the encrypted row to memory.

[0063] Now refer to Figure 7 , block diagram 700 shows various memory states generated as a result of the replay prevention scheme as disclosed herein. Memory block 710 shows the memory states that may be used in conjunction with the above Figure 6A and Figure 6B As shown, the memory block 710 includes a key identifier 404 (similar to Figure 4 ), compressed metadata 418 (similar to Figure 4 ), integrity metadata 702, and compressed data 704. As described above, integrity metadata 702 can be used to verify compressed data 704. Memory block 720 shows a memory block that can be combined with the above. Figure 6A 6. As shown, memory block 720 includes encrypted data 708 and key identifier 404. As shown in memory block 720, key identifier 404 is not encrypted.

[0064] Memory block 730 shows a memory block that can be combined with Figure 6B As shown, memory block 730 includes encrypted data 712, and the entire 512-bit data row is encrypted. In contrast, memory block 740 includes encrypted data 712 with unencrypted collision indicator 714. The collision indicator 714 illustratively replaces the first three bits of encrypted data 712, and thus memory block 740 includes the last 509 bits of encrypted data 712. Memory block 740 may be combined with the encrypted data 712 as described above. Figure 6B is generated as described in block 636 of .

[0065] See also Figure 8A In use, the computing device 100 may perform a method 800 for reading a row of data that has been protected from writes using compression replay. The method 800 begins at block 802, where the computing device 100 monitors for read requests. As described above, a write request may be generated, for example, by a core of the processor 120 in response to executing a store instruction and / or by a cache subsystem of the processor 120. The read request identifies a physical address of the row of data, which is also referred to herein as a source physical address. In block 804, the computing device 100 determines whether a read has been requested. If not, the method 800 loops back to block 802 to continue monitoring for reads. If a read has been requested, the method 800 proceeds to block 806.

[0066] The method proceeds to block 806, where the computing device 100 determines whether the beginning of the encrypted row is a collision indicator. As described above, the collision indicator can be embodied as a predetermined binary value of the same length as the key identifier (e.g., three bits). In block 808, the computing device 100 checks whether the beginning of the encrypted row matches the collision identifier. If so, the method 800 branches to Figure 8B If the start of the encrypted row does not match the conflict indicator, the method 800 proceeds to block 810.

[0067] At block 810, the computing device 100 selects an encryption key from a key table using a key identifier stored within the encrypted row. As described above, the key identifier can be embodied as one or more bits of a memory address that are reserved or not otherwise used to identify a storage location. The key identifier (e.g., a three-bit value) can be used to index the key table in memory to select an encryption key.

[0068] The method 800 then proceeds to block 812, where the computing device 100 decrypts the partially encrypted row using the encryption key to generate a compressed row. More specifically, in block 814, the computing device 100 decrypts the compressed data, integrity metadata, and compression metadata generated as part of the compression process. The computing device 100 does not decrypt the key identifier (which is stored in plain text).

[0069] At block 816, computing device 100 determines whether the integrity metadata for the compressed row is valid. For example, computing device 100 may determine whether the integrity metadata is valid authentication data for the compressed data. For example, if the original data row is incompressible, the integrity metadata may be invalid, as described above in conjunction with Figure 6B In block 818, the computing device 100 checks whether the integrity metadata is valid. If not, the method 800 branches to Figure 8B If the integrity metadata is found to be valid at block 818 , the method 800 proceeds to block 820 .

[0070] In block 820, the computing device 100 determines whether the key identifier stored with the compressed row matches the key identifier of the memory address used to read the encrypted row. As described above, at write time, the key identifier of the virtual machine requesting to write the data row is stored with the compressed row, as described above with respect to Figure 6A and Figure 6B Therefore, the stored key identifier is associated with the virtual machine that requested the write. Because the key identifier of the read memory address is associated with the virtual machine that requested the read, the computing device 100 can compare the key identifiers to detect a replay attempt.

[0071] At block 822, computing device 100 checks whether the key identifier in the encrypted row matches the key identifier in the memory address. If the key identifiers do not match, method 800 branches to block 828, where computing device 100 generates a validation error, for example, by sending a poison bit, an error bit, or an error message to central processing unit 120. In this case, the key identifiers do not match, but the integrity metadata is valid, which means that the virtual machine may have attempted to replay the encrypted row generated by a different virtual machine or another protection domain. More specifically, the compression / encryption support block may send a poison bit to central processing unit 120 to indicate that the memory read attempt failed, possibly due to an unauthorized memory replay attempt. Central processing unit 120 may be configured to notify an operator, log the memory replay attempt, or take precautionary measures to identify the unauthorized virtual machine and prevent further attempts. After generating the validation error, method 800 completes, for example, by aborting the read request.

[0072] Referring back to block 822, if a match is found between the stored key identifier and the key identifier of the memory address, the method 800 proceeds to block 824, where the computing device 100 decompresses the compressed line to restore the data line in uncompressed form. The method 800 continues to block 826, where the computing device 100 forwards the uncompressed data line to the cache and / or processor 120 (which in turn provides access to the virtual machine requesting the data line). After forwarding the data line, the method 800 loops back to block 802 to continue monitoring for additional read requests.

[0073] Returning to block 808, if the beginning of the encrypted row is found to match the conflict indicator, the method 800 branches to block 830, as shown in FIG. Figure 8B Now refer to Figure 8B , in block 830, the computing device 100 replaces the beginning of the encrypted row with the corresponding value from the collision table 208. Figure 6B As described in blocks 636, 638 of FIG, the start of the encrypted row was previously stored in the collision table 208. For example, the computing device 100 may index the collision table 208 using the memory address of the encrypted row to retrieve the original start value.

[0074] After replacing the beginning of the encrypted row, the method 800 proceeds to block 832. Figure 8AAt block 818, if the integrity metadata of the compressed row is invalid, the method 800 further branches to block 832. In block 832, the computing device 100 selects an encryption key from the key table using the key identifier of the memory address of the requested data row (i.e., the key identifier provided by the virtual machine requesting the read). The method 800 then proceeds to block 834, where the computing device 100 decrypts the entire encrypted row with the encryption key to generate the data row. After decryption, the method 800 branches to Figure 8A Block 826 is shown to forward the line of data to the cache.

[0075] Example

[0076] The following provides illustrative examples of the technology disclosed herein. Implementations of these technologies may include any one or more of the examples described below, and any combination thereof.

[0077] Example 1 includes a computing device for memory isolation, the computing device comprising: a memory manager for receiving a request to write a data row to a physical memory address, wherein the physical memory address includes a key identifier; a key manager for selecting an encryption key from a key table based on the key identifier of the physical memory address; a compression manager for (i) determining whether the data row is compressible, and (ii) in response to determining that the data row is compressible, compressing the data row to generate a compressed row, wherein the compressed row includes compression metadata and compressed data; and an encryption manager for (i) adding encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key, and (ii) in response to adding the encryption metadata, encrypting a portion of the compressed row with the encryption key to generate an encrypted row; wherein the memory manager is also for writing the encrypted row to the memory device at the physical memory address.

[0078] Example 2 includes the subject matter of Example 1, and wherein selecting the encryption key from the key table comprises indexing the key table with the key identifier to retrieve the encryption key.

[0079] Example 3 includes the subject matter of any of Examples 1 and 2, and wherein the encryption metadata includes a key identifier.

[0080] Example 4 includes the subject matter of any of Examples 1-1, and wherein the encryption metadata comprises a hash of the encryption key.

[0081] Example 5 includes the subject matter of any of Examples 1-3, and wherein the compression manager further adds a compression indicator to the compressed row, wherein the compression indicator comprises a predetermined bit pattern.

[0082] Example 6 includes the subject matter of any of Examples 1-5, and wherein encrypting the portion of the compressed row comprises encrypting the compression metadata and the compressed data.

[0083] Example 7 includes the subject matter of any of Examples 1-6, and wherein encrypting the portion of the compressed row further comprises encrypting the encryption metadata.

[0084] Example 8 includes the subject matter of any of Examples 1-7, and also includes a conflict manager for: encrypting the data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; determining whether the beginning of the encrypted row matches a compression indicator or a conflict indicator in response to the encryption of the data row, wherein the conflict indicator includes a second predetermined bit pattern different from the compression indicator; in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator, updating an entry of a conflict table corresponding to a physical memory address based on the beginning of the encrypted row; and replacing the beginning of the encrypted row with the conflict indicator in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; wherein writing the encrypted row further comprises writing the encrypted row in response to the replacement of the beginning of the encrypted row.

[0085] Example 9 includes the subject matter of any of Examples 1-8, and wherein: the encryption manager further adds integrity metadata to the compressed row, wherein the integrity metadata includes an integrity check value based on the compressed data; the encryption metadata includes a key identifier; and encrypting the portion of the compressed row includes encrypting the compression metadata, the integrity metadata, and the compressed data.

[0086] Example 10 includes the subject matter of any of Examples 1-9, and also includes a conflict manager for: encrypting the data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; selecting a second encryption key from a key table based on a first portion of the encrypted row; decrypting a remaining portion of the encrypted row with the second encryption key to generate a test compressed row, wherein the test compressed row includes second compression metadata, second integrity metadata, and second compressed data; determining whether the second integrity metadata is valid based on the second compressed data; in response to determining that the second integrity metadata is valid, updating an entry in a conflict table corresponding to a physical memory address with the first portion of the encrypted row; and in response to determining that the second integrity metadata is valid, replacing the first portion of the encrypted row with a conflict indicator, wherein the conflict indicator includes a predetermined bit pattern; wherein writing the encrypted row further includes writing the encrypted row in response to the replacement of the first portion of the encrypted row.

[0087] Example 11 includes the subject matter of any of Examples 1-10, and wherein encrypting the portion of the compressed row comprises: encrypting a first block with a block cipher to generate a first encrypted block, wherein the first block begins at an offset in the compressed row; generating a last block, wherein the last block includes a last portion of the compressed row and a first portion of the first encrypted block; encrypting the last block with a block cipher to generate a last encrypted block, and replacing the first portion of the first encrypted block with the last portion of the last encrypted block.

[0088] Example 12 includes a computing device for memory isolation, the computing device comprising: a memory manager for receiving a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; a key manager for selecting a decryption key from a key table based on the key identifier of the physical memory address; a compression manager for determining whether the beginning of the encrypted row matches a compression indicator, wherein the compression indicator includes a predetermined bit pattern; and an encryption manager for (i) in response to determining that the beginning of the encrypted row matches the compression indicator, decrypting a portion of the encrypted row with a decryption key to generate a compressed row, wherein the compressed row includes compression metadata, encryption metadata, and compressed data, and (ii) determining whether the encryption metadata is verified against the decryption key; wherein the compression manager further decompresses the compressed data to generate a data row in response to determining that the encryption metadata is verified; and wherein the memory manager further forwards the data row to a processor.

[0089] Example 13 includes the subject matter of Example 12, and wherein selecting the encryption key from the key table comprises indexing the key table with the key identifier to retrieve the encryption key.

[0090] Example 14 includes the subject matter of any of Examples 12 and 13, and wherein the encryption metadata comprises a key identifier.

[0091] Example 15 includes the subject matter of any of Examples 12-14, and wherein the encryption metadata comprises a hash of the decryption key.

[0092] Example 16 includes the subject matter of any of Examples 12-15, and wherein the encryption manager is further for generating a validation error in response to determining that the encryption metadata is not validated.

[0093] Example 17 includes the subject matter of any of Examples 12-16, and further includes a conflict manager for: in response to determining that the start of the encrypted row does not match the compression indicator, determining whether the start of the encrypted row matches a conflict indicator, wherein the conflict indicator includes a predetermined bit pattern that is different from the compression indicator; and in response to determining that the start of the encrypted row does not match the conflict indicator, decrypting the entire encrypted row using a decryption key to generate a data row.

[0094] Example 18 includes the subject matter of any of Examples 12-17, and wherein the conflict manager is further for: in response to determining that the start of the encrypted row matches the conflict indicator, replacing the start of the encrypted row with the compression indicator based on a value from a conflict table corresponding to a physical memory address of the encrypted row; wherein decrypting the entire encrypted row further comprises decrypting the entire encrypted row in response to the replacement of the start of the encrypted row.

[0095] Example 19 includes a computing device for memory isolation, the computing device comprising: a memory manager for receiving a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; a conflict manager for determining whether the beginning of the encrypted row matches a conflict indicator, wherein the conflict indicator includes a predetermined bit pattern; a key manager for, in response to determining that the beginning of the encrypted row does not match the conflict indicator, selecting a decryption key from a key table based on the beginning of the encrypted row; an encryption manager for (i) decrypting a portion of the encrypted row with the decryption key to generate a compressed row, wherein the compressed row includes compression metadata, integrity metadata and compressed data, and (ii) determining whether the integrity metadata is verified for the compressed data; and a compression manager for, in response to determining that the integrity metadata is verified for the compressed data, decompressing the compressed data to generate a data row; wherein the memory manager also forwards the data row to the processor.

[0096] Example 20 includes the subject matter of Example 19, and wherein the encryption manager is further for: in response to determining that the integrity metadata is verified for the compressed data, determining whether the start of the encrypted row matches the key identifier of the physical memory address; and generating a verification error in response to determining that the start of the encrypted row does not match the key identifier of the physical memory address; wherein decompressing the compressed data further comprises decompressing the compressed data in response to determining that the start of the encrypted row matches the key identifier of the physical memory address.

[0097] Example 21 includes the subject matter of any of Examples 19 and 20, and wherein the conflict manager is further to: in response to determining that the integrity metadata is not verified for the compressed data, select a second decryption key from the key table based on the key identifier of the physical memory address; and in response to the selection of the second decryption key, decrypt the entire encrypted row using the second decryption key to generate the data row; wherein forwarding the data row further comprises forwarding the data row in response to decryption of the entire encrypted row.

[0098] Example 22 includes the subject matter of any of Examples 19-21, and wherein the conflict manager is further for: in response to determining that the beginning of the encrypted row matches the conflict indicator, replacing the beginning of the encrypted row with a value from a conflict table corresponding to the physical memory address of the encrypted row; wherein decrypting the entire encrypted row further comprises decrypting the entire encrypted row in response to the replacement of the beginning of the encrypted row.

[0099] Example 23 includes a method for memory isolation, the method comprising: receiving, by a computing device, a request to write a data row to a physical memory address, wherein the physical memory address includes a key identifier; selecting, by the computing device, an encryption key from a key table based on the key identifier of the physical memory address; determining, by the computing device, whether the data row is compressible; compressing, by the computing device, the data row to generate a compressed row in response to determining that the data row is compressible, wherein the compressed row includes compression metadata and compressed data; adding, by the computing device, encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key; encrypting, by the computing device, using the encryption key to generate an encrypted row in response to adding the encryption metadata; and writing, by the computing device, the encrypted row to a memory device at the physical memory address.

[0100] Example 24 includes the subject matter of Example 23, and wherein selecting the encryption key from the key table comprises indexing the key table with the key identifier to retrieve the encryption key.

[0101] Example 25 includes the subject matter of any of Examples 23 and 24, and wherein the encryption metadata includes a key identifier.

[0102] Example 26 includes the subject matter of any of Examples 23-25, and wherein the encryption metadata comprises a hash of the encryption key.

[0103] Example 27 includes the subject matter of any of Examples 23-26, and further comprising adding, by the computing device, a compression indicator to the compressed row, wherein the compression indicator comprises a predetermined bit pattern.

[0104] Example 28 includes the subject matter of any of Examples 23-27, and wherein encrypting the portion of the compressed row comprises encrypting the compression metadata and the compressed data.

[0105] Example 29 includes the subject matter of any of Examples 23-28, and wherein encrypting the portion of the compressed row further comprises encrypting the encryption metadata.

[0106] Example 30 includes the subject matter of any of Examples 23-29, and further includes: encrypting, by the computing device, a data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; determining, by the computing device, in response to encrypting the data row, whether the start of the encrypted row matches a compression indicator or a conflict indicator, wherein the conflict indicator includes a second predetermined bit pattern different from the compression indicator; updating, by the computing device, an entry of a conflict table corresponding to a physical memory address based on the start of the encrypted row in response to determining that the start of the encrypted row matches the compression indicator or the conflict indicator; and replacing, by the computing device, the start of the encrypted row with the conflict indicator in response to determining that the start of the encrypted row matches the compression indicator or the conflict indicator; wherein writing the encrypted row further includes writing the encrypted row in response to replacing the start of the encrypted row.

[0107] Example 31 includes the subject matter of any of Examples 23-30, and further includes: adding, by the computing device, integrity metadata to the compressed row, wherein the integrity metadata comprises an integrity check value based on the compressed data; wherein the encryption metadata comprises a key identifier; and wherein encrypting the portion of the compressed row comprises encrypting the compression metadata, the integrity metadata, and the compressed data.

[0108] Example 32 includes the subject matter of any of Examples 23-31, and further includes: encrypting, by a computing device, the data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; selecting, by the computing device, a second encryption key from a key table based on a first portion of the encrypted row; decrypting, by the computing device, the remaining portion of the encrypted row with the second encryption key to generate a test compressed row, wherein the test compressed row includes second compression metadata, second integrity metadata, and second compressed data; determining, by the computing device, whether the second integrity metadata is valid based on the second compressed data; updating, by the computing device, an entry in a conflict table corresponding to a physical memory address with the first portion of the encrypted row in response to determining that the second integrity metadata is valid; and replacing, by the computing device, the first portion of the encrypted row with a conflict indicator in response to determining that the second integrity metadata is valid, wherein the conflict indicator includes a predetermined bit pattern; wherein writing the encrypted row further includes writing the encrypted row in response to replacing the first portion of the encrypted row.

[0109] Example 33 includes the subject matter of any of Examples 23-32, and wherein encrypting the portion of the compressed row comprises: encrypting a first block with a block cipher to generate a first encrypted block, wherein the first block begins at an offset in the compressed row; generating a last block, wherein the last block includes a last portion of the compressed row and a first portion of the first encrypted block; encrypting the last block with a block cipher to generate a last encrypted block, and replacing the first portion of the first encrypted block with the last portion of the last encrypted block.

[0110] Example 34 includes a method for memory isolation, the method comprising: receiving, by a computing device, a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; selecting, by the computing device, a decryption key from a key table based on the key identifier of the physical memory address; determining, by the computing device, whether the beginning of the encrypted row matches a compression indicator, wherein the compression indicator includes a predetermined bit pattern; decrypting, by the computing device, a portion of the encrypted row using a decryption key to generate a compressed row in response to determining that the beginning of the encrypted row matches the compression indicator, wherein the compressed row includes compression metadata, encryption metadata, and compressed data; determining, by the computing device, whether the encryption metadata is verified against the decryption key; decompressing, by the computing device, the compressed data to generate a data row in response to determining that the encryption metadata is verified; and forwarding, by the computing device, the data row to a processor.

[0111] Example 35 includes the subject matter of Example 34, and wherein selecting the decryption key from the key table comprises indexing the key table with the key identifier to retrieve the decryption key.

[0112] Example 36 includes the subject matter of any of Examples 34 and 35, and wherein the encryption metadata comprises a key identifier.

[0113] Example 37 includes the subject matter of any of Examples 34-36, and wherein the encryption metadata comprises a hash of the decryption key.

[0114] Example 38 includes the subject matter of any of Examples 34-37, and further includes generating, by the computing device, a verification error in response to determining that the encryption metadata is not verified.

[0115] Example 39 includes the subject matter of any of Examples 34-38, and further includes: determining, by the computing device, in response to determining that the start of the encrypted row does not match the compression indicator, whether the start of the encrypted row matches a conflict indicator, wherein the conflict indicator comprises a predetermined bit pattern that is different from the compression indicator; and in response to determining that the start of the encrypted row does not match the conflict indicator, decrypting the entire encrypted row using a decryption key to generate a data row.

[0116] Example 40 includes the subject matter of any of Examples 34-39, and further includes: replacing, by the computing device, the start of the encrypted row with the compression indicator based on a value from a conflict table corresponding to a physical memory address of the encrypted row in response to determining that the start of the encrypted row matches the conflict indicator; wherein decrypting the entire encrypted row further includes decrypting the entire encrypted row in response to replacing the start of the encrypted row.

[0117] Example 41 includes a method for memory isolation, the method comprising: receiving, by a computing device, a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; determining, by the computing device, whether the beginning of the encrypted row matches a conflict indicator, wherein the conflict indicator includes a predetermined bit pattern; selecting, by the computing device, a decryption key from a key table based on the beginning of the encrypted row in response to determining that the beginning of the encrypted row does not match the conflict indicator; decrypting, by the computing device, a portion of the encrypted row using the decryption key to generate a compressed row, wherein the compressed row includes compression metadata, integrity metadata, and compressed data; determining, by the computing device, whether the integrity metadata is verified for the compressed data; decompressing, by the computing device, the compressed data to generate a data row in response to determining that the integrity metadata is verified for the compressed data; and forwarding, by the computing device, the data row to the processor.

[0118] Example 42 includes the subject matter of Example 41, and further includes: determining, by the computing device, whether the start of the encrypted row matches the key identifier of the physical memory address in response to determining that the integrity metadata is verified for the compressed data; and generating, by the computing device, a verification error in response to determining that the start of the encrypted row does not match the key identifier of the physical memory address; wherein decompressing the compressed data further includes decompressing the compressed data in response to determining that the start of the encrypted row matches the key identifier of the physical memory address.

[0119] Example 43 includes the subject matter of any of Examples 41 and 42, and further includes: selecting, by the computing device, a second decryption key from the key table based on the key identifier of the physical memory address in response to determining that the integrity metadata is not verified for the compressed data; and in response to selecting the second decryption key, decrypting the entire encrypted row using the second decryption key to generate a data row; wherein forwarding the data row further includes forwarding the data row in response to decrypting the entire encrypted row.

[0120] Example 44 includes the subject matter of any of Examples 41-43, and further includes: replacing, by the computing device, the beginning of the encrypted row with a value from a collision table corresponding to a physical memory address of the encrypted row in response to determining that the beginning of the encrypted row matches the collision indicator; wherein decrypting the entire encrypted row further includes decrypting the entire encrypted row in response to replacing the beginning of the encrypted row.

[0121] Example 45 includes a computing device comprising: a processor; and a memory having a plurality of instructions stored therein that, when executed by the processor, cause the computing device to perform the method of any of Examples 22-44.

[0122] Example 46 includes one or more machine-readable storage media including a plurality of instructions stored thereon that, in response to execution of the plurality of instructions, cause a computing device to perform the method of any of Examples 22-44.

[0123] Example 47 includes a computing device comprising means for performing the method of any of Examples 22-44.

[0124] Example 48 includes a computing device for memory isolation, the computing device comprising: a device for receiving a request to write a data row to a physical memory address, wherein the physical memory address includes a key identifier; a device for selecting an encryption key from a key table based on the key identifier of the physical memory address; a device for determining whether the data row is compressible; a device for compressing the data row to generate a compressed row in response to determining that the data row is compressible, wherein the compressed row includes compression metadata and compressed data; a device for adding encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key; a device for encrypting a portion of the compressed row using the encryption key to generate an encrypted row in response to adding the encryption metadata; and a device for writing the encrypted row to a memory device at the physical memory address.

[0125] Example 49 includes the subject matter of Example 48, and wherein the means for selecting the encryption key from the key table comprises means for indexing the key table using the key identifier to retrieve the encryption key.

[0126] Example 50 includes the subject matter of any of Examples 48 and 49, and wherein the encryption metadata includes a key identifier.

[0127] Example 51 includes the subject matter of any of Examples 48-50, and wherein the encryption metadata comprises a hash of the encryption key.

[0128] Example 52 includes the subject matter of any of Examples 48-51, and further includes means for adding a compression indicator to the compressed row, wherein the compression indicator comprises a predetermined bit pattern.

[0129] Example 53 includes the subject matter of any of Examples 48-52, and wherein the means for encrypting the portion of the compressed row comprises means for encrypting the compression metadata and the compressed data.

[0130] Example 54 includes the subject matter of any of Examples 48-53, and wherein the means for encrypting the portion of the compressed row further comprises means for encrypting the encryption metadata.

[0131] Example 55 includes the subject matter of any of Examples 48-54, and further includes: means for encrypting a data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; means for determining whether the beginning of the encrypted row matches a compression indicator or a conflict indicator in response to encrypting the data row, wherein the conflict indicator includes a second predetermined bit pattern different from the compression indicator; means for updating an entry of a conflict table corresponding to a physical memory address based on the beginning of the encrypted row in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; and means for replacing the beginning of the encrypted row with the conflict indicator in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; wherein the means for writing the encrypted row further includes means for writing the encrypted row in response to replacing the beginning of the encrypted row.

[0132] Example 56 includes the subject matter of any of Examples 48-55, and further includes: means for adding integrity metadata to the compressed row, wherein the integrity metadata comprises an integrity check value based on the compressed data; wherein the encryption metadata comprises a key identifier; and wherein the means for encrypting a portion of the compressed row comprises means for encrypting the compression metadata, the integrity metadata, and the compressed data.

[0133] Example 57 includes the subject matter of any of Examples 48-56, and further includes: means for encrypting the data row with an encryption key to generate an encrypted row in response to determining that the data row is incompressible; means for selecting a second encryption key from a key table based on a first portion of the encrypted row; means for decrypting the remaining portion of the encrypted row with the second encryption key to generate a test compressed row, wherein the test compressed row includes second compression metadata, second integrity metadata, and second compressed data; means for determining whether the second integrity metadata is valid based on the second compressed data; means for updating an entry in a conflict table corresponding to a physical memory address with the first portion of the encrypted row in response to determining that the second integrity metadata is valid; and means for replacing the first portion of the encrypted row with a conflict indicator in response to determining that the second integrity metadata is valid, wherein the conflict indicator includes a predetermined bit pattern; wherein the means for writing the encrypted row also includes means for writing the encrypted row in response to replacing the first portion of the encrypted row.

[0134] Example 58 includes the subject matter of any of Examples 48-57, and wherein encrypting the portion of the compressed row comprises: means for encrypting a first block with a block cipher to generate a first encrypted block, wherein the first block begins at an offset in the compressed row; means for generating a last block, wherein the last block includes a last portion of the compressed row and a first portion of the first encrypted block; means for encrypting the last block with a block cipher to generate a last encrypted block, and means for replacing the first portion of the first encrypted block with the last portion of the last encrypted block.

[0135] Example 59 includes a computing device for memory isolation, the computing device comprising: a device for receiving a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; a device for selecting a decryption key from a key table based on the key identifier of the physical memory address; a device for determining whether the beginning of the encrypted row matches a compression indicator, wherein the compression indicator includes a predetermined bit pattern; a device for decrypting a portion of the encrypted row with a decryption key to generate a compressed row in response to determining that the beginning of the encrypted row matches the compression indicator, wherein the compressed row includes compression metadata, encryption metadata, and compressed data; a device for determining whether the encryption metadata is verified against the decryption key; a device for decompressing the compressed data to generate a data row in response to determining that the encryption metadata is verified; and a device for forwarding the data row to a processor.

[0136] Example 60 includes the subject matter of Example 59, and wherein the means for selecting the decryption key from the key table comprises means for indexing the key table using the key identifier to retrieve the decryption key.

[0137] Example 61 includes the subject matter of any of Examples 59 and 60, and wherein the encryption metadata includes a key identifier.

[0138] Example 62 includes the subject matter of any of Examples 59-61, and wherein the encryption metadata comprises a hash of the decryption key.

[0139] Example 63 includes the subject matter of any of Examples 59-62, and further includes means for generating a verification error in response to determining that the encryption metadata is not verified.

[0140] Example 64 includes the subject matter of any of Examples 59-63, and further includes: means for determining whether the beginning of the encrypted row matches a collision indicator in response to determining that the beginning of the encrypted row does not match the compression indicator, wherein the collision indicator comprises a predetermined bit pattern that is different from the compression indicator; and means for decrypting the entire encrypted row using a decryption key to generate a data row in response to determining that the beginning of the encrypted row does not match the collision indicator.

[0141] Example 65 includes the subject matter of any of Examples 59-64, and further includes: means for replacing the start of the encrypted row with a compression indicator based on a value from a conflict table corresponding to a physical memory address of the encrypted row in response to determining that the start of the encrypted row matches the conflict indicator; wherein the means for decrypting the entire encrypted row further includes means for decrypting the entire encrypted row in response to replacing the start of the encrypted row.

[0142] Example 66 includes a computing device for memory isolation, the computing device comprising: a device for receiving a request to read an encrypted row from a physical memory address of the computing device, wherein the physical memory address includes a key identifier; a device for determining whether the beginning of the encrypted row matches a conflict indicator, wherein the conflict indicator includes a predetermined bit pattern; a device for selecting a decryption key from a key table based on the beginning of the encrypted row in response to determining that the beginning of the encrypted row does not match the conflict indicator; a device for decrypting a portion of the encrypted row using the decryption key to generate a compressed row, wherein the compressed row includes compression metadata, integrity metadata and compressed data; a device for determining whether the integrity metadata is verified for the compressed data; a device for decompressing the compressed data to generate a data row in response to determining that the integrity metadata is verified for the compressed data; and a device for forwarding the data row to the processor.

[0143] Example 67 includes the subject matter of Example 66, and further includes: means for determining whether the start of an encrypted row matches a key identifier of a physical memory address in response to determining that the integrity metadata is verified for the compressed data; and means for generating a verification error in response to determining that the start of the encrypted row does not match the key identifier of the physical memory address; wherein the means for decompressing the compressed data further includes means for decompressing the compressed data in response to determining that the start of the encrypted row matches the key identifier of the physical memory address.

[0144] Example 68 includes the subject matter of any of Examples 66 and 67, and further includes: means for selecting a second decryption key from the key table based on a key identifier of a physical memory address in response to determining that the integrity metadata is not verified for the compressed data; and means for decrypting the entire encrypted row using the second decryption key to generate a data row in response to selecting the second decryption key; wherein the means for forwarding the data row further includes means for forwarding the data row in response to decrypting the entire encrypted row.

[0145] Example 69 includes the subject matter of any of Examples 66-68, and further includes: means for replacing the beginning of the encrypted row with a value from a conflict table corresponding to the physical memory address of the encrypted row in response to determining that the beginning of the encrypted row matches the conflict indicator; wherein the means for decrypting the entire encrypted row further includes means for decrypting the entire encrypted row in response to replacing the beginning of the encrypted row.

Claims

1. A computing device for memory isolation, the computing device comprising: a memory manager configured to receive a request to write a row of data to a physical memory address, wherein the physical memory address includes a key identifier; a key manager for selecting an encryption key from a key table based on the key identifier of the physical memory address; a compression manager to: (i) determine whether the data row is compressible; and (ii) in response to determining that the data row is compressible, compress the data row to generate a compressed row, wherein the compressed row includes compression metadata and compressed data; and an encryption manager to: (i) add encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key and wherein the encryption metadata includes the key identifier; (ii) add integrity metadata to the compressed row, wherein the integrity metadata includes an integrity check value based on the compressed data; and (iii) in response to adding the encryption metadata, encrypt a portion of the compressed row with the encryption key to generate an encrypted row, wherein encrypting the portion of the compressed row comprises encrypting the compression metadata, the integrity metadata, and the compressed data; The memory manager is further configured to write the encrypted row into a memory device at the physical memory address.

2. The computing device of claim 1, wherein: Selecting the encryption key from the key table includes indexing the key table with the key identifier to retrieve the encryption key.

3. The computing device of claim 1 , wherein: The encryption metadata includes the key identifier.

4. The computing device of claim 1 , wherein: The encryption metadata includes a hash of the encryption key.

5. The computing device of claim 1 , wherein: The compression manager is further configured to add a compression indicator to the compressed row, wherein the compression indicator comprises a predetermined bit pattern.

6. The computing device of claim 5, wherein: Encrypting the portion of the compressed row includes encrypting the compression metadata and the compressed data.

7. The computing device of claim 6, wherein: Encrypting the portion of the compressed row further includes encrypting the encryption metadata.

8. The computing device of claim 5, further comprising a conflict manager, the conflict manager configured to: encrypting the row of data with the encryption key to generate the encrypted row in response to determining that the row of data is not compressible; In response to encryption of the data row, determining whether the beginning of the encrypted row matches the compression indicator or the conflict indicator, wherein the conflict indicator comprising a second predetermined bit pattern different from the compression indicator; In response to determining that the start of the encrypted row matches the compression indicator or the conflict indicator, updating an entry of a conflict table corresponding to the physical memory address based on the start of the encrypted row; replacing the beginning of the encrypted row with the conflict indicator in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; Wherein, writing the encrypted row further comprises: writing the encrypted row in response to a replacement of the beginning of the encrypted row.

9. The computing device of claim 1 , further comprising a conflict manager, the conflict manager configured to: encrypting the row of data with the encryption key to generate the encrypted row in response to determining that the row of data is not compressible; selecting a second encryption key from the key table based on the first portion of the encrypted row; decrypting a remaining portion of the encrypted row with the second encryption key to generate a test compressed row, wherein the test compressed row includes second compression metadata, second integrity metadata, and second compressed data; determining whether the second integrity metadata is valid based on the second compressed data; In response to determining that the second integrity metadata is valid, updating an entry of a conflict table corresponding to the physical memory address with the first portion of the encrypted row; as well as In response to determining that the second integrity metadata is valid, replacing the first portion of the encrypted row with a conflict indicator, wherein the conflict indicator comprises a predetermined bit pattern; Wherein, writing the encrypted row further comprises: writing the encrypted row in response to the replacement of the first portion of the encrypted row.

10. The computing device of claim 1, wherein: Encrypting the portion of the compressed row includes: encrypting a first block with a block cipher to generate a first encrypted block, wherein the first block begins at an offset in the compressed row; generating a final block, wherein the final block includes a last portion of the compressed row and a first portion of the first encrypted block; encrypting the final block with the block cipher to generate a final encrypted block; and The first portion of the first encrypted block is replaced with the last portion of the last encrypted block.

11. A method for memory isolation, the method comprising: receiving, by a computing device, a request to write a row of data to a physical memory address, wherein the physical memory address includes a key identifier; selecting, by the computing device, an encryption key from a key table based on the key identifier of the physical memory address; determining, by the computing device, whether the data row is compressible; compressing, by the computing device, the row of data in response to determining that the row of data is compressible to generate a compressed row, wherein the compressed row includes compression metadata and compressed data; adding, by the computing device, encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key, and wherein the encryption metadata includes the key identifier; adding, by the computing device, integrity metadata to the compressed row, wherein the integrity metadata comprises an integrity check value based on the compressed data; encrypting, by the computing device in response to adding the encryption metadata, the portion of the compressed row using the encryption key to generate an encrypted row, wherein encrypting the portion of the compressed row comprises: encrypting the compression metadata, the integrity metadata, and the compressed data; and The encrypted row is written, by the computing device, to a memory device at the physical memory address.

12. The method of claim 11, wherein: The encryption metadata includes the key identifier.

13. The method of claim 11, wherein: The encryption metadata includes a hash of the encryption key.

14. The method of claim 11, further comprising: A compression indicator is added, by the computing device, to the compressed row, wherein the compression indicator comprises a predetermined bit pattern.

15. The method of claim 14, further comprising: encrypting, by the computing device in response to determining that the row of data is not compressible, the row of data using the encryption key to generate the encrypted row; determining, by the computing device in response to encrypting the row of data, whether a beginning of the encrypted row matches the compression indicator or a collision indicator, wherein the collision indicator comprises a second predetermined bit pattern different from the compression indicator; updating, by the computing device, an entry of a conflict table corresponding to the physical memory address based on the start of the encrypted row in response to determining that the start of the encrypted row matches the compression indicator or the conflict indicator; and replacing, by the computing device, the beginning of the encrypted row with the conflict indicator in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; Wherein, writing the encrypted row further comprises: writing the encrypted row in response to replacing the beginning of the encrypted row.

16. The method of claim 11, further comprising: encrypting, by the computing device in response to determining that the row of data is not compressible, the row of data using the encryption key to generate the encrypted row; selecting, by the computing device, a second encryption key from the key table based on the first portion of the encrypted row; decrypting, by the computing device, a remaining portion of the encrypted row using the second encryption key to generate a test compressed row, wherein the test compressed row includes second compression metadata, second integrity metadata, and second compressed data; determining, by the computing device, whether the second integrity metadata is valid based on the second compressed data; updating, by the computing device in response to determining that the second integrity metadata is valid, an entry of a conflict table corresponding to the physical memory address with the first portion of the encrypted row; and replacing, by the computing device in response to determining that the second integrity metadata is valid, the first portion of the encrypted row with a replacement conflict indicator, wherein the conflict indicator comprises a predetermined bit pattern; Wherein, writing the encrypted row further comprises: writing the encrypted row in response to replacing the first portion of the encrypted row.

17. A computing device for memory isolation, the computing device comprising: means for receiving a request to write a row of data to a physical memory address, wherein the physical memory address includes a key identifier; means for selecting an encryption key from a key table based on a key identifier of the physical memory address; means for determining whether the data row is compressible; means for compressing the row of data to generate a compressed row in response to determining that the row of data is compressible, wherein the compressed row includes compression metadata and compressed data; means for adding encryption metadata to the compressed row, wherein the encryption metadata indicates the encryption key, and wherein the encryption metadata includes the key identifier; means for adding integrity metadata to the compressed row, wherein the integrity metadata comprises an integrity check value based on the compressed data; means for encrypting the portion of the compressed row using the encryption key in response to adding the encryption metadata to generate an encrypted row, wherein encrypting the portion of the compressed row comprises: encrypting the compression metadata, the integrity metadata, and the compressed data; and Means for writing the encrypted row to a memory device at the physical memory address.

18. The computing device of claim 17, wherein: The encryption metadata includes the key identifier.

19. The computing device of claim 17, wherein: The encryption metadata includes a hash of the encryption key.

20. The computing device of claim 17, further comprising means for adding a compression indicator to the compressed row, wherein The compression indicator comprises a predetermined bit pattern.

21. The computing device of claim 20, further comprising: means for encrypting the row of data with the encryption key to generate the encrypted row in response to determining that the row of data is not compressible; means for determining, in response to encrypting the row of data, whether the beginning of the encrypted row matches the compression indicator or a collision indicator, wherein the collision indicator comprises a second predetermined bit pattern different from the compression indicator; means for updating an entry of a conflict table corresponding to the physical memory address based on the start of the encrypted row in response to determining that the start of the encrypted row matches the compression indicator or the conflict indicator; and means for replacing the beginning of the encrypted row with the conflict indicator in response to determining that the beginning of the encrypted row matches the compression indicator or the conflict indicator; Wherein, the means for writing the encrypted row further comprises: means for writing the encrypted row in response to replacing the beginning of the encrypted row.

22. The computing device of claim 17, further comprising: means for encrypting the row of data with the encryption key to generate the encrypted row in response to determining that the row of data is not compressible; means for selecting a second encryption key from the key table based on the first portion of the encrypted row; means for decrypting a remainder of the encrypted row with the second encryption key to generate a test compressed row, wherein the test compressed row comprises second compression metadata, second integrity metadata, and second compressed data; means for determining whether the second integrity metadata is valid based on the second compressed data; means for updating an entry of a conflict table corresponding to the physical memory address with the first portion of the encrypted row in response to determining that the second integrity metadata is valid; and means for replacing the first portion of the encrypted row with a conflict indicator in response to determining that the second integrity metadata is valid, wherein the conflict indicator comprises a predetermined bit pattern; Wherein, the means for writing the encrypted row further comprises: means for writing the encrypted row in response to replacing the first portion of the encrypted row.

Images