Patent Description:
<CIT> relates to a processor including a core to execute an instruction, where the core includes a register to store a pointer to a memory location and a tag associated with the pointer. The tag indicates whether the pointer is at least partially immutable. The core also includes circuitry to access the pointer and the tag associated with the pointer, determine whether the tag indicates that the pointer is at least partially immutable. The circuitry is further, based on a determination that the tag indicates the pointer is at least partially immutable, to obtain a memory address of the memory location based on the pointer, use the memory address to access encrypted data at the memory location, and decrypt the encrypted data based on a key and a tweak, where the tweak including one or more bits based, at least in part, on the pointer.

<CIT> relates to a processor including a decoder, a cache, address translation circuitry, a cache controller, and a memory controller. The decoder is to decode an instruction. The instruction is to specify a first address associated with a data object, the first address having a first memory tag. The address translation circuitry is to translate the first address to a second address, the second address to identify a memory location of the data object. The comparator is to compare the first memory tag and a second memory tag associated with the second address. The cache controller is to detect a cache miss associated with the memory location. The memory controller is to, in response to the comparator detecting a match between the first memory tag and the second memory tag and the cache controller detecting the cache miss, load the data object from the memory location into the cache. Other embodiments include encryption of memory tags together with addresses.

To provide a more complete understanding of the present disclosure and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, where like reference numerals represent like parts, in which:.

This disclosure provides various possible embodiments, or examples, for implementations of memory access instructions that may be used in the context of cryptographic computing. The scope of protection for the invention pursued by this application is limited by the attached claims. Generally, cryptographic computing may refer to computer system security solutions that employ cryptographic mechanisms inside processor components as part of its computation. Some cryptographic computing systems may implement the encryption and decryption of pointer addresses (or portions thereof), keys, data, and code in a processor core using encrypted memory access instructions. Thus, the microarchitecture pipeline of the processor core may be configured in such a way to support such encryption and decryption operations.

Embodiments disclosed in this application are related to proactively blocking out-of-bound accesses to memory while enforcing cryptographic isolation of memory regions within the memory. Cryptographic isolation may refer to isolation resulting from different regions or areas of memory being encrypted with one or more different parameters. Parameters can include keys and/or tweaks. Isolated memory regions can be composed of objects including data structures and/or code of a software entity (e.g., virtual machines (VMs), applications, functions, threads). Thus, isolation can be supported at arbitrary levels of granularity such as, for example, isolation between virtual machines, isolation between applications, isolation between functions, isolation between threads, or isolation between data structures (e.g., few byte structures).

Encryption and decryption operations of data or code associated with a particular memory region may be performed by a cryptographic algorithm using a key associated with that memory region. In at least some embodiments, the cryptographic algorithm may also (or alternatively) use a tweak as input. Generally, parameters such as 'keys' and 'tweaks' are intended to denote input values, which may be secret and/or unique, and which are used by an encryption or decryption process to produce an encrypted output value or decrypted output value, respectively. A key may be a unique value, at least among the memory regions or subregions being cryptographically isolated. Keys may be maintained, e.g., in either processor registers or processor memory (e.g., processor cache, content addressable memory (CAM), etc.) that is accessible through instruction set extensions. A tweak can be derived from an encoded pointer (e.g., security context information embedded therein) to the memory address where data or code being encrypted/decrypted is stored or is to be stored and, in at least some scenarios, can also include security context information associated with the memory region.

At least some embodiments disclosed in this specification, including read and write operations, are related to pointer based data encryption and decryption in which a pointer to a memory location for data or code is encoded with a tag and/or other metadata (e.g., security context information) and may be used to derive at least a portion of tweak input to data or code cryptographic (e.g., encryption and decryption) algorithms. Thus, a cryptographic binding can be created between the cryptographic addressing layer and data/code encryption and decryption. This implicitly enforces bounds since a pointer that strays beyond the end of an object (e.g., data) is likely to use an incorrect tag value for that adjacent object. In one or more embodiments, a pointer is encoded with a linear address (also referred to herein as "memory address") to a memory location and metadata. In some pointer encodings, a slice or segment of the address in the pointer includes a plurality of bits and is encrypted (and decrypted) based on a secret address key and a tweak based on the metadata. Other pointers can be encoded with a plaintext memory address (e.g., linear address) and metadata.

For purposes of illustrating the several embodiments for proactively blocking out-of-bound memory accesses while enforcing cryptographic isolation of memory regions, it is important to first understand the operations and activities associated with data protection and memory safety. Accordingly, the following foundational information may be viewed as a basis from which the present disclosure may be properly explained.

Known computing techniques (e.g., page tables for process/kernel separation, virtual machine managers, managed runtimes, etc.) have used architecture and metadata to provide data protection and isolation. For example, in previous solutions, memory controllers outside the CPU boundary support memory encryption and decryption at a coarser granularity (e.g., applications), and isolation of the encrypted data is realized via access control. Typically, a cryptographic computing engine is placed in a memory controller, which is outside a CPU core. In order to be encrypted, data travels from the core to the memory controller with some identification of which keys should be used for the encryption. This identification is communicated via bits in the physical address. Thus, any deviation to provide additional keys or tweaks could result in increased expense (e.g., for new buses) or additional bits being "stolen" from the address bus to allow additional indexes or identifications for keys or tweaks to be carried with the physical address. Access control can require the use of metadata and a processor would use lookup tables to encode policy or data about the data for ownership, memory size, location, type, version, etc. Dynamically storing and loading metadata requires additional storage (memory overhead) and impacts performance, particularly for fine grain metadata (such as for function as a service (FaaS) workloads or object bounds information).

Cryptographic isolation of memory compartments (also referred to herein as 'memory regions'), resolves many of the aforementioned issues (and more). Cryptographic isolation may make redundant the legacy modes of process separation, user space, and kernel with a fundamentally new fine-grain protection model. With cryptographic isolation of memory compartments, protections are cryptographic, with various types of processor units (e.g., processors, accelerators, data processing units, field programmable gate arrays, etc.) alike utilizing secret keys (and optionally tweaks) and ciphers to provide access control and separation at increasingly finer granularities. Indeed, isolation can be supported for memory compartments as small as a one-byte object to as large as data and code for an entire virtual machine. In at least some scenarios, cryptographic isolation may result in individual applications or functions becoming the boundary, allowing each address space to contain multiple distinct applications or functions. Objects can be selectively shared across isolation boundaries via pointers. These pointers can be cryptographically encoded or non-cryptographically encoded. Furthermore, in one or more embodiments, encryption and decryption happens inside the processor core, within the core boundary. Because encryption happens before data is written to a memory unit outside the core, such as the L1 cache or main memory, it is not necessary to "steal" bits from the physical address to convey key or tweak information, and an arbitrarily large number of keys and/or tweaks can be supported.

Cryptographic isolation leverages the concept of a cryptographic addressing layer where the processor encrypts at least a portion of software allocated memory addresses (addresses within the linear/virtual address space, also referred to as "pointers") based on implicit and/or explicit metadata (e.g., context information) and/or a slice of the memory address itself (e.g., as a tweak to a tweakable block cipher (e.g., XOR-encrypt-XOR-based tweaked-codebook mode with ciphertext stealing (XTS)). As used herein, a "tweak" may refer to, among other things, an extra input to a block cipher, in addition to the usual plaintext or ciphertext input and the key. A tweak comprises one or more bits that represent a value. In one or more embodiments, a tweak may compose all or part of an initialization vector (IV) for a block cipher. A resulting cryptographically encoded pointer can comprise an encrypted portion (or slice) of the memory address and some bits of encoded metadata (e.g., context information). When decryption of an address is performed, if the information used to create the tweak (e.g., implicit and/or explicit metadata, plaintext address slice of the memory address, etc.) corresponds to the original allocation of the memory address by a memory allocator (e.g., software allocation method), then the processor can correctly decrypt the address. Otherwise, a random address result will cause a fault and get caught by the processor.

These cryptographically encoded pointers (or portions thereof) may be further used by the processor as a tweak to the data encryption cipher used to encrypt/decrypt data they refer to (data referenced by the cryptographically encoded pointer), creating a cryptographic binding between the cryptographic addressing layer and data/code encryption. In some embodiments, the cryptographically encoded pointer may be decrypted and decoded to obtain the linear address. The linear address (or a portion thereof) may be used by the processor as a tweak to the data encryption cipher. Alternatively, in some embodiments, the memory address may not be encrypted but the pointer may still be encoded with some metadata representing a unique value among pointers. In this embodiment, the encoded pointer (or a portion thereof) may be used by the processor as a tweak to the data encryption cipher. It should be noted that a tweak that is used as input to a block cipher to encrypt/decrypt a memory address is also referred to herein as an "address tweak". Similarly, a tweak that is used as input to a block cipher to encrypt/decrypt data is also referred to herein as a "data tweak".

Although the cryptographically encoded pointer (or non-cryptographically encoded pointers) can be used to isolate data, via encryption, the integrity of the data may still be vulnerable. For example, unauthorized access of cryptographically isolated data can corrupt the memory region where the data is stored regardless of whether the data is encrypted, corrupting the data contents unbeknownst to the victim. Data integrity may be supported using an integrity verification (or checking) mechanism such as message authentication codes (MACs) or implicitly based on an entropy measure of the decrypted data, or both. In one example, MAC codes may be stored per cache line and evaluated each time the cache line is read to determine whether the data has been corrupted. Such mechanisms, however, do not proactively detect unauthorized memory accesses. Instead, corruption of memory (e.g., out-of-bounds access) may be detected in a reactive manner (e.g., after the data is written) rather than a proactive manner (e.g., before the data is written). For example, memory corruption may occur by a write operation performed at a memory location that is out-of-bounds for the software entity. With cryptographic computing, the write operation may use a key and/or a tweak that is invalid for the memory location. When a subsequent read operation is performed at that memory location, the read operation may use a different key on the corrupted memory and detect the corruption. For example, if the read operation uses the valid key and/or tweak), then the retrieved data will not decrypt properly and the corruption can be detected using a message authentication code, for example, or by detecting a high level of entropy (randomness) in the decrypted data (implicit integrity).

Turning to <FIG> is a simplified block diagram of an example computing device <NUM> for implementing a proactive blocking technique for out-of-bound accesses to memory while enforcing cryptographic isolation of memory regions using secure memory access logic according to at least one embodiment of the present disclosure. In the example shown, the computing device <NUM> includes a processor <NUM> with an address cryptography unit <NUM>, a cryptographic computing engine <NUM>, secure memory access logic <NUM>, and memory components, such as a cache <NUM> (e.g., L1 cache, L2 cache) and supplemental processor memory <NUM>. Secure memory access logic <NUM> includes encryption store logic <NUM> to encrypt data based on various keys and/or tweaks and then store the encrypted data and decryption load logic <NUM> to read and then decrypt data based on the keys and/or tweaks. Cryptographic computing engine <NUM> may be configured to decrypt data or code for load operations based on various keys and/or tweaks and to encrypt data or code for store operations based on various keys and/or tweaks. Address cryptography unit <NUM> may be configured to decrypt and encrypt a linear address (or a portion of the linear address) encoded in a pointer to the data or code referenced by the linear address.

Processor <NUM> also includes registers <NUM>, which may include e.g., general purpose registers and special purpose registers (e.g., control registers, model-specific registers (MSRs), etc.). Registers <NUM> may contain various data that may be used in one or more embodiments, such as an encoded pointer <NUM> to a memory address. The encoded pointer may be cryptographically encoded or non-cryptographically encoded. An encoded pointer is encoded with some metadata. If the encoded pointer is cryptographically encoded, at least a portion (or slice) of the address bits is encrypted. In some embodiments, keys <NUM> used for encryption and decryption of addresses, code, and/or data may be stored in registers <NUM>. In some embodiments, tweaks <NUM> used for encryption and decryption of addresses, code, and/or data may be stored in registers <NUM>.

The secure memory access logic <NUM> utilizes metadata about encoded pointer <NUM>, which is encoded into unused bits of the encoded pointer <NUM> (e.g., non-canonical bits of a <NUM>-bit address, or a range of addresses set aside, e.g., by the operating system, such that the corresponding high order bits of the address range may be used to store the metadata), in order to secure and/or provide access control to memory locations pointed to by the encoded pointer <NUM>. For example, the metadata encoding and decoding provided by the secure memory access logic <NUM> can prevent the encoded pointer <NUM> from being manipulated to cause a buffer overflow, and/or can prevent program code from accessing memory that it does not have permission to access. Pointers may be encoded when memory is allocated (e.g., by an operating system, in the heap) and provided to executing programs in any of a number of different ways, including by using a function such as malloc, alloc, or new; or implicitly via the loader, or statically allocating memory by the compiler, etc. As a result, the encoded pointer <NUM>, which points to the allocated memory, is encoded with the address metadata.

The address metadata can include valid range metadata. The valid range metadata allows executing programs to manipulate the value of the encoded pointer <NUM> within a valid range, but will corrupt the encoded pointer <NUM> if the memory is accessed using the encoded pointer <NUM> beyond the valid range. Alternatively or in addition, the valid range metadata can be used to identify a valid code range, e.g., a range of memory that program code is permitted to access (e.g., the encoded range information can be used to set explicit ranges on registers). Other information that can be encoded in the address metadata includes access (or permission) restrictions on the encoded pointer <NUM> (e.g., whether the encoded pointer <NUM> can be used to write, execute, or read the referenced memory).

In at least some other embodiments, other metadata (or context information) can be encoded in the unused bits of encoded pointer <NUM> such as a size of plaintext address slices (e.g., number of bits in a plaintext slice of a memory address embedded in the encoded pointer), a memory allocation size (e.g., bytes of allocated memory referenced by the encoded pointer), a type of the data or code (e.g., class of data or code defined by programming language), permissions (e.g., read, write, and execute permissions of the encoded pointer), a location of the data or code (e.g., where the data or code is stored), the memory location where the pointer itself is to be stored, an ownership of the data or code, a version of the encoded pointer (e.g., a sequential number that is incremented each time an encoded pointer is created for newly allocated memory, determines current ownership of the referenced allocated memory in time), a tag of randomized bits (e.g., generated for association with the encoded pointer), a privilege level (e.g., user or supervisor), a cryptographic context identifier (or crypto context ID) (e.g., randomized or deterministically unique value for each encoded pointer), etc. For example, in one embodiment, the address metadata can include size metadata that encodes the size of a plaintext address slice in the encoded pointer. The size metadata may specify a number of lowest order bits in the encoded pointer that can be modified by the executing program. The size metadata is dependent on the amount of memory requested by a program. Accordingly, if <NUM> bytes are requested, then size metadata is encoded as <NUM> (or <NUM> in five upper bits of the pointer) and the <NUM> lowest bits of the pointer are designated as modifiable bits to allow addressing to the requested <NUM> bytes of memory. In some embodiments, the address metadata may include a tag of randomized bits associated with the encoded pointer to make the tag unpredictable for an adversary. An adversary may try to guess the tag value so that the adversary is able to access the memory referenced by the pointer, and randomizing the tag value may make it less likely that the adversary will successfully guess the value compared to a deterministic approach for generating a version value. In some embodiments, the pointer may include a version number (or other deterministically different value) determining current ownership of the referenced allocated data in time instead of or in addition to a randomized tag value. Even if an adversary is able to guess the current tag value or version number for a region of memory, e.g., because the algorithm for generating the version numbers is predictable, the adversary may still be unable to correctly generate the corresponding encrypted portion of the pointer due to the adversary not having access to the key that will later be used to decrypt that portion of the pointer.

The example secure memory access logic <NUM> is embodied as part of processor instructions (e.g., as part of the processor instruction set architecture), or microcode (e.g., instructions that are stored in read-only memory and executed directly by the processor <NUM>). In other embodiments, portions of the secure memory access logic <NUM> may be embodied as hardware, firmware, software, or a combination thereof (e.g., as programming code executed by a privileged system component <NUM> of the computing device <NUM>). In one example, decryption load logic <NUM> and encryption store logic <NUM> are embodied as part of new load (read) and store (write) processor instructions that perform respective decryption and encryption operations to isolate memory compartments. Decryption load logic <NUM> and encryption store logic <NUM> verify encoded metadata on memory read and write operations that utilize the new processor instructions (e.g., which may be counterparts to existing processor instructions such as MOV), where a general purpose register is used as a memory address to read a value from memory (e.g., load) or to write a value to memory (e.g., store).

The secure memory access logic <NUM> is executable by the computing device <NUM> to provide security for encoded pointers "inline," e.g., during execution of a program (such as a user space application <NUM>) by the computing device <NUM>. As used herein, the terms "indirect address" and "pointer" may each refer to, among other things, an address (e.g., virtual address or linear address) of a memory location at which other data or instructions are stored. In an example, a register that stores an encoded memory address of a memory location where data or code is stored may act as a pointer. As such, the encoded pointer <NUM> may be embodied as, for example, a data pointer (which refers to a location of data), a code pointer (which refers to a location of executable code), an instruction pointer, or a stack pointer. As used herein, "context information" includes "metadata" and may refer to, among other things, information about or relating to an encoded pointer <NUM>, such as a valid data range, a valid code range, pointer access permissions, a size of plaintext address slice (e.g., encoded as a power in bits), a memory allocation size, a type of the data or code, a location of the data or code, an ownership of the data or code, a version of the pointer, a tag of randomized bits, version, a privilege level of software, a cryptographic context identifier, etc..

As used herein, "memory access instruction" may refer to, among other things, a "MOV" or "LOAD" instruction or any other instruction that causes data to be read, copied, or otherwise accessed at one storage location, e.g., memory, and moved into another storage location, e.g., a register (where "memory" may refer to main memory or cache, e.g., a form of random access memory, and "register" may refer to a processor register, e.g., hardware), or any instruction that accesses or manipulates memory. Also as used herein, "memory access instruction" may refer to, among other things, a "MOV" or "STORE" instruction or any other instruction that causes data to be read, copied, or otherwise accessed at one storage location, e.g., a register, and moved into another storage location, e.g., memory, or any instruction that accesses or manipulates memory.

The address cryptography unit <NUM> can include logic (including circuitry) to perform address decoding of an encoded pointer to obtain a linear address of a memory location of data (or code). The address decoding can include decryption if needed (e.g., if the encoded pointer includes an encrypted portion of a linear address) based at least in part on a key and/or on a tweak derived from the encoded pointer. The address cryptography unit <NUM> can also include logic (including circuitry) to perform address encoding of the encoded pointer, including encryption if needed (e.g., the encoded pointer includes an encrypted portion of a linear address), based at least in part on the same key and/or on the same tweak used to decode the encoded pointer. Address encoding may also include storing metadata in the noncanonical bits of the pointer. Various operations such as address encoding and address decoding (including encryption and decryption of the address or portions thereof) may be performed by processor instructions associated with address cryptography unit <NUM>, other processor instructions, or a separate instruction or series of instructions, or a higher-level code executed by a privileged system component such as an operating system kernel or virtual machine monitor, or as an instruction set emulator. As described in more detail below, address encoding logic and address decoding logic each operate on an encoded pointer <NUM> using metadata (e.g., one or more of valid range, permission metadata, size (power), memory allocation size, type, location, ownership, version, tag value, privilege level (e.g., user or supervisor), crypto context ID, etc.) and a secret key (e.g., keys <NUM>), in order to secure the encoded pointer <NUM> at the memory allocation/access level.

The encryption store logic <NUM> and decryption load logic <NUM> can use cryptographic computing engine <NUM> to perform cryptographic operations on data to be stored at a memory location referenced by encoded pointer <NUM> or obtained from a memory location referenced by encoded pointer <NUM>. The cryptographic computing engine <NUM> can include logic (including circuitry) to perform data (or code) decryption based at least in part on a tweak derived from an encoded pointer to a memory location of the data (or code), and to perform data (or code) encryption based at least in part on a tweak derived from an encoded pointer to a memory location for the data (or code). The cryptographic operations of the engine <NUM> may use a tweak, which includes at least a portion of the encoded pointer <NUM> (or the linear address generated from the encoded pointer) and/or a secret key (e.g., keys <NUM>) in order to secure the data or code at the memory location referenced by the encoded pointer <NUM> by binding the data/code encryption and decryption to the encoded pointer.

Various different cryptographic algorithms may be used to implement the address cryptography unit <NUM> and cryptographic computing engine <NUM>. Generally, Advanced Encryption Standard (AES) has been the mainstay for data encryption for decades, using a 128bit block cipher. Meanwhile, memory addressing is typically 64bits today. Although embodiments herein may be illustrated and explained with reference to <NUM>-bit memory addressing for <NUM> computers, the disclosed embodiments are not intended to be so limited and can easily be adapted to accommodate 32bits, 128bits, or any other available bit sizes for pointers. Likewise, embodiments herein may further be adapted to accommodate various sizes of a block cipher (e.g., 64bit, 48bit, 32bit, 16bit, etc. using Simon, Speck, tweakable K-cipher, PRINCE or any other block cipher).

Lightweight ciphers suitable for pointer-based encryption have also emerged recently. The PRINCE cipher, for example, can be implemented in <NUM> clocks requiring as little as <NUM><NUM> of area in the <NUM> process, providing half the latency of AES in a tenth the Silicon area. Cryptographic isolation may utilize these new ciphers, as well as others, introducing novel computer architecture concepts including, but not limited to: (i) cryptographic addressing, i.e., the encryption of data pointers at the processor using, as tweaks, contextual information about the referenced data (e.g., metadata embedded in the pointer and/or external metadata), a slice of the address itself, or any suitable combination thereof; and (ii) encryption of the data itself at the core, using cryptographically encoded pointers or portions thereof, non-cryptographically encoded pointers or portion(s) thereof, contextual information about the referenced data, or any suitable combination thereof as tweaks for the data encryption. A variety of encryption modes that are tweakable can be used for this purpose of including metadata (e.g., counter mode (CTR) and XOR-encrypt-XOR (XEX)-based tweaked-codebook mode with ciphertext stealing (XTS)). In addition to encryption providing data confidentiality, its implicit integrity may allow the processor to determine if the data is being properly decrypted using the correct keystream and tweak. In some block cipher encryption modes, the block cipher creates a keystream, which is then combined (e.g., using XOR operation or other more complex logic) with an input block to produce the encrypted or decrypted block. In some block ciphers, the keystream is fed into the next block cipher to perform encryption or decryption.

The example encoded pointer <NUM> in <FIG> is embodied as a register <NUM> (e.g., a general purpose register of the processor <NUM>). The example secret keys <NUM> may be generated by a key creation module <NUM> of a privileged system component <NUM>, and stored in one of the registers <NUM> (e.g., a special purpose register or a control register such as a model specific register (MSR)), another memory location that is readable by the processor <NUM> (e.g., firmware, a secure portion of a data storage device <NUM>, etc.), in external memory, or another form of memory suitable for performing the functions described herein. In some embodiments, tweaks for encrypting addresses, data, or code may be computed in real time for the encryption or decryption. Tweaks <NUM> may be stored in registers <NUM>, another memory location that is readable by the processor <NUM> (e.g., firmware, a secure portion of a data storage device <NUM>, etc.), in external memory, or another form of memory suitable for performing the functions described herein. In some embodiments, the secret keys <NUM> and/or tweaks <NUM> are stored in a location that is readable only by the processor, such as supplemental processor memory <NUM>. In at least one embodiment, the supplemental processor memory <NUM> may be implemented as a new cache or content addressable memory (CAM). In one or more implementations, supplemental processor memory <NUM> may be used to store information related to cryptographic isolation such as keys and potentially tweaks, credentials, and/or context IDs.

Secret keys may also be generated and associated with cryptographically encoded pointers for encrypting/decrypting the address portion (or slice) encoded in the pointer. These keys may be the same as or different than the keys associated with the pointer to perform data (or code) encryption/decryption operations on the data (or code) referenced by the cryptographically encoded pointer. For ease of explanation, the terms "secret address key" or "address key" may be used to refer to a secret key used in encryption and decryption operations of memory addresses and the terms "secret data key" or "data key" may be used to refer to a secret key used in operations to encrypt and decrypt data or code.

On (or during) a memory allocation operation (e.g., a "malloc"), memory allocation logic <NUM> allocates a range of memory for a buffer, returns a pointer along with the metadata (e.g., one or more of range, permission metadata, size (power), memory allocation size, type, location, ownership, version, tag, privilege level, crypto context ID, etc.). In one example, the memory allocation logic <NUM> may encode plaintext range information in the encoded pointer <NUM> (e.g., in the unused/non-canonical bits, prior to encryption), or supply the metadata as one or more separate parameters to the instruction, where the parameter(s) specify the range, code permission information, size (power), memory allocation size, type, location, ownership, version, tag, privilege level (e.g., user or supervisor), crypto context ID, or some suitable combination thereof. Illustratively, the memory allocation logic <NUM> may be embodied in a memory manager module <NUM> of the privileged system component <NUM>. The memory allocation logic <NUM> causes the pointer <NUM> to be encoded with the metadata (e.g., range, permission metadata, size (power), memory allocation size, type, location, ownership, version, tag value, privilege level, crypto context ID, some suitable combination thereof, etc.). The metadata may be stored in an unused portion of the encoded pointer <NUM> (e.g., non-canonical bits of a <NUM>-bit address). For some metadata or combinations of metadata, the pointer <NUM> may be encoded in a larger address space (e.g., <NUM>-bit address, <NUM>-bit address) to accommodate the size of the metadata or combination of metadata.

To determine valid range metadata, example range rule logic selects the valid range metadata to indicate an upper limit for the size of the buffer referenced by the encoded pointer <NUM>. Address adjustment logic adjusts the valid range metadata as needed so that the upper address bits (e.g., most significant bits) of the addresses in the address range do not change as long as the encoded pointer <NUM> refers to a memory location that is within the valid range indicated by the range metadata. This enables the encoded pointer <NUM> to be manipulated (e.g., by software performing arithmetic operations, etc.) but only so long as the manipulations do not cause the encoded pointer <NUM> to go outside the valid range (e.g., overflow the buffer).

In an embodiment, the valid range metadata is used to select a portion (or slice) of the encoded pointer <NUM> to be encrypted. In other embodiments, the slice of the encoded pointer <NUM> to be encrypted may be known a priori (e.g., upper <NUM> bits, lower <NUM> bits, etc.). The selected slice of the encoded pointer <NUM> (and the adjustment, in some embodiments) is encrypted using a secret address key (e.g., keys <NUM>) and optionally, an address tweak, as described further below. On a memory access operation (e.g., a read, write, or execute operation), the previously-encoded pointer <NUM> is decoded. To do this, the encrypted slice of the encoded pointer <NUM> (and in some embodiments, the encrypted adjustment) is decrypted using a secret address key (e.g., keys <NUM>) and an address tweak (if the address tweak was used in the encryption), as described further below.

The encoded pointer <NUM> is returned to its original (e.g., canonical) form, based on appropriate operations in order to restore the original value of the encoded pointer <NUM> (e.g., the true, original linear memory address). To do this in at least one possible embodiment, the address metadata encoded in the unused bits of the encoded pointer <NUM> are removed (e.g., return the unused bits to their original form). If the encoded pointer <NUM> decodes successfully, the memory access operation completes successfully. However, if the encoded pointer <NUM> has been manipulated (e.g., by software, inadvertently or by an attacker) so that its value falls outside the valid range indicated by the range metadata (e.g., overflows the buffer), the encoded pointer <NUM> may be corrupted as a result of the decrypting process performed on the encrypted address bits in the pointer. A corrupted pointer will raise a fault (e.g., a general protection fault or a page fault if the address is not mapped as present from the paging structures/page tables). One condition that may lead to a fault being generated is a sparse address space. In this scenario, a corrupted address is likely to land on an unmapped page and generate a page fault. Even if the corrupted address lands on a mapped page, it is highly likely that the authorized tweak or initialization vector for that memory region is different from the corrupted address that may be supplied as a tweak or initialization vector in this case. In this way, the computing device <NUM> provides encoded pointer security against buffer overflow attacks and similar exploits.

Referring now in more detail to <FIG>, the computing device <NUM> may be embodied as any type of electronic device for performing the functions described herein. For example, the computing device <NUM> may be embodied as, without limitation, a smart phone, a tablet computer, a wearable computing device, a laptop computer, a notebook computer, a mobile computing device, a cellular telephone, a handset, a messaging device, a vehicle telematics device, a server computer, a workstation, a distributed computing system, a multiprocessor system, a consumer electronic device, and/or any other computing device configured to perform the functions described herein. As shown in <FIG>, the example computing device <NUM> includes at least one processor <NUM> embodied with the secure memory access logic <NUM>, the address cryptography unit <NUM>, and the cryptographic computing engine <NUM>.

The computing device <NUM> also includes memory <NUM>, an input/output subsystem <NUM>, a data storage device <NUM>, a display device <NUM>, a user interface (UI) subsystem <NUM>, a communication subsystem <NUM>, application <NUM>, and the privileged system component <NUM> (which, illustratively, includes memory manager module <NUM> and key creation module <NUM>). The computing device <NUM> may include other or additional components, such as those commonly found in a mobile and/or stationary computers (e.g., various sensors and input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the example components may be incorporated in, or otherwise form a portion of, another component. Each of the components of the computing device <NUM> may be embodied as software, firmware, hardware, or a combination of software and hardware.

The processor <NUM> may be embodied as any type of processor capable of performing the functions described herein. For example, the processor <NUM> may be embodied as a single or multi-core central processing unit (CPU), a multiple-CPU processor or processing/controlling circuit, or multiple diverse processing units or circuits (e.g., CPU and Graphics Processing Unit (GPU), etc.).

Processor memory may be provisioned inside a core and outside the core boundary. For example, registers <NUM> may be included within the core and may be used to store encoded pointers (e.g., <NUM>), secret keys <NUM> and possibly tweaks <NUM> for encryption and decryption of data or code and addresses. Processor <NUM> may also include cache <NUM>, which may be L1 and/or L2 cache for example, where data is stored when it is retrieved from memory <NUM> in anticipation of being fetched by processor <NUM>.

The processor may also include supplemental processor memory <NUM> outside the core boundary. Supplemental processor memory <NUM> may be a dedicated cache that is not directly accessible by software. In one or more embodiments, supplemental processor memory <NUM> may store the mapping <NUM> between parameters and their associated memory regions. For example, keys may be mapped to their corresponding memory regions in the mapping <NUM>. In some embodiments, tweaks that are paired with keys may also be stored in the mapping <NUM>. In other embodiments, the mapping <NUM> may be managed by software.

Generally, keys and tweaks can be handled in any suitable manner based on particular needs and architecture implementations. In a first embodiment, both keys and tweaks may be implicit, and thus are managed by a processor. In this embodiment, the keys and tweaks may be generated internally by the processor or externally by a secure processor. In a second embodiment, both the keys and the tweaks are explicit, and thus are managed by software. In this embodiment, the keys and tweaks are referenced at instruction invocation time using instructions that include operands that reference the keys and tweaks. The keys and tweaks may be stored in registers or memory in this embodiment. In a third embodiment, the keys may be managed by a processor, while the tweaks may be managed by software.

The memory <NUM> of the computing device <NUM> may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. Volatile memory is a storage medium that requires power to maintain the state of data stored by the medium. Examples of volatile memory may include various types of random access memory (RAM), such as dynamic random access memory (DRAM) or static random access memory (SRAM). One particular type of DRAM that may be used in memory is synchronous dynamic random access memory (SDRAM). In particular embodiments, DRAM of memory <NUM> complies with a standard promulgated by the Joint Electron Device Engineering Council (JEDEC), such as JESD79F for Double Data Rate (DDR) SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, or JESD79-4A for DDR4 SDRAM (these standards are available at www. Non-volatile memory is a storage medium that does not require power to maintain the state of data stored by the medium. Nonlimiting examples of nonvolatile memory may include any or a combination of: solid state memory (such as planar or 3D NAND flash memory or NOR flash memory), 3D crosspoint memory, memory devices that use chalcogenide phase change material (e.g., chalcogenide glass), byte addressable nonvolatile memory devices, ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, polymer memory (e.g., ferroelectric polymer memory), ferroelectric transistor random access memory (Fe-TRAM) ovonic memory, nanowire memory, electrically erasable programmable read-only memory (EEPROM), other various types of non-volatile random access memories (RAMs), and magnetic storage memory.

In some embodiments, memory <NUM> comprises one or more memory modules, such as dual in-line memory modules (DIMMs). In some embodiments, the memory <NUM> may be located on one or more integrated circuit chips that are distinct from an integrated circuit chip comprising processor <NUM> or may be located on the same integrated circuit chip as the processor <NUM>. Memory <NUM> may comprise any suitable type of memory and is not limited to a particular speed or technology of memory in various embodiments.

In operation, the memory <NUM> may store various data and code used during operation of the computing device <NUM>, as well as operating systems, applications, programs, libraries, and drivers. Memory <NUM> may store data and/or code, which includes sequences of instructions that are executed by the processor <NUM>.

The memory <NUM> is communicatively coupled to the processor <NUM>, e.g., via the I/O subsystem <NUM>. The I/O subsystem <NUM> may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, the memory <NUM>, and other components of the computing device <NUM>. For example, the I/O subsystem <NUM> may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, 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 to facilitate the input/output operations. In some embodiments, the I/O subsystem <NUM> may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor <NUM>, the memory <NUM>, and/or other components of the computing device <NUM>, on a single integrated circuit chip.

The data storage device <NUM> may be embodied as any type of physical device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, flash memory or other read-only memory, memory devices that are combinations of read-only memory and random access memory, or other data storage devices. In various embodiments, memory <NUM> may cache data that is stored on data storage device <NUM>.

The display device <NUM> may be embodied as any type of display capable of displaying digital information such as a liquid crystal display (LCD), a light emitting diode (LED), a plasma display, a cathode ray tube (CRT), or other type of display device. In some embodiments, the display device <NUM> may be coupled to a touch screen or other human computer interface device to allow user interaction with the computing device <NUM>. The display device <NUM> may be part of the user interface (UI) subsystem <NUM>. The user interface subsystem <NUM> may include a number of additional devices to facilitate user interaction with the computing device <NUM>, including physical or virtual control buttons or keys, a microphone, a speaker, a unidirectional or bidirectional still and/or video camera, and/or others. The user interface subsystem <NUM> may also include devices, such as motion sensors, proximity sensors, and eye tracking devices, which may be configured to detect, capture, and process various other forms of human interactions involving the computing device <NUM>.

The computing device <NUM> further includes a communication subsystem <NUM>, which may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the computing device <NUM> and other electronic devices. The communication subsystem <NUM> may be configured to use any one or more communication technology (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth™, Wi-Fi™, WiMAX, <NUM>/LTE, etc.) to effect such communication. The communication subsystem <NUM> may be embodied as a network adapter, including a wireless network adapter.

The example computing device <NUM> also includes a number of computer program components, such as one or more user space applications (e.g., application <NUM>) and the privileged system component <NUM>. The user space application may be embodied as any computer application (e.g., software, firmware, hardware, or a combination thereof) that interacts directly or indirectly with an end user via, for example, the display device <NUM> or the UI subsystem <NUM>. Some examples of user space applications include word processing programs, document viewers/readers, web browsers, electronic mail programs, messaging services, computer games, camera and video applications, etc. Among other things, the privileged system component <NUM> facilitates the communication between the user space application (e.g., application <NUM>) and the hardware components of the computing device <NUM>. Portions of the privileged system component <NUM> may be embodied as any operating system capable of performing the functions described herein, such as a version of WINDOWS by Microsoft Corporation, ANDROID by Google, Inc. , and/or others. Alternatively or in addition, a portion of the privileged system component <NUM> may be embodied as any type of virtual machine monitor capable of performing the functions described herein (e.g., a type I or type II hypervisor).

The example privileged system component <NUM> includes key creation module <NUM>, which may be embodied as software, firmware, hardware, or a combination of software and hardware. For example, the key creation module <NUM> may be embodied as a module of an operating system kernel, a virtual machine monitor, or a hypervisor. The key creation module <NUM> creates the secret keys <NUM> (e.g., secret address keys and secret data keys) and may write them to a register or registers to which the processor <NUM> has read access (e.g., a special purpose register). To create a secret key, the key creation module <NUM> may execute, for example, a random number generator or another algorithm capable of generating a secret key that can perform the functions described herein. In other implementations, secret keys may be written to supplemental processor memory <NUM> that is not directly accessible by software. In yet other implementations, secret keys may be encrypted and stored in memory <NUM>. In one or more embodiments, when a data key is generated for a memory region allocated to a particular software entity the data key may be encrypted, and the software entity may be provided with the encrypted data key, a pointer to the encrypted data key, or a data structure including the encrypted key or pointer to the encrypted data key. In other implementations, the software entity may be provided with a pointer to the unencrypted data key stored in processor memory or a data structure including a pointer to the unencrypted data key. Generally, any suitable mechanism for generating, storing, and providing secure keys to be used for encrypting and decrypting data (or code) and to be used for encrypting and decrypting memory addresses (or portions thereof) encoded in pointers may be used in embodiments described herein.

It should be noted that a myriad of approaches could be used to generate or obtain a key for embodiments disclosed herein. For example, although the key creation module <NUM> is shown as being part of computing device <NUM>, one or more secret keys could be obtained from any suitable external source using any suitable authentication processes to securely communicate the key to computing device <NUM>, which may include generating the key as part of those processes. Furthermore, privileged system component <NUM> may be part of a trusted execution environment (TEE), virtual machine, processor <NUM>, a co-processor, or any other suitable hardware, firmware, or software in computing device <NUM> or securely connected to computing device <NUM>. Moreover, the key may be "secret", which is intended to mean that its value is kept hidden, inaccessible, obfuscated, or otherwise secured from unauthorized actors (e.g., software, firmware, machines, extraneous hardware components, and humans).

<FIG> is a simplified flow diagram illustrating a general process 200A of cryptographic computing based on embodiments of an encoded pointer <NUM>. Process 200A illustrates storing (e.g., writing) data to a memory region at a memory address indicated by encoded pointer <NUM>, where encryption and decryption of the data is bound to the contents of the pointer according to at least one embodiment. At least some portions of process 200A may be executed by hardware, firmware, and/or software of the computing device <NUM>. In the example shown, pointer <NUM> is an example of encoded pointer <NUM> and is embodied as an encoded linear address including a metadata portion. The metadata portion is some type of context information (e.g., size/power metadata, tag, version, etc.) and the linear address may be encoded in any number of possible configurations, at least some of which are described herein.

Encoded pointer <NUM> may have various configurations according to various embodiments. For example, encoded pointer <NUM> may be encoded with a plaintext linear address or may be encoded with some plaintext linear address bits and some encrypted linear address bits. Encoded pointer <NUM> may also be encoded with different metadata depending on the particular embodiment. For example, metadata encoded in encoded pointer <NUM> may include, but is not necessarily limited to, one or more of size/power metadata, a tag value, or a version number.

Generally, process 200A illustrates a cryptographic computing flow in which the encoded pointer <NUM> is used to obtain a memory address for a memory region of memory <NUM> where data is to be stored, and to encrypt the data to be stored based, at least in part, on a tweak derived from the encoded pointer <NUM>. First, address cryptography unit <NUM> decodes the encoded pointer <NUM> to obtain a decoded linear address <NUM>. The decoded linear address <NUM> may be used to obtain a physical address <NUM> in memory <NUM> using a translation lookaside buffer <NUM> or page table (not shown). A data tweak <NUM> is derived, at least in part, from the encoded pointer <NUM>. For example, the data tweak <NUM> may include the entire encoded pointer, one or more portions of the encoded pointer, a portion of the decoded linear address, the entire decoded linear address, encoded metadata, and/or external context information (e.g., context information that is not encoded in the pointer).

Once the tweak <NUM> has been derived from encoded pointer <NUM>, a cryptographic computing engine <NUM> can compute encrypted data <NUM> by encrypting unencrypted data <NUM> based on a data key <NUM> and the data tweak <NUM>. In at least one embodiment, the cryptographic computing engine <NUM> includes an encryption algorithm such as a keystream generator, which may be embodied as an AES-CTR mode block cipher <NUM>, at a particular size granularity (any suitable size). In this embodiment, the data tweak <NUM> may be used as an initialization vector (IV) and a plaintext offset of the encoded pointer <NUM> may be used as the counter value (CTR). The keystream generator can encrypt the data tweak <NUM> to produce a keystream <NUM> and then a cryptographic operation (e.g., a logic function <NUM> such as an exclusive-or (XOR), or other more complex operations) can be performed on the unencrypted data <NUM> and the keystream <NUM> in order to generate encrypted data <NUM>. It should be noted that the generation of the keystream <NUM> may commence while the physical address <NUM> is being obtained from the encoded pointer <NUM>. Thus, the parallel operations may increase the efficiency of encrypting the unencrypted data. It should be noted that the encrypted data may be stored to cache (e.g., <NUM>) before or, in some instances instead of, being stored to memory <NUM>.

<FIG> is a simplified flow diagram illustrating a general process 200B of cryptographic computing based on embodiments of encoded pointer <NUM>. Process 200B illustrates obtaining (e.g., reading, loading, fetching) data stored in a memory region at a memory address that is referenced by encoded pointer <NUM>, where encryption and decryption of the data is bound to the contents of the pointer according to at least one embodiment. At least some portions of process 200B may be executed by hardware, firmware, and/or software of the computing device <NUM>.

Generally, process 200B illustrates a cryptographic computing flow in which the encoded pointer <NUM> is used to obtain a memory address for a memory region of memory <NUM> where encrypted data is stored and, once the encrypted data is fetched from the memory region, to decrypt the encrypted data based, at least in part, on a tweak derived from the encoded pointer <NUM>. First, address cryptography unit <NUM> decodes the encoded pointer <NUM> to obtain the decoded linear address <NUM>, which is used to fetch the encrypted data <NUM> from memory, as indicated at <NUM>. Data tweak <NUM> is derived, at least in part, from the encoded pointer <NUM>. In this process 200B for loading/reading data from memory, the data tweak <NUM> is derived in the same manner as in the converse process 200A for storing/writing data to memory.

Once the tweak <NUM> has been derived from encoded pointer <NUM>, the cryptographic computing engine <NUM> can compute decrypted (or unencrypted) data <NUM> by decrypting encrypted data <NUM> based on the data key <NUM> and the data tweak <NUM>. As previously described, in this example, the cryptographic computing engine <NUM> includes an encryption algorithm such as a keystream generator embodied as AES-CTR mode block cipher <NUM>, at a particular size granularity (any suitable size). In this embodiment, the data tweak <NUM> may be used as an initialization vector (IV) and a plaintext offset of the encoded pointer <NUM> may be used as the counter value (CTR). The keystream generator can encrypt the data tweak <NUM> to produce keystream <NUM> and then a cryptographic operation (e.g., the logic function <NUM> such as an exclusive-or (XOR), or other more complex operations) can be performed on the encrypted data <NUM> and the keystream <NUM> in order to generate decrypted (or unencrypted) data <NUM>. It should be noted that the generation of the keystream may commence while the encrypted data is being fetched at <NUM>. Thus, the parallel operations may increase the efficiency of decrypting the encrypted data.

<FIG> illustrates a simplified block diagram of a processor and memory architecture <NUM> in accordance with certain embodiments. The example architecture <NUM> includes two processor cores <NUM> (310a and 310b) and a memory hierarchy that includes respective Level-<NUM> (L1) caches <NUM> (311a and 311b) and <NUM> (312a and 312b) (which may also be referred to as data cache units (DCUs)) for each core <NUM>, a shared Level-<NUM> (L2) cache <NUM> (which may also be referred to as a mid level cache (MLC)), a shared last level cache (LLC) <NUM> (which may also be referred to as a Level-<NUM> (L3) cache), and main memory <NUM> (which could be implemented using any suitable memory, such as a dual inline memory module (DIMM) comprising dynamic random access memory (DRAM), phase change memory, or other suitable memory). Each core <NUM> may have a respective Level-<NUM> data cache (L1D) <NUM> and a Level-<NUM> instruction cache (L1I) <NUM>. Other embodiments may include additional levels of cache between a core and the memory <NUM> or fewer levels of cache between a core and the memory <NUM>.

In various embodiments of the present disclosure, the cryptographic computing engine <NUM> may be placed in any one of the locations indicated by Options <NUM>, <NUM>, and <NUM> (or otherwise in between any two levels of cache or between a cache and memory <NUM>). The cryptographic computing engine <NUM> may perform encryption and decryption on data communicated between memory boundaries. For example, with respect to Option <NUM>, the cryptographic computing engine <NUM> (which may have any suitable characteristics of other cryptographic computing engines described herein) is placed between the caches <NUM>/<NUM> and the L2 cache <NUM> and encrypts data moving downstream from the caches <NUM>/<NUM> to the L2 cache <NUM> and decrypts data moving upstream from the L2 cache <NUM> to caches <NUM>/<NUM>. With respect to Option <NUM>, the cryptographic computing engine <NUM> is placed between the L2 cache <NUM> and the LLC <NUM> and encrypts data moving from the L2 cache <NUM> to the LLC <NUM> and decrypts data moving from the LLC <NUM> to the L2 cache. With respect to Option <NUM>, the cryptographic computing engine <NUM> is placed between the LLC <NUM> and main memory <NUM> and encrypts data moving from the LLC <NUM> to the main memory <NUM> and decrypts data moving from the main memory <NUM> to the LLC <NUM>. In some situations, data may skip one of the caches in the hierarchy during movement. For example, data may be loaded directly from memory <NUM> into the L2 cache, in which case the data may be decrypted by the cryptographic computing engine <NUM> before being placed in the L2 cache whether Option <NUM> or Option <NUM> is implemented.

<FIG> illustrates a plurality of cache lines <NUM> (402A-<NUM>) at various locations in a memory hierarchy of a computing system according to at least one embodiment. In this illustration, cryptographic computing engine <NUM> is placed between the L2 cache <NUM> and the LLC <NUM> (and thus this embodiment corresponds to Option <NUM> described above). However, this disclosure also contemplates use of the techniques described herein with respect to Option <NUM> and Option <NUM> as well as other arrangements). The cache lines <NUM> on the left side of the dotted line underneath the cryptographic computing engine <NUM> represent cache lines within a cache that is upstream (e.g., closer to a core) of the cryptographic computing engine <NUM> (e.g., an L1 cache <NUM> or an L2 cache <NUM>) while the cache lines on the right side of the dotted line represent cache lines within a memory structure that is downstream (farther from a core) of the cryptographic computing engine <NUM> (e.g., LLC <NUM> or memory <NUM>). Data within a memory structure (e.g., a cache or memory) that is upstream of the cryptographic computing engine <NUM> may generally be stored in an unencrypted state while data with a memory structure that is downstream of the cryptographic computing engine <NUM> may be stored in an encrypted state.

In the embodiment depicted, each cache line includes <NUM> Bytes (B) of data, although other embodiments include cache lines of any suitable size. In various embodiments of the present disclosure, the cryptographic computing engine <NUM> is capable of performing cryptographic operations at any suitable granularity, including at a granularity that is smaller than a cache line. For example, in the embodiment depicted, each cache line <NUM> is logically divided into four <NUM> B slots (slot <NUM>, slot <NUM>, slot <NUM>, and slot <NUM>). The lower <NUM> address bits that are used to address the slots are shown in the embodiment depicted. For example, the lower <NUM> address bits of the address for each slot <NUM> are b00xxxx, the lower <NUM> address bits for each slot <NUM> are b01xxx, the lower <NUM> address bits for each slot <NUM> are b10xxxx, and the lower <NUM> address bits for each slot <NUM> are b11xxxx, where the xxxx bits of the address could be used (in some embodiments) to address an individual byte within a slot.

In another example, the cache lines may be logically divided into slots of different sizes. For example, a cache line may be logically divided into eight <NUM> B slots, two <NUM> B slots, or other suitable configuration of slots.

Examples of cryptographic operations that may be performed by the cryptographic computing engine <NUM> on a slot include a block cipher, such as AES with a <NUM> B block size. Other ciphers such as 3DES, PRINCE, K-Cipher, etc. may have different block sizes allowing different slot sizes. A cache line slot corresponds to the output of a block cipher with the block size corresponding to the slot size.

While an entire cache line may belong to the same memory allocation (e.g., object) in many instances, in some cases a first portion (e.g., slot) of data in a cache line may belong to one allocation and a second portion of data in the cache line may belong to another allocation. In some instances, the allocations may be accessed by different software entities and it may be desirable to keep the allocations cryptographically isolated from each other (so that an entity that has access to the first allocation but should not have access to the second allocation is not able to use the data of the first allocation).

In various embodiments, the cryptographic computing engine <NUM> may encrypt and decrypt data at a slot granularity so as to enable cryptographic isolation among different slots of the same cache line. For example, each slot within a cache line may be encrypted separately before being stored in a downstream memory structure (e.g., LLC <NUM>). In one example, during a cryptographic operation performed by the engine <NUM> each slot may be encrypted or decrypted using the same key and tweak, but the cryptographic computing engine <NUM> may encrypt and decrypt along a diffusion boundary of the slot size (e.g., <NUM> B). In another example, during a cryptographic operation performed by the engine <NUM>, a slot in a particular cache line <NUM> may be encrypted using a different key or a different tweak than a key or tweak used to encrypt another slot. In various embodiments, each slot may be encrypted (e.g., tweaked) according to its address or location in memory, location in a cache line, or location in a memory page.

In one embodiment, when a cache line is stored in a cache that is upstream of the cryptographic computing engine <NUM> (e.g., L0 cache, L1 cache <NUM>, or a L2 cache <NUM>), the cache line is stored along with (or otherwise in association with) a tag that includes address information (e.g., physical address bits) for the cache line as well as context information that may be used in the encryption and decryption of the cache line. For example, the context information may identify a key to use for the encryption/decryption and/or other information that may be used in a tweak for the encryption/decryption. When the encrypted cache line is stored downstream of the cryptographic computing engine <NUM> (e.g., in LLC <NUM> or memory <NUM>), the context information is no longer stored in a tag with the cache line (since the encryption of the cache line is now bound to the context information, the context information does not need to be stored, but rather may be supplied, e.g., by an instruction, when the encrypted cache line is decrypted in order to obtain the correct plaintext data). Thus, in various embodiments the context information may be stored in tags in the caches that are upstream of the cryptographic computing engine <NUM>, but not in the caches or memory that store the encrypted cache lines downstream of the cryptographic computing engine <NUM>. The downstream caches and memory are larger (holding more cachelines), therefore it is advantageous to avoid storing this context tag information per cacheline in order to avoid increased downstream cache sizes and latencies.

In the embodiment depicted, the context information used includes a size. For example, the size could be the allocation size or an approximation thereof (for the allocation in memory to which each associated slot belongs). In operation, a single set of context information (e.g., size and/or other context information) is stored in a tag for a physical cache line in an upstream cache. In the embodiment depicted, a plurality of sizes are shown for some of the cache lines in order to illustrate how slots within the same cache line may be encrypted and decrypted using different context information sets.

In some embodiments, when a cache line <NUM> is loaded from a downstream memory structure (e.g., the LLC <NUM> or memory <NUM>) into an upstream cache (e.g., L1 cache <NUM> or L2 cache <NUM>), the cryptographic computing engine <NUM> may use a single context information set (where a context information set may include one or more items of context information, such as a size as depicted) specified by the memory access instruction to decrypt each slot of the cache line. For example, when slot <NUM> or slot <NUM> of cache line 402B is being loaded per a memory access instruction, each slot of the cache line may be decrypted using size <NUM> and when slot <NUM> or slot <NUM> of cache line 402B is being loaded, each slot of the cache line may decrypted using size <NUM>. The resulting decrypted slots of the cache line 402B may then be placed into one or more upstream caches (e.g., L1 cache <NUM> or L2 cache <NUM>). In various embodiments, the size context information may originate from the linear/virtual address referencing an object in memory (e.g., a pointer or capability). Other examples of context information may include the version of an object in memory or other tags that may vary for objects sharing the same cache line. In some embodiments, reading memory for the same address/location with different context information (e.g., size) may result in different cache lines in the upstream cache, while writing cache lines for the same address/location but with different context information will merge back into the same downstream cacheline for that memory address/location.

Cache line 402A includes four slots that are all encrypted based on the same context information set (size <NUM>). Thus, in the LLC <NUM> and memory <NUM>, each slot of cache line 402A is represented as being encrypted based on size <NUM> (s1). Cache line 402B includes two slots (slot0 and slot1) that are encrypted based on a first set of context information (size <NUM>) and two slots (slot <NUM> and slot <NUM>) that are encrypted based on a second set of context information (size <NUM>). On the first row shown in association with cache line 402B, slot <NUM> and slot <NUM> are labeled as ciphertext. This is to signify that when cache line 402B is retrieved from LLC <NUM> or memory <NUM> and decrypted by cryptographic computing engine <NUM> using the first set of context information (e.g., size <NUM> in the tweak), slot <NUM> and slot <NUM> will decrypt correctly, but slot <NUM> and slot <NUM> will not decrypt correctly (since these slots are encrypted based on the second set of context information (e.g., size <NUM> in the tweak). Accordingly, slot <NUM> and slot <NUM> will decrypt into random ciphertext. Similarly, when cache line 402B is decrypted based on the second set of context information (e.g., size <NUM>), slots <NUM> and <NUM> will decrypt correctly, but slots <NUM> and <NUM> will decrypt to random ciphertext, thus protecting this data from an access performed using incorrect context information. However, when symmetric cryptographic operations are used by the engine <NUM>, when the same context information is used in the encryption prior to the slots being stored back in the LLC <NUM> or memory <NUM> (e.g., responsive to modification of the other slots that decrypted correctly), the slots comprising the random ciphertext will be encrypted back into their original encrypted values.

Cache line 402C includes one slot (slot <NUM>) encrypted using size <NUM> and three slots (slot <NUM>, <NUM>, and <NUM>) encrypted using size <NUM>. Cache line 402D includes one slot (slot <NUM>) encrypted using size <NUM>, two slots (slot <NUM> and slot <NUM>) encrypted using size <NUM>, and one slot (slot <NUM>) encrypted using size <NUM>. Cache line 402E includes four slots each encrypted using size <NUM>. Cache line 402F includes two slots (slots <NUM> and <NUM>) encrypted using size <NUM>, one slot (slot <NUM>) encrypted using size <NUM>, and one slot (slot <NUM>) encrypted using size <NUM>. Cache line <NUM> includes three slots (slots <NUM>, <NUM>, and <NUM>) encrypted using size <NUM> and one slot encrypted using size <NUM>. Cache line <NUM> includes two slots (slot <NUM> and slot <NUM>) encrypted using size <NUM> and two slots (slot <NUM> and slot <NUM>) encrypted using size <NUM>.

In the embodiment depicted, the context information stored in a cache line tag includes a size value, such as a size of plaintext address slices (e.g., number of bits in a plaintext slice of a memory address embedded in the encoded pointer) or a memory allocation size (e.g., bytes of allocated memory referenced by the encoded pointer). In various embodiments, the context information may include any suitable information that may be used in cryptographic operations associated with the slots of the cache line, such as a type of the data or code (e.g., class of data or code defined by programming language), permissions (e.g., read, write, and execute permissions of the encoded pointer), a location of the data or code (e.g., where the data or code is stored), encoded pointer (or capability), the memory location where the pointer itself is to be stored (e.g., the location of a return address on a call stack), an ownership of the data or code, a version of the encoded pointer (e.g., a sequential number that is incremented each time an encoded pointer is created for newly allocated memory, determines current ownership of the referenced allocated memory in time), a tag of randomized bits (e.g., generated for association with the encoded pointer), a privilege level (e.g., user or supervisor), a cryptographic context identifier (or crypto context ID) (e.g., randomized or deterministically unique value for each encoded pointer), a process or virtual machine identifier, etc..

As described above, a cache line stored in an upstream cache may store a single set of context information in the tag for the cache line and the cryptographic computing engine <NUM> may encrypt or decrypt each slot individually based on the single set of context information. In other embodiments, the tag in the cache line could include a set of context information for each slot in the cache line and the cryptographic computing engine <NUM> may encrypt or decrypt each slot individually based on the respective context information set for the slot.

<FIG> illustrates a flow for retrieving data responsive to a load instruction according to at least one embodiment of the present disclosure. At <NUM>, a load instruction is issued. The load instruction may supply the context information that is used to decrypt the data (e.g., the context information may be used to select the key, derive the key, or may be used in a tweak) when it is loaded into an upstream cache. The context information may be specified in any suitable manner. For example, the context information may be embedded in a pointer comprising the linear address of the cache line, may be referenced by an index in the pointer, may be included in a separate operand, or may be stored in processor state such as a register. In some embodiments, a processor may translate a linear address into a physical address and access memory using the physical address while also retaining the context information passed along to the cache as a context information tag in addition to the physical memory address/location.

At <NUM>, a determination as to whether the requested cache line is present in the cache is made. If the cache line is already present in an upstream cache, then decryption is not needed and the cache line is retrieved and the requested data (e.g., a slot of the cache line) is placed into a register specified by the load instruction at <NUM>.

If the cache line is not present in an upstream cache, then the cache line is retrieved from memory <NUM> or a downstream cache (e.g., LLC <NUM>) at <NUM>. The slots of the cache line <NUM> are each decrypted based on the context information supplied in the instruction at <NUM> and/or other context information such as the physical address or a portion thereof, the slot position within a cache line, etc. The decrypted slots of the cache line and a tag for the cache line (including address information and the context information) is stored in one or more upstream caches at <NUM>. At <NUM>, data from the cache line (e.g., a slot of the cache line) is placed into a register.

<FIG> illustrates a flow for storing data responsive to a store instruction according to at least one embodiment of the present disclosure. At <NUM>, a store instruction is issued. The store instruction may supply the context information that is used to encrypt the data (e.g., the context information may be used to select the key, derive the key, or may be used in a tweak) when it is stored into a downstream cache or memory <NUM>. The context information may be specified in any suitable manner. For example, the context information may be embedded in a pointer comprising the linear address of the cache line, may be referenced by an index in the pointer, or may be included in a separate operand.

At <NUM>, data (e.g., one or more slots of a cacheline) specified by the store instruction is written to one or more upstream caches along with a tag including address information and context information. At <NUM> a writeback is triggered. In various embodiments, data may be written back to memory <NUM> automatically upon being written to an upstream cache or may be written back pursuant to the cacheline being evicted from the upstream cache. At <NUM>, the slots of the cache line are encrypted based on the context information in the tag of the cache line and/or other context information such as the physical address or a portion thereof, the slot position within a cache line, etc. In some embodiments, all slots are encrypted. In other embodiments, only the slots that have been modified are encrypted. The modified slots (which are now encrypted) may then be written back to memory <NUM> at <NUM> (and may be optionally written to one or more downstream caches as well).

<FIG> below provide some example computing devices, computing environments, hardware, software or flows that may be used in the context of embodiments as described herein.

<FIG> is a block diagram illustrating an example cryptographic computing environment <NUM> according to at least one embodiment. In the example shown, a cryptographic addressing layer <NUM> extends across the example compute vectors (e.g., processor units) central processing unit (CPU) <NUM>, graphical processing unit (GPU) <NUM>, artificial intelligence (AI) <NUM>, and field programmable gate array (FPGA) <NUM>. For example, the CPU <NUM> and GPU <NUM> may share the same virtual address translation for data stored in memory <NUM>, and the cryptographic addresses may build on this shared virtual memory. They may share the same process key for a given execution flow, and compute the same tweaks to decrypt the cryptographically encoded addresses and decrypt the data referenced by such encoded addresses, following the same cryptographic algorithms.

Combined, the capabilities described herein may enable cryptographic computing. Memory <NUM> may be encrypted at every level of the memory hierarchy, from the first level of cache through last level of cache and into the system memory. Binding the cryptographic address encoding to the data encryption may allow extremely fine-grain object boundaries and access control, enabling fine grain secure containers down to even individual functions and their objects for function-as-a-service. Cryptographically encoding return addresses on a call stack (depending on their location) may also enable control flow integrity without the need for shadow stack metadata. Thus, any of data access control policy and control flow can be performed cryptographically, simply dependent on cryptographic addressing and the respective cryptographic data bindings.

<NUM>-<NUM> are block diagrams of exemplary computer architectures that may be used in accordance with embodiments disclosed herein. Generally, any computer architecture designs known in the art for processors and computing systems may be used. In an example, system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, tablets, engineering workstations, servers, network devices, servers, appliances, network hubs, routers, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, smart phones, mobile devices, wearable electronic devices, portable media players, hand held devices, and various other electronic devices, are also suitable for embodiments of computing systems described herein. Generally, suitable computer architectures for embodiments disclosed herein can include, but are not limited to, configurations illustrated in <FIG>.

<FIG> is an example illustration of a processor according to an embodiment. Processor <NUM> is an example of a type of hardware device that can be used in connection with the implementations shown and described herein (e.g., processor <NUM>). Processor <NUM> may be any type of processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, a multi-core processor, a single core processor, or other device to execute code. Although only one processor <NUM> is illustrated in <FIG>, a processing element may alternatively include more than one of processor <NUM> illustrated in <FIG>. Processor <NUM> may be a single-threaded core or, for at least one embodiment, the processor <NUM> may be multi-threaded in that it may include more than one hardware thread context (or "logical processor") per core.

<FIG> also illustrates a memory <NUM> coupled to processor <NUM> in accordance with an embodiment. Memory <NUM> may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. Such memory elements can include, but are not limited to, random access memory (RAM), read only memory (ROM), logic blocks of a field programmable gate array (FPGA), erasable programmable read only memory (EPROM), and electrically erasable programmable ROM (EEPROM).

Processor <NUM> can execute any type of instructions associated with algorithms, processes, or operations detailed herein. Generally, processor <NUM> can transform an element or an article (e.g., data) from one state or thing to another state or thing.

Code <NUM>, which may be one or more instructions to be executed by processor <NUM>, may be stored in memory <NUM>, or may be stored in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object where appropriate and based on particular needs. In one example, processor <NUM> can follow a program sequence of instructions indicated by code <NUM>. Each instruction enters a front-end logic <NUM> and is processed by one or more decoders <NUM>. The decoder may generate, as its output, a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals that reflect the original code instruction. Front-end logic <NUM> also includes register renaming logic <NUM> and scheduling logic <NUM>, which generally allocate resources and queue the operation corresponding to the instruction for execution.

Processor <NUM> can also include execution logic <NUM> having a set of execution units 816a, 816b, 816n, etc. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. Execution logic <NUM> performs the operations specified by code instructions.

After completion of execution of the operations specified by the code instructions, back-end logic <NUM> can retire the instructions of code <NUM>. In one embodiment, processor <NUM> allows out of order execution but requires in order retirement of instructions. Retirement logic <NUM> may take a variety of known forms (e.g., re-order buffers or the like). In this manner, processor <NUM> is transformed during execution of code <NUM>, at least in terms of the output generated by the decoder, hardware registers and tables utilized by register renaming logic <NUM>, and any registers (not shown) modified by execution logic <NUM>.

Although not shown in <FIG>, a processing element may include other elements on a chip with processor <NUM>. For example, a processing element may include memory control logic along with processor <NUM>. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (such as flash memory or fuses) may also be included on the chip with processor <NUM>.

<FIG> is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue/execution pipeline according to one or more embodiments of this disclosure. <FIG> is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to one or more embodiments of this disclosure. The solid lined boxes in <FIG> illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue/execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

Processor core <NUM> and memory unit <NUM> are examples of the types of hardware that can be used in connection with the implementations shown and described herein (e.g., processor <NUM>, memory <NUM>). In addition, processor core <NUM> and its components represent example architecture that could be used to implement logical processors and their respective components.

The front end unit <NUM> includes a branch prediction unit <NUM> coupled to an instruction cache unit <NUM>, which is coupled to an instruction translation lookaside buffer (TLB) unit <NUM>, which is coupled to an instruction fetch unit <NUM>, which is coupled to a decode unit <NUM>.

The execution engine unit <NUM> includes the rename/allocator unit <NUM> coupled to a retirement unit <NUM> and a set of one or more scheduler unit(s) <NUM>. The scheduler unit(s) <NUM> represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s) <NUM> is coupled to the physical register file(s) unit(s) <NUM>. Each of the physical register file(s) units <NUM> represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register file(s) unit <NUM> comprises a vector registers unit, a write mask registers unit, and a scalar registers unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers (GPRs). In at least some embodiments described herein, register units <NUM> are examples of the types of hardware that can be used in connection with the implementations shown and described herein (e.g., registers <NUM>). The physical register file(s) unit(s) <NUM> is overlapped by the retirement unit <NUM> to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer(s) and a retirement register file(s); using a future file(s), a history buffer(s), and a retirement register file(s); using register maps and a pool of registers; etc.). The retirement unit <NUM> and the physical register file(s) unit(s) <NUM> are coupled to the execution cluster(s) <NUM>. The execution cluster(s) <NUM> includes a set of one or more execution units <NUM> and a set of one or more memory access units <NUM>. The execution units <NUM> may perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Execution units <NUM> may also include an address generation unit to calculate addresses used by the core to access main memory (e.g., memory unit <NUM>) and a page miss handler (PMH).

The scheduler unit(s) <NUM>, physical register file(s) unit(s) <NUM>, and execution cluster(s) <NUM> are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline that each have their own scheduler unit, physical register file(s) unit, and/or execution cluster - and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit(s) <NUM>). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

In addition, a page miss handler may also be included in core <NUM> to look up an address mapping in a page table if no match is found in the data TLB unit <NUM>.

By way of example, the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline <NUM> as follows: <NUM>) the instruction fetch unit <NUM> performs the fetch and length decoding stages <NUM> and <NUM>; <NUM>) the decode unit <NUM> performs the decode stage <NUM>; <NUM>) the rename/allocator unit <NUM> performs the allocation stage <NUM> and renaming stage <NUM>; <NUM>) the scheduler unit(s) <NUM> performs the scheduling stage <NUM>; <NUM>) the physical register file(s) unit(s) <NUM> and the memory unit <NUM> perform the register read/memory read stage <NUM>; the execution cluster <NUM> perform the execute stage <NUM>; <NUM>) the memory unit <NUM> and the physical register file(s) unit(s) <NUM> perform the write back/memory write stage <NUM>; <NUM>) various units may be involved in the exception handling stage <NUM>; and <NUM>) the retirement unit <NUM> and the physical register file(s) unit(s) <NUM> perform the commit stage <NUM>.

Accordingly, in at least some embodiments, multi-threaded enclaves may be supported.

While register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in an in-order architecture. While the illustrated embodiment of the processor also includes separate instruction and data cache units <NUM>/<NUM> and a shared L2 cache unit <NUM>, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a Level <NUM> (L1) internal cache, or multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and/or the processor. Alternatively, all of the cache may be external to the core and/or the processor.

<FIG> illustrates a computing system <NUM> that is arranged in a point-to-point (PtP) configuration according to an embodiment. In particular, <FIG> shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. Generally, one or more of the computing systems or computing devices described herein may be configured in the same or similar manner as computing system <NUM>.

Processors <NUM> and <NUM> may be implemented as single core processors 1074a and 1084a or multi-core processors 1074a-1074b and 1084a-1084b. Processors <NUM> and <NUM> may each include a cache <NUM> and <NUM> used by their respective core or cores. A shared cache (not shown) may be included in either processors or outside of both processors, yet connected with the processors via P-P interconnect, such that either or both processors' local cache information may be stored in the shared cache if a processor is placed into a low power mode. It should be noted that one or more embodiments described herein could be implemented in a computing system, such as computing system <NUM>. Moreover, processors <NUM> and <NUM> are examples of the types of hardware that can be used in connection with the implementations shown and described herein (e.g., processor <NUM>).

Processors <NUM> and <NUM> may also each include integrated memory controller logic (IMC) <NUM> and <NUM> to communicate with memory elements <NUM> and <NUM>, which may be portions of main memory locally attached to the respective processors. In alternative embodiments, memory controller logic <NUM> and <NUM> may be discrete logic separate from processors <NUM> and <NUM>. Memory elements <NUM> and/or <NUM> may store various data to be used by processors <NUM> and <NUM> in achieving operations and functionality outlined herein.

Processors <NUM> and <NUM> may be any type of processor, such as those discussed in connection with other figures. Processors <NUM> and <NUM> may exchange data via a point-to-point (PtP) interface <NUM> using point-to-point interface circuits <NUM> and <NUM>, respectively. Processors <NUM> and <NUM> may each exchange data with an input/output (I/O) subsystem <NUM> via individual point-to-point interfaces <NUM> and <NUM> using point-to-point interface circuits <NUM>, <NUM>, <NUM>, and <NUM>. I/O subsystem <NUM> may also exchange data with a high-performance graphics circuit <NUM> via a high-performance graphics interface <NUM>, using an interface circuit <NUM>, which could be a PtP interface circuit. In one embodiment, the high-performance graphics circuit <NUM> is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. I/O subsystem <NUM> may also communicate with a display <NUM> for displaying data that is viewable by a human user. In alternative embodiments, any or all of the PtP links illustrated in <FIG> could be implemented as a multi-drop bus rather than a PtP link.

I/O subsystem <NUM> may be in communication with a bus <NUM> via an interface circuit <NUM>. Bus <NUM> may have one or more devices that communicate over it, such as a bus bridge <NUM>, I/O devices <NUM>, and one or more other processors <NUM>. Via a bus <NUM>, bus bridge <NUM> may be in communication with other devices such as a user interface <NUM> (such as a keyboard, mouse, touchscreen, or other input devices), communication devices <NUM> (such as modems, network interface devices, or other types of communication devices that may communicate through a computer network <NUM>), audio I/O devices <NUM>, and/or a storage unit <NUM>. Storage unit <NUM> may store data and code <NUM>, which may be executed by processors <NUM> and/or <NUM>. In alternative embodiments, any portions of the bus architectures could be implemented with one or more PtP links.

Program code, such as code <NUM>, may be applied to input instructions to perform the functions described herein and generate output information. For purposes of this application, a processing system may be part of computing system <NUM> and includes any system that has a processor, such as, for example; a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

The program code (e.g., <NUM>) may be implemented in a high level procedural or object oriented programming language to communicate with a processing system.

<FIG> is a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set according to embodiments of this disclosure. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. <FIG> shows a program in a high level language <NUM> may be compiled using an x86 compiler <NUM> to generate x86 binary code <NUM> that may be natively executed by a processor with at least one x86 instruction set core <NUM>. The processor with at least one x86 instruction set core <NUM> represents any processor that can perform substantially the same functions as an Intel processor with at least one x86 instruction set core by compatibly executing or otherwise processing (<NUM>) a substantial portion of the instruction set of the Intel x86 instruction set core or (<NUM>) object code versions of applications or other software targeted to run on an Intel processor with at least one x86 instruction set core, in order to achieve substantially the same result as an Intel processor with at least one x86 instruction set core. The x86 compiler <NUM> represents a compiler that is operable to generate x86 binary code <NUM> (e.g., object code) that can, with or without additional linkage processing, be executed on the processor with at least one x86 instruction set core <NUM>. Similarly, <FIG> shows the program in the high level language <NUM> may be compiled using an alternative instruction set compiler <NUM> to generate alternative instruction set binary code <NUM> that may be natively executed by a processor without at least one x86 instruction set core <NUM> (e.g., a processor with cores that execute the MIPS instruction set of MIPS Technologies of Sunnyvale, CA and/or that execute the ARM instruction set of ARM Holdings of Sunnyvale, CA). The instruction converter <NUM> is used to convert the x86 binary code <NUM> into code that may be natively executed by the processor without an x86 instruction set core <NUM>. This converted code is not likely to be the same as the alternative instruction set binary code <NUM> because an instruction converter capable of this is difficult to make; however, the converted code will accomplish the general operation and be made up of instructions from the alternative instruction set. Thus, the instruction converter <NUM> represents software, firmware, hardware, or a combination thereof that, through emulation, simulation or any other process, allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code <NUM>.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the one or more of the techniques described herein.

Such machine-readable storage media may include, without limitation, non-transitory, tangible arrangements of articles manufactured or formed by a machine or device, including storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), phase change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

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

The computing system depicted in <FIG> is a schematic illustration of an embodiment of a computing system that may be utilized to implement various embodiments discussed herein. It will be appreciated that various components of the system depicted in <FIG> may be combined in a system-on-a-chip (SoC) architecture or in any other suitable configuration capable of achieving the functionality and features of examples and implementations provided herein.

Although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. For example, the actions described herein can be performed in a different order than as described and still achieve the desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.

The architectures presented herein are provided by way of example only, and are intended to be non-exclusive and non-limiting. Furthermore, the various parts disclosed are intended to be logical divisions only, and need not necessarily represent physically separate hardware and/or software components. Certain computing systems may provide memory elements in a single physical memory device, and in other cases, memory elements may be functionally distributed across many physical devices. In the case of virtual machine managers or hypervisors, all or part of a function may be provided in the form of software or firmware running over a virtualization layer to provide the disclosed logical function.

Note that with the examples provided herein, interaction may be described in terms of a single computing system. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a single computing system. Moreover, the system for deep learning and malware detection is readily scalable and can be implemented across a large number of components (e.g., multiple computing systems), as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of the computing system as potentially applied to a myriad of other architectures.

As used herein, unless expressly stated to the contrary, use of the phrase 'at least one of' refers to any combination of the named items, elements, conditions, or activities. For example, 'at least one of X, Y, and Z' is intended to mean any of the following: <NUM>) at least one X, but not Y and not Z; <NUM>) at least one Y, but not X and not Z; <NUM>) at least one Z, but not X and not Y; <NUM>) at least one X and at least one Y, but not Z; <NUM>) at least one X and at least one Z, but not Y; <NUM>) at least one Y and at least one Z, but not X; or <NUM>) at least one X, at least one Y, and at least one Z.

Additionally, unless expressly stated to the contrary, the terms 'first', 'second', 'third', etc., are intended to distinguish the particular nouns (e.g., element, condition, module, activity, operation, claim element, etc.) they modify, but are not intended to indicate any type of order, rank, importance, temporal sequence, or hierarchy of the modified noun. For example, 'first X' and "second X' are intended to designate two separate X elements that are not necessarily limited by any order, rank, importance, temporal sequence, or hierarchy of the two elements.

References in the specification to "one embodiment," "an embodiment," "some embodiments," etc., indicate that the embodiment(s) described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any embodiments or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination.

Similarly, the separation of various system components and modules in the embodiments described above should not be understood as requiring such separation in all embodiments. It should be understood that the described program components, modules, and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claim 1:
A method, comprising:
requesting a cache line (<NUM>) from memory (<NUM>) responsive to a memory access instruction, wherein the cache line (<NUM>) comprises a first slot encrypted according to first context information and a second slot encrypted according to second context information, wherein the first context information is different from the second context information;
decrypting, by a cryptographic computing engine (<NUM>, <NUM>, <NUM>) using symmetric cryptographic operations, the first slot and the second slot of the cache line (<NUM>) based on the first context information; and
storing the decrypted first slot (<NUM>) and the decrypted second slot (<NUM>) of the cache line (<NUM>) and a tag in a first cache (311a-b, 312a-b, <NUM>, <NUM>), wherein the tag comprises the first context information.