Patent Description:
<CIT> relates to an apparatus that comprises a controller. The controller comprises circuitry and aims at generating an error correction code for a memory line, the memory line comprising a plurality of first data blocks. The error correction code comprises parity bits generated based on first portions of a plurality of second data blocks, wherein the plurality of second data blocks are the first data blocks or diffused data blocks generated from the plurality of first data blocks. Further, a metadata block corresponding to the memory line is generated, wherein the metadata block comprises the error correction code for the memory line and at least one metadata bit. The first data blocks and the metadata block are then encoded. Finally, the encoded data blocks and the encoded metadata block are provided for storage on a memory module.

<CIT> relates to a method and apparatus for controlling the unauthorized removal of software from a non-volatile storage medium. The method includes storing an encoded version of the software at an address of the storage medium where the address is used as data directly in the process of deriving an encoding key used to encode the software, and decoding the encoded software using a decoding key derived using the location of the software in its storage medium as data.

It is the object of the present invention to provide an improved method and system for allowing multiple entities to access the same memory.

One aspect of the present disclosure relates to a method in a system including a processor and a memory. The method may include receiving data for storage at an address in the memory. The method may further include after encoding the data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a watermark to generate watermarked data for storage in the memory, where the watermark is generated by applying a cryptographic function to a user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits.

In yet another aspect, the present disclosure relates to a system including a host server comprising a memory controller coupled to a memory and a processor. The system may further include a hypervisor, associated with the host server, configured to manage a plurality of compute entities. The memory controller may be configured to: (<NUM>) receive data from a compute entity from among one of the plurality of compute entities for storing at an address in the memory, and (<NUM>) after encoding the data with an error correction code to generate intermediate data having a first number of bits, reversibly alter the intermediate data with a watermark to generate watermarked data for storage in the memory, where the watermark is generated by applying a cryptographic function to the address, and where the watermarked data has a second number of bits equal to the first number of bits.

In another aspect, the present disclosure relates to a method performed in a host server including a processor and a memory. The method may include receiving plaintext data from a compute entity, from among one of a plurality of compute entities associated with the host server, for storing at an address in the memory. The method may further include encrypting the plaintext data using at least a user key associated with the compute entity to generate encrypted data. The method may further include after encoding the encrypted data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a message authentication code to generate watermarked data for storage in the memory, where the message authentication code is generated by applying a cryptographic function to the user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits.

Examples described in this disclosure relate to ensuring the integrity of data stored in a multi-user computing system by using a watermark. The data may be stored in memory modules included in a host server. Multiple host servers may be included in a rack of servers or a stack of servers. The host server may be any server in a cloud computing environment that is configured to serve tenants or other subscribers of the cloud computing service. Example memory technologies include, but are not limited to, volatile-memory technologies, non-volatile memory technologies, and quasi-volatile memory technologies. Example memory types include dynamic random access memory (DRAM), flash memory (e.g., NAND flash), ferroelectric random-access memory (FeRAM), magnetic random-access memory (MRAM), phase-change memory (PCM), and resistive random-access memory (RRAM). Broadly speaking, examples of the present disclosure relate to a computing environment in which even if one user can access another user's memory, it cannot do so without being detected. Examples of the techniques described in the present disclosure may be implemented in systems such as personal computers, laptops, mobile phones, cellular towers (e.g., <NUM> cellular towers), edge-computing sites, gaming controllers or other like devices.

Cloud computing may refer to a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly. A cloud computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may be used to expose various service models, such as, for example, Hardware as a Service ("HaaS"), Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). A cloud computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

<FIG> shows a diagram of a system environment <NUM> for ensuring the integrity of data stored by using a watermark in accordance with one example. In this example, system environment <NUM> may correspond to a cloud computing stack in a data center. System environment <NUM> may be implemented as a rack of servers. In this example, system environment <NUM> may include host servers <NUM>, <NUM>, and <NUM>. Each of the host servers may include one or more processors configured to provide at least some form of compute functionality. As an example, host server <NUM> may include CPU <NUM> and CPU <NUM>, host server <NUM> may include CPU <NUM> and CPU <NUM>, and host server <NUM> may include CPU <NUM> and CPU <NUM>. Host server <NUM> may further include memory <NUM> and memory <NUM>. Host server <NUM> may further include memory <NUM> and memory <NUM>. Host server <NUM> may further include memory <NUM> and memory <NUM>.

With continued reference to <FIG>, host server <NUM> may be configured to execute instructions corresponding to hypervisor <NUM>. Hypervisor <NUM> may further be configured to interface with virtual machines (VMs) (e.g., VM <NUM>, VM <NUM>, and VM <NUM>). Instructions corresponding to the VMs may be executed using either of CPU <NUM> or CPU <NUM> associated with host server <NUM>. Hypervisor <NUM> may further be configured to interface with virtual machines (VMs) (e.g., VM <NUM>, VM <NUM>, and VM <NUM>). Instructions corresponding to these VMs may be executed using either of CPU <NUM> or CPU <NUM> associated with host server <NUM>. Hypervisor <NUM> may further be configured to interface with virtual machines (VMs) (e.g., VM <NUM>, VM <NUM>, and VM <NUM>). Instructions corresponding to these VMs may be executed using either of CPU <NUM> or CPU <NUM> associated with host server <NUM>.

Hypervisor <NUM> may share control information with hypervisor <NUM> via a control path. The control path may correspond to a path implemented using a bus system (e.g., a server rack bus system or other types of bus systems). Hypervisor <NUM> may share control information with hypervisor <NUM> via another control path. The control path may correspond to a path implemented using a bus system. Each of hypervisor <NUM>, hypervisor <NUM>, and hypervisor <NUM> may be a kernel-based virtual machine (KVM) hypervisor, a Hyper-V hypervisor, or another type of hypervisor. Although <FIG> shows system <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. As an example, although not shown in <FIG>, each host server may include an operating system for managing certain aspects of the host server. As another example, system <NUM> may include any number of host servers combined as part of a rack or a stack. As another example, each host server may include any number of CPUs, GPUs, memory modules, or other components, as needed for providing cloud computing, storage, and/or networking functions. In addition, the functionality associated with system <NUM> may be distributed or combined, as needed. Moreover, although <FIG> describes the access to the host server's memory by VMs, other types of compute entities, such as containers, micro-VMs, microservices, and unikernels for serverless functions, may access the memory in a like manner. As used herein, the term "compute entity" encompasses, but is not limited to, any executable code (in the form of hardware, firmware, software, or in any combination of the foregoing) that implements a functionality, a hypervisor, an application, a service, a micro-service, a container, a unikernel for serverless computing, or a part of the aforementioned.

<FIG> shows a host server <NUM> including a memory controller <NUM> in accordance with one example. Host server <NUM> may include a CPU <NUM>, cache <NUM>, memory controller <NUM>, and memory <NUM>. CPU <NUM> may be coupled to cache <NUM>, via bus <NUM>, to allow fast access to cached instructions or data. In this example, cache <NUM> may be an L2 cache and may also be coupled to other caches, such as an L1 cache (not shown). CPU <NUM> may be coupled to memory controller <NUM> to allow for the exchange of data/control signals. Cache <NUM> may also be coupled to memory controller <NUM> to allow for exchange of data and metadata or other information. In one example, CPU <NUM>, cache <NUM>, and memory controller <NUM> may be incorporated in a single module (e.g., an SoC). Memory controller <NUM> may be coupled to memory <NUM> via a bus <NUM> (e.g., a DDR memory bus or another type of bus). Memory <NUM> may correspond to any of the various types of storage media, including random access memories (e.g., DRAM), storage class memories, or any other type of storage suitable for storing data for use as part of host server <NUM>. In addition, although not shown, a clock source may be used to synchronize signals, as needed. Clock source may be implemented as a phase-locked loop (PLL) circuit or another type of clocking circuit. In one example, memory <NUM> may correspond to DRAM modules (e.g., DIMMs) coupled via a bus <NUM> (e.g., a single channel or multiple channels) to memory controller <NUM>. Each memory module may include memory chips.

With respect to the access to memory (e.g., DIMMs) associated with the host server, at a broad level, there may be two ways for a compute entity (e.g., a virtual machine (VM)) to access a host server's memory. In those instances, where the VM is accessing the physical memory associated with the CPU it is being executed, then load or store accesses may be translated to the bus transactions by the hardware associated with the system.

Still referring to <FIG>, memory controller <NUM> may receive addresses (ADDR) from CPU <NUM> via bus <NUM>. Memory controller <NUM> may include address decoding logic (not shown) to decode the received address and provide commands to memory <NUM>. As an example, in case memory <NUM> is implemented as a DRAM, memory controller <NUM> may decode the received address into appropriate control signals for accessing the DRAM. In this example, the addresses may correspond to host physical addresses. In one example, an operating system (not shown) associated with host server <NUM> may maintain a mapping between virtual addresses (used by compute entities such as virtual machines) and host physical addresses. A memory management unit (MMU) associated with CPU <NUM> may translate the virtual addresses into host physical addresses. Other appropriate address translation mechanisms may also be used. Memory controller <NUM> may further maintain a mapping between the host physical addresses and the logical addresses for memory <NUM>. As an example, in case memory <NUM> is a DRAM, then logical addresses may correspond to DDR logical addresses.

Memory controller <NUM> may receive data (DATA) from cache <NUM> via bus <NUM>. Memory controller <NUM> may include a key generator <NUM>. Key generator <NUM> may be coupled via a bus <NUM> to scrambling logic <NUM>. Key generator <NUM> may further be coupled via a bus <NUM> to encryption logic/decryption logic <NUM>. Scrambling logic <NUM> may be coupled via a bus <NUM> with watermark logic <NUM>. Encryption logic/decryption logic <NUM> may be coupled to ECC encoder/decoder <NUM> via bus <NUM>. ECC encoder/decoder <NUM> may be coupled via a bus <NUM> to watermark logic <NUM>. Watermark logic <NUM> may be coupled via a bus <NUM> to memory <NUM>. Although <FIG> shows system host server <NUM> and memory controller <NUM> as including a certain number of components arranged and coupled in a certain way, each may include fewer or additional components arranged and coupled differently. As an example, although not shown in <FIG>, each host server <NUM> may include an operating system for managing certain aspects of the host server. As another example, each host server <NUM> may include any number of CPUs, GPUs, memory modules, or other components, as needed for providing cloud computing, storage, and/or networking functions. In addition, the functionality associated with host server <NUM> may be distributed or combined, as needed. Moreover, memory controller <NUM> may include additional functionality, including the ability to control multiple channels coupled to different memory media. As another example, watermark logic <NUM> may be coupled to a channel controller (not shown), which may in turn be coupled to memory <NUM>.

With continued reference to <FIG>, in one example, hypervisor may assign a unique logical number to each user (e.g., a guest VM). This logical number may be referred to as a user ID. CPU <NUM> may provide the user ID to cache <NUM>, such that it could be broadcast to all memory channels associated with CPU <NUM>. Thus, with respect to host server <NUM>, the user ID may be provided to key generator <NUM> included as part of memory controller <NUM>. The channel associated with memory controller <NUM> may generate a number to serve as the key for the user associated with the user ID. When a write operation is performed for a user, the user ID may be used to generate a user key, or a previously generated user key may be used. Thus, in one example, when memory controller <NUM> is notified of a new valid user ID, key generator <NUM> may generate a user key corresponding to the user ID and store it inside memory controller <NUM>. In this manner, when a preexisting user ID is associated with a memory operation, memory controller <NUM> may simply use the stored user key instead of generating a new user key.

A CPU (e.g., CPU <NUM> of <FIG>) may access both memory <NUM> and memory <NUM> using the same user ID for a compute entity. In addition, a memory operation performed by a compute entity running on CPU <NUM>, CPU <NUM>, or on both CPU <NUM> and CPU <NUM> at the same time, may use the same user ID regardless of which CPU initiates the memory operation. In another example, the user ID may be local to each CPU. Thus, in a system with two CPUs, one CPU may register the user ID as X with its attached memory controller and the other CPU may register the user ID as Y with its attached memory controller, and a bus system interconnecting the two CPUs (e.g., the UPI bus) may translate between the two user IDs so that the correct user ID (X or Y) is presented to the memory controller servicing the memory operation at issue. The user key (e.g., USER KEY) may be used to encrypt the data so as to convert the data from plaintext to ciphertext. As an example, encryption logic/decryption logic <NUM> may be used to convert the data from plaintext into ciphertext. When a read operation is performed on behalf of the same user, then the same previously generated user key may be used for the decryption. As an example, encryption logic/decryption logic <NUM> may be used for performing encryption and decryption.

Once a user key is generated it may be stored as part of an array (or another type of data structure) inside memory controller <NUM>. Memory controller <NUM> may be configured such that the user keys cannot be accessed from outside and do not ever exit memory controller <NUM>. At some time later the hypervisor may determine that the compute entity (e.g., a guest VM) requires shutdown or termination. This may be a result of a virtual machine being uninstalled or otherwise being terminated. Hypervisor (e.g., any of hypervisors <NUM>, <NUM>, or <NUM>) may broadcast another command to memory controller <NUM> indicating that the user ID associated with the compute entity is no longer valid. Memory controller <NUM> may erase the user key associated with the compute entity (e.g., a guest VM). Thus, even if CPU <NUM> issues an instruction to read data associated with the user ID of the compute entity that is no longer valid, memory controller <NUM> would not be able to generate the correct watermark, and an exception would be thrown. This way, even malicious code posing as the user with the invalid user ID would not be able to get to that data because the user key associated with the invalid user ID has already been erased.

Still referring to <FIG>, the encrypted data may be encoded using an ECC code. Example ECC codes include but are not limited to Reed-Solomon codes, Bose-Chaudhuri-Hocquenghem (BCH) codes, and Low Density Parity Check (LDPC) codes. As an example, ECC encoder/decoder <NUM> may generate <NUM> bits of code of which <NUM> bits may be data bits and <NUM> bits may be ECC bits.

With continued reference to <FIG>, after encoding the encrypted data with an error correction code to generate intermediate data having a first number of bits (e.g., <NUM> bits of which <NUM> bits may be data bits and <NUM> bits may be ECC bits), watermark logic <NUM> of <FIG> may be used to apply a watermark (e.g., a message authentication code (MAC)) to the intermediate data to generate watermarked data for storage in the memory. In one example, the MAC may be a cryptographic function with a key and an input. To ensure a stronger security guarantee, in one example, the function may be a pseudorandom function. The watermark may be combined with the intermediate data using any type of permutation, scrambling, or combining function that results in a reversible alteration of the intermediate data. Appropriate MACs may be constructed with hash functions (e.g., HMAC (Keyed-Hashing for Message Authentication), KMAC (KECCAK Message Authentication Code) or block ciphers (e.g., Advanced Encryption Standard (AES)-CMAC). Although such MACs have a fixed output length, they can be applied repeatedly to the input along with a counter to create as many output bits as needed. Apart from MACs, other keyed cryptographic functions that have a pseudorandom output may also be used. As an example, block ciphers (e.g., Advanced Encryption Standard (AES)-cipher block chaining (CBC) or AES-CTR (Counter block mode)) may be used to encrypt the user key and/or the address and counter. In addition, stream ciphers where the output depends on the user key and address may also be used.

Example alterations include but are not limited to performing an exclusive OR operation between the watermark and the intermediate data, rotating the intermediate data based on the watermark, and other alterations that are reversible in nature. The watermark is selected to ensure that the position of errors is not changed after the application of the watermark. As an example, Reed-Solomon code can be understood as having symbols that must be aligned at certain points. Assuming, in one example, the application of the watermark is a rotation, and thus some of the bits of the symbol are rotated into a different symbol, while some of those bits of the symbol are left in the original symbol. In this example, if there was an actual error in the data, there is a possibility that there was an error in only one symbol and the underlying memory media is designed to try to keep fault mechanisms localized to a single symbol. Because those bits have been moved into two separate symbols, the error can no longer be corrected. Accordingly, in this example, the memory system has been weakened by transforming a correctable error into an uncorrectable error. If instead, no bits were allowed to go into a different symbol, then the memory system has not been weakened because even if the bits were moved to different locations within the same symbol, the error can still be corrected. Hence, a rotation that does not result in data bits moving across symbols may be a valid permutation to use. For example, the exclusive OR mechanism does not move bits at all, and so the errors remain in the original underlying position and thus are exactly as correctable as before the application of the watermark.

In response to a read request from CPU <NUM> for reading data at an address, the watermark may be applied to the retrieved watermarked data (e.g., stored in memory <NUM>) to generate intermediate data. As an example, watermark logic <NUM> may permute the watermark with the watermarked data retrieved from the address to generate the intermediate data. ECC encoder/decoder <NUM> may decode the intermediate data to generate decoded data; if the decoding results in an uncorrectable error the read operation may be terminated by memory controller <NUM>, otherwise the decoded data may be decrypted using encryption logic/decryption logic <NUM> to generate plaintext data. The plaintext data may be provided to CPU <NUM> via cache <NUM>.

In sum, in the examples associated with the present disclosure, the example memory controller is configured to generate an authentication code (e.g., a message authentication code (MAC)) but rather than write it as additional data into the memory, it is used to reversibly alter the data encoded by the error correction code (ECC). In conventional systems, a MAC may be stored as metadata besides the user data and the ECC. Since every bit is a precious resource this causes conflicts such as a compromise between the size of the MAC and the strength in the ECC. Moreover, a system in which the ECC strength is reduced cannot really be more secure because the corruption of the data bits is a possible attack vector. One of the advantages of the permutation scheme is that there is no competition for the metadata bits, and at the same time there is no weakening of the ECC. Thus, in other words, the message authentication code (MAC) is used as an implicit MAC rather than as an explicit MAC for ensuring the integrity of the data stored in the memory.

In such a system, the matching read and write operations add and subtract entropy to the data bits in a precise balance so that when the MACs match, which is required, the information for the MAC effectively disappears and the ECC system has full integrity. Certain examples of the present disclosure further require that the allowed permutations must be ones which do not move bits outside of their correction symbol, and additionally the MAC may be used in the ECC for purposes such as adjusting weightings due to physical differences in error rate on different bit positions.

In certain examples, without requiring additional metadata bits, methods of imprinting a message authentication code into the data storage are described. These techniques use the MAC to permute the data during the write operation, and the same MAC is used to reverse the alterations during the read operation. This data is reversibly altered after the error correction code is computed. If the user performing the write operation is different from the user performing the read operations, their keys would be different from each other and thus their MACs will not match so the reversible alteration will not be reversed and the ECC will fail. In effect, in such examples, the MAC has been stored as a "watermark" which needs no additional bits, and the ECC mechanism is borrowed to function as the MAC integrity check.

If the MAC used by the writer is not the same as the MAC used by the reader, then the reversibly altered data will not match, and the data is not restored to the original value. The reversible alteration operation is performed across all bits, thereby effectively generating a random codeword, so the ECC will report mismatches as uncorrectable errors. In these examples, the ECC integrity must be strong enough to support security requirements since the system would not be secure if other causes of error were not detected. Advantageously, the use of the MAC to reversibly alter the data eliminates storage overhead. In effect, the MAC entropy is orthogonally imprinted into all the data bits, but if the same MAC is used by the reader then the imprint is completely removed so the data may proceed through error correction with the full strength and integrity of error correction unimpaired. The reversible alteration method is required to be such that if an error does occur in the data during storage then that error remains correctable after the reversible alteration is reversed. In certain examples, this is achieved by using each bit of the MAC to guide a very localized transformation where all bits remain within the same correction symbols.

Assuming in a DRAM-based memory system there are <NUM> bits of metadata per <NUM> bits of data, then the Reed-Solomon error correction code could be configured to repair just one <NUM>-bit symbol. This would leave approximately <NUM> bits of integrity check built into the ECC algorithm. Alternatively, with the <NUM> bits of metadata per <NUM> bits of data, the Reed-Solomon error correction code could be configured to repair two <NUM>-bit symbols. This may increase the reliability slightly, but the integrity may fall to approximately <NUM> bits. In a different memory system, assuming there are <NUM> bits of metadata per <NUM> bits of data, then the Reed-Solomon error correction code could be configured to repair just one <NUM>-bit symbol or two <NUM>-bit symbols. If the <NUM>-bit symbol can be corrected, then this may provide "chip kill" fault protection, assuming each chip provides <NUM> bits. Thus, even if the chip completely fails, the data could still be recreated. While Reed-Solomon is a good choice for a DRAM-based memory system and has a good level of rejection of false positives, other ECC technology with strong false positive rejection may also be compatible. The main requirement is that the reversible alteration should not weaken the error correction scheme in the presence of routine physical errors. For example, if the memory system uses Flash memory then the application of the watermark may need to be designed not to disturb error repair algorithms for multilevel cells.

<FIG> shows a diagram of a data path <NUM> for ensuring the integrity of data by using a watermark in accordance with one example. In this example, the operations on the data and other information (e.g., the user key and the address) may be performed using memory controller <NUM> of <FIG>. Data path <NUM> assumes the data size to be <NUM> bits. In addition, it is assumed that the users cannot change their identifier and interact with the memory controller as another user. In this example, it is further assumed that users (e.g., compute entities) may access memory with the following functions: (<NUM>) Write(address A, data D) (writes data D to address A and D is a fixed-length block of data (<NUM> bits in this example)); (<NUM>) Read(address A) (reads data stored at address A); and (<NUM>) Corrupt(address A) (models attacks similar to Row-hammer where a user may introduce random corruptions to the data stored at address A). If a user executes Write(A, D), then Read(A), there may be Read, Write, and Corrupt operations in between, executed by other (possibly malicious) users in the system, affecting address A. Moreover, it is assumed that the users cannot access the data written to a media by the memory controller directly, and thus the memory is only accessible via the Read, Write and Corrupt functions. In addition, in this example, user keys are never exported from memory controller <NUM>. Finally, in this example, it is assumed that the intermediate values computed by the memory controller do not leak (by side-channel attacks or directly). Memory controller <NUM> ensures that a read error is raised signaling corruption of the data if a corrupt operation occurs between writing and reading.

Table <NUM> shows the movement of data and other operations as part of a storage sequence for storing data using memory controller <NUM>.

Table <NUM> shows the movement of data and other operations as part of a load sequence for retrieving data from memory <NUM> of <FIG> using memory controller <NUM> of <FIG>.

<FIG> shows a diagram of another data path <NUM> for ensuring the integrity of data by using a watermark in accordance with one example. Data path <NUM> assumes the data size to be <NUM> bits. In addition, it is assumed that the users cannot change their identifier and interact with the memory controller as another user. In this example, it is further assumed that users (e.g., compute entities) may access memory with the following functions: (<NUM>) Write(address A, data D) (writes data D to address A and D is a fixed-length block of data (<NUM> bits in this example)); (<NUM>) Read(address A) (reads data stored at address A); and (<NUM>) Corrupt(address A): (models attacks similar to Row-hammer where a user may introduce random corruptions to the data stored at address A). If a user executes Write(A, D), then Read(A), there may be Read, Write, and Corrupt operations in between, executed by other (possibly malicious) users in the system, affecting address A. Moreover, it is assumed that the users cannot access the data written to media by the memory controller directly, memory is only accessible via the Read, Write and Corrupt functions. In addition, in this example, user keys are never exported from memory controller <NUM>. Finally, in this example, it is assumed that intermediate values computed by the memory controller do not leak (by side-channel attacks or directly). Memory controller <NUM> ensures that a read error is raised signaling corruption of the data if a corrupt operation occurs between writing and reading.

Table <NUM> shows the movement of data and other operations as part of a storage sequence for storing data using memory controller <NUM> of <FIG>.

Although Tables <NUM>, <NUM>, <NUM>, and <NUM> illustrate the use of a specific cryptographic function as part of the scrambling operation to generate the message authentication code, other techniques described earlier may instead be used. As an example, hash functions (e.g., HMAC (Keyed-Hashing for Message Authentication), KMAC (KECCAK Message Authentication Code) or block ciphers (e.g., Advanced Encryption Standard (AES)-CMAC) may be used. In addition, as noted earlier, apart from the MACs, other keyed cryptographic functions that have a pseudorandom output may also be used. As an example, block ciphers (e.g., Advanced Encryption Standard (AES)-cipher block chaining (CBC) or AES-CTR (Counter block mode)) may be used to encrypt the user key and/or the address and a counter. Although the examples described with respect to <FIG> and <FIG> describe the XOR operation as part of the data paths, other permutations may also be used. As an example, other permutations include rotating the bits or dividing certain bits among groups and using those bits to either leave the bits in the same order as before or reverse the order of the bits. In general, any reversible operation such as an XOR operation may be used for permutations.

<FIG> shows a system environment <NUM> for implementing systems and methods in accordance with one example. In this example, system environment <NUM> may correspond to a portion of a data center. As an example, the data center may include several clusters of racks including platform hardware, such as server nodes, storage nodes, networking nodes, or other types of nodes. Server nodes may be connected to switches to form a network. The network may enable connections between each possible combination of switches. System environment <NUM> may include server1 <NUM> and serverN <NUM>. System environment <NUM> may further include data center related functionality <NUM>, including deployment/monitoring <NUM>, directory/identity services <NUM>, load balancing <NUM>, data center controllers <NUM> (e.g., software defined networking (SDN) controllers and other controllers), and routers/switches <NUM>. Server1 <NUM> may include host processor(s) <NUM>, host hypervisor <NUM>, memory <NUM>, storage interface controller(s) (SIC(s)) <NUM>, cooling <NUM> (e.g., cooling fans or other cooling apparatus), network interface controller(s) (NIC(s)) <NUM>, and storage disks <NUM> and <NUM>. ServerN <NUM> may include host processor(s) <NUM>, host hypervisor <NUM>, memory <NUM>, storage interface controller(s) (SIC(s)) <NUM>, cooling <NUM> (e.g., cooling fans or other cooling apparatus), network interface controller(s) (NIC(s)) <NUM>, and storage disks <NUM> and <NUM>. Server1 <NUM> may be configured to support virtual machines, including VM1 <NUM>, VM2 <NUM>, and VMN <NUM>. The virtual machines may further be configured to support applications, such as APP1 <NUM>, APP2 <NUM>, and APPN <NUM>. ServerN <NUM> may be configured to support virtual machines, including VM1 <NUM>, VM2 <NUM>, and VMN <NUM>. The virtual machines may further be configured to support applications, such as APP1 <NUM>, APP2 <NUM>, and APPN <NUM>.

With continued reference to <FIG>, in one example, system environment <NUM> may be enabled for multiple tenants using the Virtual eXtensible Local Area Network (VXLAN) framework. Each virtual machine (VM) may be allowed to communicate with VMs in the same VXLAN segment. Each VXLAN segment may be identified by a VXLAN Network Identifier (VNI). Although <FIG> shows system environment <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with system environment <NUM> may be distributed or combined, as needed. Moreover, although <FIG> shows VMs, other types of compute entities, such as containers, micro-VMs, microservices, and unikernels for serverless functions, may also be used in a like manner.

<FIG> shows a flowchart <NUM> of a method in accordance with one example. In this example, this method may be performed in a system including a processor and a memory. As an example, this method may be performed as part of a host server <NUM> of <FIG> as part of system environment <NUM> of <FIG>. Step <NUM> may include receiving data for storage at an address in the memory. As an example, as part of step <NUM>, a memory controller (e.g., <NUM> of <FIG>) may receive data from cache <NUM> for storing an address (ADDR) provided by CPU <NUM>. In addition, in one example, the data may be the <NUM> bits of plaintext data described with respect to <FIG> and Table <NUM>.

Step <NUM> may include after encoding the data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a watermark to generate watermarked data for storage in the memory, where the watermark is generated by applying a cryptographic function to a user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits. As an example, a memory controller (e.g., memory controller <NUM> of <FIG>) may perform this step as described with respect to <FIG> and <FIG>. In this example, after encoding the data with an error correction code to generate intermediate data having a first number of bits (e.g., <NUM> bits of which <NUM> bits may be data bits and <NUM> bits may be ECC bits), watermark logic <NUM> of <FIG> may be used to reversibly alter the intermediate data with a watermark (e.g., a MAC) to generate watermarked data for storage in the memory. Example reversible alterations include but are not limited to performing an exclusive OR operation between the watermark and the intermediate data, rotating the intermediate data based on the watermark, and other alterations that are reversible in nature. Additional examples of the MACs and other watermarks are described earlier with respect to <FIG>. Although <FIG> describes flow chart <NUM> as including a certain number of steps being executed in a certain order, the method may include additional or fewer steps executed in a different order. The user may comprise one of a hypervisor, a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions.

<FIG> shows another flowchart <NUM> of a method in accordance with one example. In this example, this method may be performed in a host server including a memory and a processor. As an example, this method may be performed as part of a host server <NUM> of <FIG> as part of system environment <NUM> of <FIG>. Step <NUM> may include receiving plaintext data from one of a plurality of compute entities associated with the host server for storing at an address in the memory. As an example, as part of step <NUM>, a memory controller (e.g., <NUM> of <FIG>) may receive plaintext data from cache <NUM> for storing an address (ADDR) provided by CPU <NUM>. In addition, in one example, the plaintext data may be the <NUM> bits of plaintext data described with respect to <FIG> and Table <NUM>. The compute entity may comprise one of a hypervisor, a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions.

Step <NUM> may include encrypting the plaintext data using at least a user key associated with the compute entity to generate encrypted data. As an example, as part of step <NUM>, a memory controller (e.g., <NUM> of <FIG>) may encrypt the plaintext data as described earlier with respect to <FIG>. In addition, in one example, the encrypted data may be <NUM> bits of encrypted data described earlier with respect to <FIG> and Table <NUM>.

Step <NUM> may include after encoding the encrypted data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a message authentication code to generate watermarked data for storage in the memory, where the message authentication code is generated by applying a cryptographic function to the user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits. As an example, a memory controller (e.g., memory controller <NUM> of <FIG>) may perform this step as described with respect to <FIG> and <FIG>. In this example, after encoding the encrypted data with an error correction code to generate intermediate data having a first number of bits (e.g., <NUM> bits of which <NUM> bits may be data bits and <NUM> bits may be ECC bits), watermark logic <NUM> of <FIG> may be used to reversibly alter the intermediate data with a MAC to generate watermarked data for storage in the memory. Example reversible alterations include, but are not limited, to performing an exclusive OR operation between the MAC and the intermediate data, rotating the intermediate data based on the MAC, and other alterations that are reversible in nature. Additional examples of the MACs and other watermarks are described earlier with respect to <FIG>. Although <FIG> describes flow chart <NUM> as including a certain number of steps being executed in a certain order, the method may include additional steps executed in a different order.

In conclusion, the present disclosure relates to a method in a system including a processor and a memory. The method may include receiving data for storage at an address in the memory. The method may further include after encoding the data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a watermark to generate watermarked data for storage in the memory, where the watermark is generated by applying a cryptographic function to a user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits.

The system may further include a memory controller and the method may further include memory controller generating the user key based on a user identifier associated with a user. The system may further include a hypervisor, and the method may further include the hypervisor assigning the user identifier to the user. The user may comprise one of the hypervisor, a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions.

The intermediate data may further comprise metadata, and the method may further include reversibly altering the intermediate data and the metadata with the watermark.

The method may further include reading the watermarked data from the memory at the address in response to a read operation specifying the address in the memory; recomputing a previously applied watermark to the intermediate data by processing the watermarked data with the user key; and removing the previously applied watermark to generate a second intermediate data. The method may further include decoding the second intermediate data using the error correction code to generate decoded data; and terminating the read operation if the decoding results in an uncorrectable error then.

In yet another aspect, the present disclosure relates to a system including a host server comprising a memory controller coupled to a memory and a processor. The system may further include a hypervisor, associated with the host server, configured to manage a plurality of compute entities. The memory controller may be configured to: (<NUM>) receive data from one of the plurality of compute entities for storing at an address in the memory, and (<NUM>) after encoding the data with an error correction code to generate intermediate data having a first number of bits, reversibly alter the intermediate data with a watermark to generate watermarked data for storage in the memory, where the watermark is generated by applying a cryptographic function to the address, and where the watermarked data has a second number of bits equal to the first number of bits.

The hypervisor may further be configured to assign a user identifier to the compute entity, and where the memory controller may further be configured to generate a user key based on the user identifier associated with the compute entity. The compute entity may comprise one of the hypervisor, a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions. The intermediate data may further comprise metadata, and the memory controller may further be configured to reversibly alter the metadata with the watermark.

The memory controller may further be configured to: read the watermarked data from the memory at the address in response to a read request from the compute entity specifying the address; recompute a previously applied watermark to the intermediate data by processing the watermarked data with the address; and remove the previously applied watermark to generate a second intermediate data. The memory controller may further be configured to: decode the second intermediate data using the error correction code to generate decoded data; and terminate the read request if the decoding results in an uncorrectable error.

In another aspect, the present disclosure relates to a method performed in a host server including a processor and a memory. The method may include receiving plaintext data from one of a plurality of compute entities associated with the host server, for storing at an address in the memory. The method may further include encrypting the plaintext data using at least a user key associated with the compute entity to generate encrypted data. The method may further include after encoding the encrypted data with an error correction code to generate intermediate data having a first number of bits, reversibly altering the intermediate data with a watermark to generate watermarked data for storage in the memory, where the message authentication code is generated by applying a cryptographic function to the user key and the address, and where the watermarked data has a second number of bits equal to the first number of bits.

The system may further comprise a memory controller, and the method may further comprise the memory controller generating the user key based on a user identifier associated with the compute entity. The method may further include a hypervisor associated with the host server assigning the user identifier to the compute entity. The compute entity may comprise one of a hypervisor, a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions. The intermediate data may further comprise metadata, and the method may further comprise reversibly altering the intermediate data and the metadata with the watermark.

The method may further include reading the watermarked data from the memory at the address in response to a read request from the compute entity specifying the address, recomputing a previously applied watermark to the intermediate data by processing the watermarked data with the user key, and removing the previously applied watermark to generate a second intermediate data. The method may further include decoding the second intermediate data using the error correction code to generate decoded data and if the decoding results in an uncorrectable error then terminating the read request otherwise decrypting the decoded data to generate second plaintext data.

It is to be understood that the methods, modules, and components depicted herein are merely exemplary. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or inter-medial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "coupled," to each other to achieve the desired functionality.

The functionality associated with some examples described in this disclosure can also include instructions stored in a non-transitory media. The term "non-transitory media" as used herein refers to any media storing data and/or instructions that cause a machine to operate in a specific manner. Exemplary non-transitory media include non-volatile media and/or volatile media. Non-volatile media include, for example, a hard disk, a solid state drive, a magnetic disk or tape, an optical disk or tape, a flash memory, an EPROM, NVRAM, PRAM, or other such media, or networked versions of such media. Volatile media include, for example, dynamic memory such as DRAM, SRAM, a cache, or other such media. Non-transitory media is distinct from but can be used in conjunction with transmission media. Transmission media is used for transferring data and/or instruction to or from a machine. Exemplary transmission media include coaxial cables, fiber-optic cables, copper wires, and wireless media, such as radio waves.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above described operations are merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

Although the disclosure provides specific examples, various modifications and changes can be made without departing from the scope of the disclosure as set forth in the claims below. Any benefits, advantages, or solutions to problems that are described herein with regard to a specific example are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

Claim 1:
A method in a system (<NUM>, <NUM>, <NUM>) including a processor (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) and a memory (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), the method comprising:
receiving (<NUM>) data for storage at an address in the memory; and
after encoding (<NUM>) the data with an error correction code to generate intermediate data having a first number of bits, reversibly altering (<NUM>) the intermediate data with a watermark to generate watermarked data for storage in the memory, wherein the watermark is generated by applying a cryptographic function to a user key and the address, and wherein the watermarked data has a second number of bits equal to the first number of bits.