Management of keys for use in cryptographic computing

A method comprising executing, by a core of a processor, a first instruction requesting access to a parameter associated with data for storage in a main memory coupled to the processor, the first instruction including a reference to the parameter, a reference to a wrapping key, and a reference to an encrypted encryption key, wherein execution of the first instruction comprises decrypting the encrypted encryption key using the wrapping key to generate a decrypted encryption key; requesting transfer of the data between the main memory and the processor core; and performing a cryptographic operation on the parameter using the decrypted encryption key.

TECHNICAL FIELD

This disclosure relates in general to the field of computing systems and, more particularly, to management of keys for use in cryptographic computing.

BACKGROUND

Protecting memory in computer systems from software bugs and security vulnerabilities is a significant concern. Encrypting data before storage may mitigate the potential of damage from malicious actors. For a system protecting multiple different cryptographic contexts (where each context is protected by a different cryptographic key or tweak), the management of the cryptographic keys may be intensive in terms of storage space or computational resources.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Various embodiments of the present disclosure address cryptographic key management issues associated with instruction guard extensions and/or cryptographic computing. Cryptographic computing is a new computing paradigm where security is supported by fine grain cryptographic operations occurring at the processor core. Cryptographic computing may encompass the encrypting and decrypting of pointers to data and/or the data itself. Encryption and decryption operations utilize encryption keys. Implicit access to encryption keys (e.g., by reference) stored inside a central processing unit (CPU) is a potential solution but is costly since the amount of state that needs to be maintained inside the CPU is proportional to the number of keys that are used.

Embodiments of the present disclosure provide a flexible instruction set for a processor to securely store and access keys in a cost efficient way by software applications running on a computing device100. Some of these instructions may perform encrypted memory read and write operations, wherein data gets encrypted before exiting the CPU core and entering the L1 cache. Similarly, data gets decrypted after crossing the CPU boundary and entering the CPU core. The microarchitecture pipeline extensions supporting this fine grain isolation of software components may be referred to as “instruction guard extensions.”

In some embodiments, key management may be simplified by the use of a register file comprising dedicated cryptographic key registers104. In some embodiments, these registers104are dedicated to storing one or more of data encryption keys, pointer encryption keys, and wrapping keys, where “wrapping” refers to the encryption of a data or pointer encryption key (similarly “unwrapping” refers to the decryption of a wrapped data or pointer encryption key). In other embodiments, these registers104may additionally store results of based on such keys (e.g., encrypted or decrypted data or pointers), where the results may be produced by instructions described herein (or other cryptographic instructions). Various instructions of the new instruction set described herein may include parameters comprising references to the dedicated registers104storing the keys to be used in the cryptographic operations requested by the instructions. Accordingly, keys stored in the dedicated registers104may be explicitly stored, accessed, and referenced by software applications utilizing such instructions. In some embodiments, access to the dedicated registers104is limited to a subset of the instructions executable by processor102, such as any combination of the cryptographic instructions described herein or other cryptographic instructions requiring access to these registers (e.g., various instructions that access general purpose registers106or data registers108may be prohibited from accessing the dedicated registers104). For example, processor102may be capable of executing a load and store instructions that cannot access the dedicated registers104as well as cryptographic load and store instructions that can access the dedicated registers104.

In various embodiments described herein, the instructions may support one or more of: the wrapping and unwrapping of keys, the encryption and decryption of data or pointers by directly passing as input a wrapped key and the wrapping key, and the encryption and decryption of data or pointers by directly passing as input a master key and context information (which may be implicit, e.g., an object index) which can be used to compute a derived key used for the actual data encryption or decryption. In some embodiments, the new instructions and registers can support scalable access to a large number (e.g., millions) of cryptographically isolated memory areas without requiring the maintenance of each key and controlled access to secrets where different functions in the same application space may be able to access only subsets of these secrets.

The term “key” as used herein refers to an encryption secret that is passed as input to a cryptographic algorithm, which supports at least one of the functions of confidentiality and data integrity. In various embodiments, the term “key” may be used to either refer to a secret bit string that is expanded into a round key schedule string, as done by typical block ciphers, a tweak value that customizes the operation of block ciphers or cryptographic hash functions (also referred to as a “tweak”), or other suitable cryptographic secret used to encrypt or decrypt data, pointers, or other keys. Among other things, a tweak may refer to an extra input to a block cipher (e.g., an input other than the usual plaintext or ciphertext input and the cryptographic key). When the same plaintext is encrypted using the same cryptographic key, different tweak values will result in different encrypted data outputs. Similarly, when the same ciphertext is decrypted using the same cryptographic key, different tweak values will result in different plaintext outputs.

Any suitable cryptographic mode may be used to perform the encryption and decryption operations described herein. For example, the processor102may utilize Advanced Encryption Standard Electronic Codebook (AES-ECB), AES xor-encrypt-xor (XEX) based tweaked-codebook mode with ciphertext stealing (AES-XTS), AES counter (AES-CTR), a k-cipher, SIMON, PRINCE, or SPECK cipher, or other suitable cryptographic modes of operation to encrypt and decrypt data, pointers, and/or keys. In various embodiments, symmetric cryptographic modes may be used so that the same key, and/or tweak may be used for encryption and decryption operations.

Referring in detail toFIG. 1, the computing device100may be embodied as any type of electronic device for performing the functions described herein. For example, the computing device100may 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 inFIG. 1, the example computing device100includes at least one processor102. Processor102includes dedicated cryptographic key registers104, general purpose registers106, data registers108, and microarchitecture components110.

Dedicated registers104may include a plurality of registers that may each store a data encryption key (e.g., a key used to encrypt data), a pointer encryption key (e.g., a key used to encrypt a pointer to data), or a wrapping key (e.g., a key used to encrypt a data encryption key and/or a pointer encryption key). In an alternative embodiment, a register may store a key pair (e.g., a data encryption key and a wrapping key associated with that data encryption key). Utilization of the dedicated registers104may preserve space in the data registers108(which may be limited) for data other than keys (in some embodiments, bit strings for keys may be rather large, such as 128, 256, or 512 bits).

In a particular embodiment, a new instruction is provided to load one or more keys into a dedicated register104. The instruction may be formatted in any suitable manner. As just one example, the instruction may specify a register (e.g., a data register108) storing a key and a dedicated register104into which the key is to be moved. Thus, a software application may provide a key (e.g., a random number generated using a boot process of device100or other suitable key) and may invoke an instruction to move that key to a dedicated register104. In some embodiments, the dedicated registers104may be write only registers in order to protect the keys stored therein (and thus results utilizing the keys, such as a wrapped encryption key or an unwrapped encryption key may be placed in a non-dedicated register for retrieval by the calling application). In another embodiment, an additional instruction may be provided to access one or more keys stored in a dedicated register104(and other security precautions may be implemented to guard against unauthorized retrieval of keys from the dedicated registers104).

General purpose register106may store general purpose information, such as data or addresses. Data registers108may hold data such as numeric data values (e.g., integers), characters, bit arrays, or other suitable data. For example, data registers108may include Advanced Vector Extensions (AVX) registers, such as XMM, YMM, or ZMM registers as provided by the x86 instruction set architecture (ISA) or other suitable data registers. In some embodiments, the data registers are larger than the general purpose registers106.

The processor102may also include michroarchitecture components110, such as functional units, caches, and other suitable logic. Various examples of such components110may be found in the example architectures set forth inFIGS. 10-13.

The computing device100also includes main memory122, an input/output subsystem124, a data storage device126, a display device128, a user interface (UI) subsystem130, a communication subsystem132, at least one user space application134, and privileged system component142. The computing device100may include other or additional components, such as those commonly found in 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 device100may be embodied as software, firmware, hardware, or a combination of software and hardware.

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

The main memory122of the computing device100may 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 main memory122complies 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.jedec.org). 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, main memory122comprises one or more memory modules, such as dual in-line memory modules (DIMMs). In some embodiments, the main memory122may be located on one or more integrated circuit chips that are distinct from an integrated circuit chip comprising processor102or may be located on the same integrated circuit chip as the processor102. Main memory122may comprise any suitable type of memory and is not limited to a particular speed or technology of memory in various embodiments.

In operation, the main memory122may store various data and software used during operation of the computing device100, as well as operating systems, applications, programs, libraries, and drivers. Main memory122may store data and/or sequences of instructions that are executed by the processor102.

The main memory122is communicatively coupled to the processor102, e.g., via the I/O subsystem124. The I/O subsystem124may be embodied as circuitry and/or components to facilitate input/output operations with the processor102, the main memory122, and other components of the computing device100. For example, the I/O subsystem124may 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 subsystem124may form a portion of a system-on-a-chip (SoC) and be incorporated, along with one or more of the processor102, the main memory122, and/or other components of the computing device100, on a single integrated circuit chip.

The data storage device126may 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, main memory122may cache data that is stored on data storage device126.

The display device128may 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 device128may be coupled to a touch screen or other human computer interface device to allow user interaction with the computing device100. The display device128may be part of the user interface (UI) subsystem130. The user interface subsystem130may include a number of additional devices to facilitate user interaction with the computing device100, 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 subsystem130may 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 device100.

The computing device100further includes a communication subsystem132, which may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the computing device100and other electronic devices. The communication subsystem132may 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, 3G/LTE, etc.) to effect such communication. In some embodiments, the communication subsystem132may be embodied as a network adapter, such as a wireless network adapter.

The example computing device100also includes a number of computer program components, such as one or more user space applications134or other applications. The user space application134may 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 device128or the UI subsystem130. Some examples of user space applications134include 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 component142facilitates the communication between the user space applications134and the hardware components of the computing device100. Portions of the privileged system component142may 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 component142may 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).

FIG. 2Aillustrates a flow of an encrypt key instruction in accordance with certain embodiments. Execution of the encrypt key instruction by the processor may include identifying a wrapping key202and a data-encryption key204specified by the instruction and performing a encrypt key operation206to encrypt the data-encryption key204based on the wrapping key202to form wrapped data-encryption key208.

In an embodiment, the parameters of the encrypt key instruction may include a reference to wrapping key202and a reference to data-encryption key204. In some embodiments, the parameters may also include a reference to a location at which the wrapped data-encryption key208is to be stored. In various embodiments, one or more of the parameters may be implicit rather than explicit, such that the processor102is configured to access the same register or memory location (e.g., in main memory122) to obtain or store the associated operator (e.g.,202,204, or208) each time the encrypt key instruction is executed.

In an embodiment, the reference to wrapping key202is an identifier (ID) of a first register of dedicated registers104which stores the wrapping key202and the reference to data-encryption key204is an ID of a second register of dedicated registers104which stores the data-encryption key. In another embodiment, the reference to wrapping key202is an ID of a register of the dedicated registers104which stores the wrapping key202and the reference to data-encryption key204is an ID of a non-dedicated register (e.g., one of data registers108which stores the data-encryption key). In other embodiments, one or more of these references may comprise an ID of a non-dedicated register (e.g., a data register of data registers108) or other memory location (e.g., a location in main memory122). In various embodiments, the reference to the location for the wrapped data-encryption key208may be an ID of a dedicated register104, an ID of a non-dedicated register, or other suitable memory location.

As described above, one or more of the parameters of the instruction may be implicit. For example, the wrapped data-encryption key208may be placed in the second dedicated register104and may overwrite the data-encryption key204(when the data-encryption key204is placed in one of the dedicated registers104) each time the encrypt key instruction is called. As another example, the wrapped data-encryption key may be placed in a dedicated register104or in a non-dedicated register (e.g., one of data registers108) that is different from the register used to hold the data-encryption key204each time the instruction is executed. In other examples, one or both of the wrapping key202and data-encryption key204may be accessed from the same register or memory location each time the instruction is executed.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a encrypt key instruction as described herein. In some embodiments, an instruction may implement the functionality of the encrypt key instruction described herein as well as one or more other functions (that is, the flow shown for the encrypt key instruction may be performed as part of the execution of another instruction e.g., that may be identified by an opcode that is different from the opcode used to identify the encrypt key instruction).

FIG. 2Billustrates a flow of a decrypt key instruction in accordance with certain embodiments. Execution of the decrypt key instruction by the processor may include identifying a wrapping key202and a wrapped data-encryption key208specified by the instruction and performing a decrypt key operation210to decrypt the wrapped data-encryption key208based on the wrapping key202to generate data-encryption key204(which may in some situations be a recovery of the data-encryption key that was encrypted using an encrypt key instruction).

In an embodiment, the parameters of the decrypt key instruction may include a reference to wrapping key202and a reference to wrapped data-encryption key208. In some embodiments, the parameters may also include a reference to a location at which the data-encryption key204is to be stored. In various embodiments, one or more of the parameters may be implicit (as described above).

In an embodiment, the reference to wrapping key202is an ID of a first register of dedicated registers104which stores the wrapping key202and the reference to wrapped data-encryption key208is an ID of a second register of dedicated registers104which stores the wrapped data-encryption key. In another embodiment, the reference to wrapping key202is an ID of a register of the dedicated registers104which stores the wrapping key202and the reference to wrapped data-encryption key208is an ID of a non-dedicated register (e.g., one of data registers108which stores the wrapped data-encryption key). In other embodiments, one or more of these references may comprise an ID of a non-dedicated register (e.g., a data register of data registers108) or other memory location. In various embodiments, the reference to the location for the data-encryption key204may be an ID of a dedicated register104, an ID of a non-dedicated register, or other suitable memory location.

As described above, one or more of the parameters of the instruction may be implicit. For example, the data-encryption key204may be placed in the second dedicated register104and may overwrite the wrapped data-encryption key208(when the wrapped data-encryption key208is placed in one of the dedicated registers104) each time the decrypt key instruction is called. As another example, the data-encryption key204may be placed in a dedicated register104or in a non-dedicated register (e.g., one of data registers108) that is different from the register used to hold the wrapped data-encryption key208each time the instruction is executed. In other examples, one or both of the wrapping key202and wrapped data-encryption key208may be accessed from the same register or memory location each time the instruction is executed.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a decrypt key instruction as described herein. In some embodiments, an instruction may implement the functionality of the decrypt key instruction described herein as well as one or more other functions (that is, the flow shown for the decrypt key instruction may be performed as part of the execution of another instruction e.g., that may be identified by an opcode that is different from the opcode used to identify the decrypt key instruction). For example, the flow of the decrypt key instruction may be used within a decrypt key and encrypt data instruction, a decrypt key and decrypt data instruction, a decrypt key and encrypt pointer instruction, or a decrypt key and decrypt pointer instruction as described below in connection withFIGS. 3A, 3B, 4A, and 4B.

In various embodiments, instructions similar to the encrypt instruction and decrypt instruction described above in connection withFIGS. 2A and 2Bmay be used to encrypt and decrypt a pointer-encryption key (where a pointer-encryption key may be substituted for the data-encryption key and a wrapped pointer-encryption key may be substituted for the wrapped data-encryption key). Alternatively, if the encrypt key operation206and decrypt key operation210operate similarly regardless of whether the input is a data-encryption key204and a wrapped data-encryption key208or a pointer-encryption key and wrapped pointer-encryption key, the same encrypt instruction and decrypt instructions may be used to encrypt and decrypt data-encryption keys and pointer-encryption keys. Moreover, in various embodiments, the processor102may support various types of encryption and decryption operations206and210(e.g., using different lengths or different modes of cryptography) using variants of the encrypt instruction and decrypt instruction (e.g., instructions with different opcodes and/or other parameter values).

FIG. 3Aillustrates a flow of a decrypt key and encrypt data instruction in accordance with certain embodiments. In some embodiments, the encryption of the data takes place as part of a store operation, where data is transferred from the processor core to the main memory. In one embodiment, the store operation is executed by the processor core responsive to a cryptographic store instruction called by an application. Execution of the decrypt key and encrypt data instruction by the processor may include identifying a wrapping key202, a wrapped data-encryption key208, and data302specified by the instruction and performing a decrypt key and encrypt data operation304to generate encrypted data306. Operation304may include using the wrapping key202to perform a decrypt key operation210on the wrapped data-encryption key208to extract a data-encryption key204, and then using the unwrapped data-encryption key204to encrypt the data302to generate the encrypted data306.

In an embodiment, the parameters of the decrypt key and encrypt data instruction may include a reference to wrapping key202, a reference to wrapped data-encryption key208, and a reference to data302. In some embodiments, the parameters may also include a reference to a location at which the encrypted data306is to be stored. In various embodiments, one or more of the parameters may be implicit rather than explicit, such that the processor102is configured to access the same register or memory location (e.g., in main memory122) to obtain or store the associated operator (e.g.,202,208,302, or306) each time the decrypt key and encrypt data instruction is executed.

In an embodiment, the reference to wrapping key202is an ID of a first register of dedicated registers104which stores the wrapping key202, the reference to wrapped data-encryption key208is an ID of a second register of dedicated registers104which stores the wrapped data-encryption key, and the reference to data302is an ID of a non-dedicated register (e.g., a data register108) or location in memory which stores the data302. In another embodiment, the reference to wrapping key202is an ID of a register of the dedicated registers104which stores the wrapping key202, the reference to wrapped data-encryption key208is an ID of a non-dedicated register (e.g., one of data registers108which stores the wrapped data-encryption key), and the reference to data302is an ID of a non-dedicated register (e.g., a data register108) or a location in memory. In other embodiments, any one or more of these references may comprise an ID of a dedicated register104, a non-dedicated register (e.g., a data register108) or other memory location. In various embodiments, the reference to the location for the encrypted data306may be an ID of a dedicated register, an ID of a non-dedicated register, or other suitable memory location.

As described above, one or more of the parameters of the instruction may be implicit. For example, the encrypted data306may be placed in the same register or memory location as the data302and may overwrite the data302each time the decrypt key and encrypt data instruction is called. As another example, the encrypted data306may be placed in a non-dedicated register or memory location that is different from the non-dedicated register or memory location that stores the data302each time the instruction is executed. In other examples, one or more of the wrapping key202, wrapped data-encryption key208, or data302may be accessed from the same register or memory location each time the instruction is executed.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a decrypt key and encrypt data instruction as described herein. In some embodiments, an instruction may implement the functionality of the decrypt key and encrypt data instruction described herein as well as one or more other functions (that is, the flow shown for the decrypt key and encrypt data instruction may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the decrypt key and encrypt data instruction instruction). For example, a cryptographic store instruction may perform the operations of the decrypt key and encrypt data instruction and (in some embodiments) additional operations (e.g., moving the data302into the location referenced by the decrypt key and encrypt data instruction or moving the encrypted data306to memory).

FIG. 3Billustrates a flow of a decrypt key and decrypt data instruction in accordance with certain embodiments. In some embodiments, the decryption of the data takes place as part of a load operation, where data is transferred from the main memory to the processor core. In one embodiment, the load operation is executed by the processor core responsive to a cryptographic load instruction called by an application. Execution of the decrypt key and decrypt data instruction by the processor may include identifying a wrapping key202, a wrapped data-encryption key208, and encrypted data306specified by the instruction and performing a decrypt key and decrypt data operation308to generate data302. Operation308may include using the wrapping key202to perform a decrypt key operation210on the wrapped data-encryption key208to extract a data-encryption key204, and then using the unwrapped data-encryption key204to decrypt the encrypted data306to generate the data302.

In an embodiment, the parameters of the decrypt key and decrypt data instruction may include a reference to wrapping key202, a reference to wrapped data-encryption key208, and a reference to encrypted data306. In some embodiments, the parameters may also include a reference to a location at which the data302is to be stored. In various embodiments, one or more of the parameters may be implicit rather than explicit, such that the processor102is configured to access the same register or memory location (e.g., in main memory122) to obtain or store the associated operator (e.g.,202,208,306, or302) each time the decrypt key and decrypt data instruction is executed.

In an embodiment, the reference to wrapping key202is an ID of a first register of dedicated registers104which stores the wrapping key202, the reference to wrapped data-encryption key208is an ID of a second register of dedicated registers104which stores the wrapped data-encryption key, and the reference to encrypted data306is an ID of a non-dedicated register (e.g., a data register108) or location in memory which stores the encrypted data306. In another embodiment, the reference to wrapping key202is an ID of a register of the dedicated registers104which stores the wrapping key202, the reference to wrapped data-encryption key208is an ID of a non-dedicated register (e.g., one of data registers108which stores the wrapped data-encryption key), and the reference to encrypted data306is an ID of a non-dedicated register (e.g., a data register108) or a location in memory. In other embodiments, any one or more of these references may comprise an ID of a dedicated register104, a non-dedicated register (e.g., a data register108), or other memory location. In various embodiments, the reference to the location for the data302may be an ID of a dedicated register, an ID of a non-dedicated register, or other suitable memory location.

As described above, one or more of the parameters of the instruction may be implicit. For example, the data302may be placed in the same register or memory location as the encrypted data306and may overwrite the encrypted data306each time the decrypt key and decrypt data instruction is called. As another example, the data302may be placed in a non-dedicated register or memory location that is different from the non-dedicated register or memory location that stores the encrypted data306each time the instruction is executed. In other examples, one or more of the wrapping key202, wrapped data-encryption key208, or encrypted data306may be accessed from the same register or memory location each time the instruction is executed.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a decrypt key and decrypt data instruction as described herein. In some embodiments, an instruction may implement the functionality of the decrypt key and decrypt data instruction described herein as well as one or more other functions (that is, the flow shown for the decrypt key and decrypt data instruction may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the decrypt key and decrypt data instruction instruction). For example, a cryptographic load instruction may perform the operations of the decrypt key and decrypt data instruction and (in some embodiments) additional operations (e.g., moving the encrypted data306into the location referenced by the decrypt key and decrypt data instruction or moving the data302to a data register108).

FIG. 4Aillustrates a flow of a decrypt key and encrypt pointer instruction in accordance with certain embodiments. In some embodiments, the encryption of the pointer takes place as part of a store operation, where the pointer value is transferred from the processor core to the main memory. In one embodiment, the store operation is executed by the processor core responsive to a cryptographic store instruction called by an application. At a high level, the flow may operate in a manner similar to that described above for the decrypt key and encrypt data instruction, except that the key that is unwrapped is a wrapped pointer-encryption key402(instead of a wrapped data-encryption key208) and a pointer404(rather than data302) is encrypted by the unwrapped pointer-encryption key. Thus, execution of the decrypt key and encrypt pointer instruction by the processor may include identifying a wrapping key400(which for a particular cryptographic context or application could be the same wrapping key202used to encrypt/decrypt a data encryption pointer, or it could be a different wrapping key), a wrapped pointer-encryption key402, and a pointer404specified by the instruction and performing a decrypt key and encrypt pointer operation406to generate encrypted pointer408. Operation406may include using the wrapping key400to decrypt the wrapped pointer-encryption key402to extract a pointer-encryption key, and then using the unwrapped pointer-encryption key to encrypt the pointer404to generate the encrypted pointer408. The options described above for the various parameters of the decrypt key and encrypt data instruction may similarly apply to the decrypt key and encrypt pointer instruction. For example, the instruction may specify the wrapping key400, wrapped pointer-encryption key402, pointer404, and location to store encrypted pointer408in a manner that is similar to how the decrypt key and encrypt data instruction may specify the wrapping key202, wrapped data-encryption key208, data302, and location to store encrypted data306respectively.

As used herein, a “pointer” may refer to a data address, such as, e.g., a data block's linear address, physical address, guest physical address, or host physical address. The encryption operation within406may be performed on the entire pointer or on a subset of the bits of the pointer.

In various embodiments, the wrapping key400used to unwrap the wrapped pointer-encryption key402may be a different size than the wrapping key202used to unwrap the wrapped data-encryption key208(e.g., it may have fewer bits). Similarly, the pointer-encryption key may have a different size than the data-encryption key204(e.g., it may have fewer bits). In some embodiments, one or more different cryptographic modes may be used by the decrypt key and encrypt pointer operation406than is used by the decrypt key and encrypt data operation304. As one example, operation304may utilize an AES-ECB, AES-XTS, or AES-CTR mode to encrypt data302, while operation406might use a k-cipher, SIMON, PRINCE, or SPECK cipher to encrypt pointer404.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a decrypt key and encrypt pointer instruction as described herein. In some embodiments, an instruction may implement the functionality of the decrypt key and encrypt pointer instruction described herein as well as one or more other functions (that is, the flow shown for the decrypt key and encrypt pointer instruction may be performed as part of the execution of another instruction e.g., that may be identified by an opcode that is different from the opcode used to identify the decrypt key and encrypt pointer instruction). For example, the decrypt key and encrypt pointer instruction may be performed as part of a memory allocation instruction that allocates a block of memory (e.g., a heap block) to an application.

FIG. 4Billustrates a flow of a decrypt key and decrypt pointer instruction in accordance with certain embodiments. In some embodiments, the decryption of the pointer value takes place as part of a load operation, where the pointer value is transferred from the main memory to the processor core. In one embodiment, the load operation is executed by the processor core responsive to a cryptographic load instruction called by an application. At a high level, the flow may operate in a manner similar to that described above for the decrypt key and decrypt data instruction, except that the key that is unwrapped is a wrapped pointer-encryption key402(instead of a wrapped data-encryption key208) and an encrypted pointer408(rather than encrypted data306) is decrypted by the unwrapped pointer-encryption key. Thus, execution of the decrypt key and decrypt pointer instruction by the processor may include identifying a wrapping key400, a wrapped pointer-encryption key402, and an encrypted pointer408specified by the instruction and performing a decrypt key and decrypt pointer operation410to generate pointer404. Operation410may include using the wrapping key400to decrypt the wrapped pointer-encryption key402to extract a pointer-encryption key, and then using the unwrapped pointer-encryption key to decrypt the encrypted pointer408to generate the pointer404. The options described above for the various parameters of the decrypt key and decrypt data instruction may similarly apply to the decrypt key and decrypt pointer instruction. For example, the instruction may specify one or more of wrapping key400, wrapped pointer-encryption key402, encrypted pointer408, and location to store pointer404in a manner that is similar to how the decrypt key and decrypt data instruction may specify the wrapping key202, wrapped data-encryption key208, encrypted data306, and location to store data302respectively.

Similar to the embodiment described above with respect to operation406, the decryption operation within operation410with respect to the encrypted pointer408may be performed on the entire encrypted pointer408or on a subset of the bits of the encrypted pointer408. For example, in some embodiments, an encrypted pointer408may comprise an encrypted portion and an unencrypted portion, and only the encrypted portion is decrypted during operation410.

In some embodiments, one or more different cryptographic modes may be used by the decrypt key and decrypt pointer operation410than is used by the decrypt key and decrypt data operation308. As one example, operation308may utilize an AES-ECB, AES-XTS, or AES-CTR mode to decrypt encrypted data306, while operation410might use a k-cipher, SIMON, PRINCE, or SPECK cipher to decrypt encrypted pointer408.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a decrypt key and decrypt pointer instruction as described herein. In some embodiments, an instruction may implement the functionality of the decrypt key and decrypt pointer instruction described herein as well as one or more other functions (that is, the flow shown for the decrypt key and decrypt pointer instruction may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the decrypt key and decrypt pointer instruction). For example, the operations of the decrypt key and decrypt pointer instruction may be performed during any type of instruction that requests data from memory (e.g., main memory122), such as a cryptographic load instruction.

FIG. 5Aillustrates a flow of a generate derived key and encrypt data instruction in accordance with certain embodiments. Execution of the generate derived key and encrypt data instruction by the processor may include identifying a master key502, context information504, and data506specified by the instruction and performing a generate derived key and encrypt data operation508to generate encrypted data510. Operation508may include using the master key502to encrypt the context information504to generate a derived key and then using the derived key to encrypt the data506to generate the encrypted data510.

In some embodiments, the context information is not secret information. For example, the context information may include a software object identifier (e.g., a unique identifier for a data object among a plurality of identifiers for a plurality of data objects). In some embodiments, in addition to the software object identifier, the context information could include one or more of a version or a type of the data object (e.g., one value may signify an integer, another value may signify a float, another value may signify a complex struct, etc.). Thus, in some embodiments, the context information may include a combination of different metadata associated with a particular object.

In some embodiments, the context information does not need to be stored by the software application requesting encryption of the data506. For example, the context information may be computed on the fly or obtained from some property of the application, such as a running program counter. Accordingly, a software application may use the master key502and various different instances of context information504(e.g., object IDs) to generate any number of derived keys that may each be used to encrypt different objects without having to store the derived keys.

In an embodiment, the parameters of the generate derived key and encrypt data instruction may include a reference to master key502, a reference to context information504, and a reference to data506. In some embodiments, the parameters may also include a reference to a location at which the encrypted data510is to be stored. In yet other embodiments, the parameters may additionally or alternatively include a reference to a location at which the derived key is to be stored (e.g., for provision to a function that does not have access to the master key502but does have access to the encrypted data510). In various embodiments, one or more of the parameters may be implicit rather than explicit, such that the processor102is configured to access the same register or memory location (e.g., in main memory122) to obtain or store the associated operator (e.g.,502,504,506, or510) each time the generate derived key and encrypt data instruction is executed.

In an embodiment, the reference to master key502is an ID of a register of dedicated registers104which stores the master key502, an ID of a non-dedicated register, or other memory location. In various embodiments, the reference to context information504may be an ID of a register, a memory location, or an immediate operand (e.g., the value of the context information504is provided in the encoding of the instruction). In an embodiment, the reference to data506is an ID of a non-dedicated register (e.g., a data register108) or a location in memory. In various embodiments, the reference to the location for the encrypted data510may be an ID of a dedicated register, an ID of a non-dedicated register, or other suitable memory location.

As described above, one or more of the parameters of the instruction may be implicit. For example, the encrypted data510may be placed in the same register or memory location as the data506and may overwrite the data506each time the generate derived key and encrypt data instruction is called. As another example, the encrypted data510may be placed in a non-dedicated register or memory location that is different from the non-dedicated register or memory location that stores the data506each time the instruction is executed. In other examples, one or more of the master key502, context information504, or data506may be accessed from the same register or memory location each time the instruction is executed.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a generate derived key and encrypt data instruction as described herein. In some embodiments, an instruction may implement the functionality of the generate derived key and encrypt data instruction described herein as well as one or more other functions (that is, the flow shown for the generate derived key and encrypt data instruction may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the generate derived key and encrypt data instruction instruction). For example, an instruction may perform the operations of the generate derived key and encrypt data instruction as well as communicate the derived key to another entity (e.g., a child function).

FIG. 5Billustrates a flow of a generate derived key and decrypt data instruction in accordance with certain embodiments. Execution of the generate derived key and decrypt data instruction by the processor may include identifying a master key502, context information504, and encrypted data510specified by the instruction and performing a generate derived key and decrypt data operation512to generate data506. Operation512may include using the master key502to encrypt the context information504to generate a derived key and then using the derived key to decrypt the encrypted data510to generate the data506.

In an embodiment, the parameters of the generate derived key and decrypt data instruction may include a reference to master key502, a reference to context information504, and a reference to encrypted data510. In some embodiments, the parameters may also include a reference to a location at which the data506is to be stored. These references may be specified in any suitable manner, such as any of those described above with respect toFIG. 5Aor in other suitable manner. In various embodiments, one or more of the parameters may be implicit rather than explicit.

In a particular embodiment, a specific opcode within an instruction may identify the instruction as a generate derived key and decrypt data instruction as described herein. In some embodiments, an instruction may implement the functionality of the generate derived key and decrypt data instruction described herein as well as one or more other functions (that is, the flow shown for the generate derived key and decrypt data instruction may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the generate derived key and decrypt data instruction instruction).

FIG. 6Aillustrates a flow of a generate derived key and encrypt pointer instruction in accordance with certain embodiments. The generate derived key and encrypt pointer instruction may have any of the characteristics of the generate derived key and encrypt data instruction described herein, but may operate via operation604on a pointer602to generate an encrypted pointer606(rather than operating on user data). In various embodiments, one or more of the cryptographic modes used by the instruction to generate the derived key and encrypted pointer may also vary from the one or more cryptographic modes used by the generate derived key and encrypt data instruction.

FIG. 6Billustrates a flow of a generate derived key and decrypt pointer instruction in accordance with certain embodiments. The generate derived key and decrypt pointer instruction may have any of the characteristics of the generate derived key and decrypt data instruction described herein, but may operate via operation608on an encrypted pointer606to decrypt a pointer610(rather than operating on user data). In various embodiments, one or more of the cryptographic modes used by the instruction to generate the derived key and decrypted pointer may also vary from the one or more cryptographic modes used by the generate derived key and encrypt data instruction.

In various embodiments, a specific opcode within an instruction may identify the instruction as a generate derived key and encrypt pointer instruction or a generate derived key and decrypt pointer instruction as described herein. In some embodiments, an instruction may implement the functionality of either of these instructions as well as one or more other functions (that is, the flows shown may be performed as part of the execution of another instruction, e.g., that may be identified by an opcode that is different from the opcode used to identify the generate derived key and encrypt pointer instruction or generate derived key and decrypt pointer instruction).

FIG. 7illustrates a data space704comprising objects712(e.g.,712(1),712(2), . . .712(N)) encrypted using derived keys714(e.g.,714(1),714(2), . . .714(N)) based on a master key708in accordance with certain embodiments. In this embodiment, a parent function702has access to a master key708(which may have any of the characteristics of master key502) and context information, such as object IDs710. Parent function702may be any suitable application, such as an operating system, hypervisor, virtual machine monitor (VMM), or other application at the root of a hierarchy of privileges.

Use of the master key708and the various object IDs710enable the parent function to create and manage many cryptographically isolated objects (e.g., millions of objects712) in a scalable fashion. An object is simply a collection of data and may be, e.g., as small as one byte or as large as an entire virtual machine. The data of each object712is encrypted with a different derived key714based on the master key708and the ID of the object and can be accessed by the parent function702without the parent function702having to store the derived keys714for all of the objects. For example, when accessing an object712, the parent function702may call a generate derived key and encrypt data instruction or a generate derived key and decrypt data instruction as described above in connection withFIGS. 5A and 5B. This may save a large amount of memory space and/or improve access latency. Such embodiments may effectively resolve key management scalability issues that arise when the number of cryptographically isolated objects that need to be simultaneously accessed is very large.

In addition to being accessible by the parent function702(e.g., using the instructions depicted inFIGS. 5A and 5B), each object may also be accessed by a separate child function. For example, the parent function702may communicate the derived key for a particular object to a child function706, and the child function706may access that object using the derived key. For example, a child function706may access an object using regular encrypted load and store instruction (e.g., load and store instructions that do not involve key wrapping and unwrapping operations). Thus, software objects712may maintain their data and state encrypted using a master key708and a derived key714.

In summary, the embodiment shown inFIG. 7may support the cryptographic isolation of a very large number of objects, where each function (whether parent function702or child function706) associated with the objects only needs to store and manage a single key only (master key708for the parent function702and a derived key714for the child function706).

In a particular embodiment, the parent function702may have access to a signed certificate that enables the parent function702to write to the objects within a data region without suffering integrity violations. However, a child function706may only access its own object with a derived key714and if it tries to access another object, it will trigger an integrity violation.

FIG. 8illustrates a hierarchy800of secrets S1-S5in accordance with certain embodiments. The instructions illustrated inFIGS. 2-6(or a subset thereof) may be used to create this hierarchy of secrets, where a secret defines a scope of access and a function may only access the data which is within its scope.

In the embodiment depicted, a root secret S1is generated and used as a wrapping key for wrapping and unwrapping secrets S2and S3. In a similar manner, secret S2is used as a wrapping key for wrapping or unwrapping secrets S4and S5and thus may be considered a root secret to secrets S4and S5(as may root secret S1). In general, access to a particular root secret enables access to any secret that is a descendant of that root secret within the hierarchy800. Secrets (not depicted inFIG. 8) which are not wrapping keys are used to encrypt data. For example, secret S2may be used for wrapping a first set of one or more encryption keys which are used to encrypt data, secret S3may be used for wrapping a second set of one or more encryption keys which are used to encrypt other data, secret S4may be used for wrapping a third set of one or more encryption keys which are used to encrypt yet other data, and so on.

A function F1has access to all data in the hierarchy800that has its encryption bound to secrets S2, S4, or S5(that is, such data is within the scope of F1). Because F1has access to S2, it may also obtain access to secrets S4and S5(by using S2to unwrap an encrypted representation of S5or encrypted S4). Function F2, however, is given access to S5only (and is not able to access secrets S2, S3, and S4) and thus has access only to the data that has its encryption bound to secret S5. Similarly function F3is only given access to secret S3, which prevents it from accessing data bound to secrets S2, S4, or S5. The functions may utilize any suitable instructions referenced above to unwrap other secrets (e.g., S2, S3, etc.) and/or encryption keys wrapped using the secrets and encrypt or decrypt data using such encryption keys.

FIG. 9Aillustrates a flow for performing a cryptographic load instruction in accordance with certain embodiments. The operations of the flow may be performed by any suitable processor.

At902, a cryptographic load instruction is decoded. At904, encrypted data referenced by the instruction is retrieved from memory (e.g.,122). At906, a data encryption key referenced by the instruction is unwrapped by a wrapping key referenced by the instruction. At908, the encrypted data is decrypted using the unwrapped data encryption key. At910, the decrypted data is placed into a register of the processor.

FIG. 9Billustrates a flow for performing a cryptographic store instruction in accordance with certain embodiments. The operations of the flow may be performed by any suitable processor.

At952, a cryptographic store instruction is decoded. At954, data is retrieved from a register. At956, a data encryption key referenced by the instruction is unwrapped by a wrapping key referenced by the instruction. At958, the data is encrypted using the unwrapped data encryption key. At960, the decrypted data is stored (e.g., placed into a memory address or register specified by the instruction).

The flows described inFIGS. 2A, 2B, 3A, 3B, 4A, 4B, 5A, 5B, 6A, 6B, 9A and 9Bare merely representative of operations or communications that may occur in particular embodiments. In other embodiments, additional operations or communications may be performed in the flows. Various embodiments of the present disclosure contemplate any suitable signaling mechanisms for accomplishing the functions described herein. Some of the operations illustrated inFIGS. 2A, 2B, 3A, 3B, 4A, 4B, 5A, 5B, 6A, 6B, 9A and 9Bmay be repeated, combined, modified, or deleted where appropriate. Additionally, operations may be performed in any suitable order without departing from the scope of particular embodiments.

FIGS. 10-13are block diagrams of exemplary computer architectures that may be used in accordance with any of the 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 inFIGS. 10-13.

FIG. 10is an example illustration of a processor according to an embodiment. Processor1000is an example of a type of hardware device that can be used in connection with the implementations shown and described herein (e.g., processor102). Processor1000may 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 processor1000is illustrated inFIG. 10, a processing element may alternatively include more than one of processor1000illustrated inFIG. 10. Processor1000may be a single-threaded core or, for at least one embodiment, the processor1000may be multi-threaded in that it may include more than one hardware thread context (or “logical processor”) per core.

FIG. 10also illustrates a memory1002coupled to processor1000in accordance with an embodiment. Memory1002is an example of a type of hardware device that can be used in connection with the implementations shown and described herein (e.g., main memory122). Memory1002may 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).

Processor1000can execute any type of instructions associated with algorithms, processes, or operations detailed herein. Generally, processor1000can transform an element or an article (e.g., data) from one state or thing to another state or thing.

Code1004, which may be one or more instructions to be executed by processor1000, may be stored in memory1002, 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, processor1000can follow a program sequence of instructions indicated by code1004. Each instruction enters a front-end logic1006and is processed by one or more decoders1008. 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 logic1006also includes register renaming logic1010and scheduling logic1012, which generally allocate resources and queue the operation corresponding to the instruction for execution.

Processor1000can also include execution logic1014having a set of execution units1016a,1016b,1016n, 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 logic1014performs the operations specified by code instructions.

After completion of execution of the operations specified by the code instructions, back-end logic1018can retire the instructions of code1004. In one embodiment, processor1000allows out of order execution but requires in order retirement of instructions. Retirement logic1020may take a variety of known forms (e.g., re-order buffers or the like). In this manner, processor1000is transformed during execution of code1004, at least in terms of the output generated by the decoder, hardware registers and tables utilized by register renaming logic1010, and any registers (not shown) modified by execution logic1014.

Although not shown inFIG. 10, a processing element may include other elements on a chip with processor1000. For example, a processing element may include memory control logic along with processor1000. 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 processor1000.

FIG. 11Ais 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. 11Bis 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 inFIGS. 11A-11Billustrate 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.

InFIG. 11A, a processor pipeline1100includes a fetch stage1102, a length decode stage1104, a decode stage1106, an allocation stage1108, a renaming stage1110, a schedule (also known as a dispatch or issue) stage1112, a register read/memory read stage1114, an execute stage1116, a write back/memory write stage1118, an exception handling stage1122, and a commit stage1124.

FIG. 11Bshows processor core1190including a front end unit1130coupled to an execution engine unit1150, and both are coupled to a memory unit1170. Processor core1190and memory unit1170are examples of the types of hardware that can be used in connection with the implementations shown and described herein (e.g., processor102, main memory122). The core1190may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core1190may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like. In addition, processor core1190and its components represent example architecture that could be used to implement logical processors and their respective components.

The front end unit1130includes a branch prediction unit1132coupled to an instruction cache unit1134, which is coupled to an instruction translation lookaside buffer (TLB) unit1136, which is coupled to an instruction fetch unit1138, which is coupled to a decode unit1140. The decode unit1140(or decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decode unit1140may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read only memories (ROMs), etc. In one embodiment, the core1190includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in decode unit1140or otherwise within the front end unit1130). The decode unit1140is coupled to a rename/allocator unit1152in the execution engine unit1150.

The execution engine unit1150includes the rename/allocator unit1152coupled to a retirement unit1154and a set of one or more scheduler unit(s)1156. The scheduler unit(s)1156represents any number of different schedulers, including reservations stations, central instruction window, etc. The scheduler unit(s)1156is coupled to the physical register file(s) unit(s)1158. Each of the physical register file(s) units1158represents 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) unit1158comprises 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 units1158are examples of the types of hardware that can be used in connection with the implementations shown and described herein. The physical register file(s) unit(s)1158is overlapped by the retirement unit1154to 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 unit1154and the physical register file(s) unit(s)1158are coupled to the execution cluster(s)1160. The execution cluster(s)1160includes a set of one or more execution units1162and a set of one or more memory access units1164. The execution units1162may 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 units1162may also include an address generation unit (e.g.,1122) to calculate addresses used by the core to access main memory (e.g., memory unit1170) and a page miss handler (PMH).

The scheduler unit(s)1156, physical register file(s) unit(s)1158, and execution cluster(s)1160are 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)1164). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue/execution and the rest in-order.

The set of memory access units1164is coupled to the memory unit1170, which includes a data TLB unit1172coupled to a data cache unit1174coupled to a level 2 (L2) cache unit1176. In one exemplary embodiment, the memory access units1164may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit1172in the memory unit1170. The instruction cache unit1134is further coupled to a level 2 (L2) cache unit1176in the memory unit1170. The L2 cache unit1176is coupled to one or more other levels of cache and eventually to a main memory. In addition, a page miss handler may also be included in core1190to look up an address mapping in a page table if no match is found in the data TLB unit1172.

By way of example, the exemplary register renaming, out-of-order issue/execution core architecture may implement the pipeline1100as follows: 1) the instruction fetch1138performs the fetch and length decoding stages1102and1104; 2) the decode unit1140performs the decode stage1106; 3) the rename/allocator unit1152performs the allocation stage1108and renaming stage1110; 4) the scheduler unit(s)1156performs the schedule stage1112; 5) the physical register file(s) unit(s)1158and the memory unit1170perform the register read/memory read stage1114; the execution cluster1160perform the execute stage1116; 6) the memory unit1170and the physical register file(s) unit(s)1158perform the write back/memory write stage1118; 7) various units may be involved in the exception handling stage1122; and 8) the retirement unit1154and the physical register file(s) unit(s)1158perform the commit stage1124.

FIG. 12illustrates a computing system1200that is arranged in a point-to-point (PtP) configuration according to an embodiment. In particular,FIG. 12shows 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 (e.g., computing device100) herein may be configured in the same or similar manner as computing system1200.

Processors1270and1280may be implemented as single core processors1274aand1284aor multi-core processors1274a-1274band1284a-1284b. Processors1270and1280may each include a cache1271and1281used 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 system1200. Moreover, processors1270and1280are examples of the types of hardware that can be used in connection with the implementations shown and described herein (e.g., processor102).

Processors1270and1280may also each include integrated memory controller logic (MC)1272and1282to communicate with memory elements1232and1234, which may be portions of main memory locally attached to the respective processors. In alternative embodiments, memory controller logic1272and1282may be discrete logic separate from processors1270and1280. Memory elements1232and/or1234may store various data to be used by processors1270and1280in achieving operations and functionality outlined herein.

Processors1270and1280may be any type of processor, such as those discussed in connection with other figures. Processors1270and1280may exchange data via a point-to-point (PtP) interface1250using point-to-point interface circuits1278and1288, respectively. Processors1270and1280may each exchange data with an input/output (I/O) subsystem1290via individual point-to-point interfaces1252and1254using point-to-point interface circuits1276,1286,1294, and1298. I/O subsystem1290may also exchange data with a high-performance graphics circuit1238via a high-performance graphics interface1239, using an interface circuit1292, which could be a PtP interface circuit. In one embodiment, the high-performance graphics circuit1238is 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 subsystem1290may also communicate with a display1233for displaying data that is viewable by a human user. In alternative embodiments, any or all of the PtP links illustrated inFIG. 12could be implemented as a multi-drop bus rather than a PtP link.

I/O subsystem1290may be in communication with a bus1210via an interface circuit1296. Bus1210may have one or more devices that communicate over it, such as a bus bridge1218, I/O devices1216, audio I/O1224, and processors1215. Via a bus1220, bus bridge1218may be in communication with other devices such as a user interface1222(such as a keyboard, mouse, touchscreen, or other input devices), communication devices1226(such as modems, network interface devices, or other types of communication devices that may communicate through a computer network1260), and/or a data storage device1228. Data storage device1228may store code and data1230, which may be executed by processors1270and/or1280. In alternative embodiments, any portions of the bus architectures could be implemented with one or more PtP links.

The computing system depicted inFIG. 12is 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 inFIG. 12may 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.

Logic may be used to implement any of the flows described herein or functionality of the various components such as computing device100, processor102, processor1000, core1190, system1200, subcomponents of any of these, or other entity or component described herein. “Logic” may refer to hardware, firmware, software and/or combinations of each to perform one or more functions. In various embodiments, logic may include a microprocessor or other processing element operable to execute software instructions, discrete logic such as an application specific integrated circuit (ASIC), a programmed logic device such as a field programmable gate array (FPGA), a storage device containing instructions, combinations of logic devices (e.g., as would be found on a printed circuit board), or other suitable hardware and/or software. Logic may include one or more gates or other circuit components. In some embodiments, logic may also be fully embodied as software. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in storage devices.

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: 1) at least one X, but not Y and not Z; 2) at least one Y, but not X and not Z; 3) at least one Z, but not X and not Y; 4) at least one X and at least one Y, but not Z; 5) at least one X and at least one Z, but not Y; 6) at least one Y and at least one Z, but not X; or 7) 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. Moreover, such phrases are not necessarily referring to the same embodiment.

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.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of this disclosure. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims.

Example 1 may comprise a processor comprising a plurality of registers; and a processor core comprising circuitry, the processor core to execute a first instruction requesting access to a parameter associated with data for storage in a main memory coupled to the processor, the first instruction including a reference to the parameter, a reference to a wrapping key, and a reference to an encrypted encryption key, wherein execution of the first instruction comprises decrypting the encrypted encryption key using the wrapping key to generate a decrypted encryption key; requesting transfer of the data between the main memory and the processor core; and performing a cryptographic operation on the parameter using the decrypted encryption key.

Example 2 may comprise the subject matter of example 1, wherein the parameter comprises at least one of the data, a linear address of the data, a physical address of the data, a software object identifier, and a software object type.

Example 3 may comprise the subject matter of any of examples 1-2, wherein the first instruction comprises a cryptographic store instruction, the parameter comprises plaintext data, the cryptographic operation comprises encryption of the plaintext data to generate the data for storage in the main memory, and requesting transfer of the data comprises requesting transfer, from the processor core to the main memory, of the data for storage in the main memory.

Example 4 may comprise the subject matter of any of examples 1-2, wherein the first instruction comprises a cryptographic load instruction, the parameter comprises encrypted data stored in the main memory, requesting transfer of the data comprises requesting transfer of the encrypted data from the main memory to the processor core, and the cryptographic operation comprises decryption of the encrypted data.

Example 5 may comprise the subject matter of any of examples 1-4, wherein the parameter comprises the data for storage in the main memory and execution of the first instruction further comprises placing the parameter into a register of the plurality of registers.

Example 6 may comprise the subject matter of any of examples 1-5, wherein the parameter comprises an encrypted pointer referencing the data for storage in the main memory.

Example 7 may comprise the subject matter of any of examples 1-6, wherein the plurality of registers comprise a plurality of data registers and a plurality of registers dedicated to storing cryptographic keys, and wherein the reference to the wrapping key comprises an identifier of a register of the plurality of registers dedicated to storing cryptographic keys.

Example 8 may comprise the subject matter of example 7, wherein the reference to the encrypted encryption key comprises an identifier of a second register of the plurality of registers dedicated to storing cryptographic keys.

Example 9 may comprise the subject matter of any of examples 1-8, wherein the parameter comprises an object identifier of a plurality of object identifiers, the object identifier is associated with the data for storage in the main memory, and the wrapping key comprises a master key used by a parent function to encrypt the plurality of object identifiers to generate a plurality of derived keys to be distributed to a plurality of child functions.

Example 10 may comprise the subject matter of example 9, wherein the processor is further to execute an instruction issued by a child function of the plurality of child functions, wherein the instruction issued by the child function includes a reference to a derived key of the plurality of derived keys and a reference to data encrypted by the derived key.

Example 11 may comprise the subject matter of any of examples 1-10, wherein the processor is to implement a hierarchy of encryption keys, wherein a first function having access to a first wrapping key that is a root of a second wrapping key obtains access to data encrypted using an encryption key wrapped by the first wrapping key and data encrypted using a second encryption key wrapped by the second wrapping key and wherein a second function having access to the second wrapping key but not the first wrapping key obtains access to data encrypted using the second encryption key but not data encrypted using the first encryption key.

Example 12 may comprise the subject matter of any of examples 1-11, wherein the processor core is to execute a second instruction, the second instruction including a reference to the wrapping key and a reference to the encryption key, wherein execution of the second instruction comprises encrypting the encryption key using the wrapping key to generate the encrypted encryption key; and outputting the encrypted encryption key.

Example 13 may comprise the subject matter of any of examples 1-12, further comprising one or more of: a battery communicatively coupled to the processor, a display communicatively coupled to the processor, or a network interface communicatively coupled to the processor.

Example 14 may comprise a method comprising executing, by a core of a processor, a first instruction requesting access to a parameter associated with data for storage in a main memory coupled to the processor, the first instruction including a reference to the parameter, a reference to a wrapping key, and a reference to an encrypted encryption key, wherein execution of the first instruction comprises decrypting the encrypted encryption key using the wrapping key to generate a decrypted encryption key; requesting transfer of the data between the main memory and the processor core; and performing a cryptographic operation on the parameter using the decrypted encryption key.

Example 15 may comprise the subject matter of example 14, wherein the parameter comprises at least one of the data, a linear address of the data, a physical address of the data, a software object identifier, and a software object type.

Example 16 may comprise the subject matter of any of examples 14-15, wherein the first instruction comprises a cryptographic store instruction, the parameter comprises plaintext data, the cryptographic operation comprises encryption of the plaintext data to generate the data for storage in the main memory, and requesting transfer of the data comprises requesting transfer, from the processor core to the main memory, of the data for storage in the main memory.

Example 17 may comprise the subject matter of any of examples 14-15, wherein the first instruction comprises a cryptographic load instruction, the parameter comprises encrypted data stored in the main memory, requesting transfer of the data comprises requesting transfer of the encrypted data from the main memory to the processor core, and the cryptographic operation comprises decryption of the encrypted data.

Example 18 may comprise the subject matter of any of examples 14-17, wherein the parameter comprises the data for storage in the main memory and execution of the first instruction further comprises placing the parameter into a register of the plurality of registers.

Example 19 may comprise the subject matter of any of examples 1-5, wherein the parameter comprises an encrypted pointer referencing the data for storage in the main memory.

Example 20 may comprise the subject matter of any of examples 14-19, wherein the processor comprises a plurality of registers and the plurality of registers comprise a plurality of data registers and a plurality of registers dedicated to storing cryptographic keys, and wherein the reference to the wrapping key comprises an identifier of a register of the plurality of registers dedicated to storing cryptographic keys.

Example 21 may comprise the subject matter of example 20, wherein the reference to the encrypted encryption key comprises an identifier of a second register of the plurality of registers dedicated to storing cryptographic keys.

Example 22 may comprise the subject matter of any of examples 14-21, wherein the parameter comprises an object identifier of a plurality of object identifiers, the object identifier is associated with the data for storage in the main memory, and the wrapping key comprises a master key used by a parent function to encrypt the plurality of object identifiers to generate a plurality of derived keys to be distributed to a plurality of child functions.

Example 23 may comprise the subject matter of example 22, further comprising executing an instruction issued by a child function of the plurality of child functions, wherein the instruction issued by the child function includes a reference to a derived key of the plurality of derived keys and a reference to data encrypted by the derived key.

Example 24 may comprise the subject matter of any of examples 14-23, further comprising implementing a hierarchy of encryption keys, wherein a first function having access to a first wrapping key that is a root of a second wrapping key obtains access to data encrypted using an encryption key wrapped by the first wrapping key and data encrypted using a second encryption key wrapped by the second wrapping key and wherein a second function having access to the second wrapping key but not the first wrapping key obtains access to data encrypted using the second encryption key but not data encrypted using the first encryption key.

Example 25 may comprise the subject matter of any of examples 14-24, further comprising executing a second instruction, the second instruction including a reference to the wrapping key and a reference to the encryption key, wherein execution of the second instruction comprises encrypting the encryption key using the wrapping key to generate the encrypted encryption key; and outputting the encrypted encryption key.

Example 26 may comprise the subject matter of any of examples 14-25, further comprising one or more of: communicatively coupling a battery to the processor, communicatively coupling a display to the processor, or communicatively coupling a network interface to the processor.

Example 27 may comprise one or more non-transitory computer-readable media with code stored thereon, wherein the code is executable to cause a processor to execute a first instruction requesting access to a parameter associated with data for storage in a main memory coupled to a processor, the first instruction including a reference to the parameter, a reference to a wrapping key, and a reference to an encrypted encryption key, wherein execution of the first instruction comprises decrypting the encrypted encryption key using the wrapping key to generate a decrypted encryption key; requesting transfer of the data between the main memory and the processor core; and performing a cryptographic operation on the parameter using the decrypted encryption key.

Example 28 may comprise the subject matter of example 27, wherein the parameter comprises at least one of the data, a linear address of the data, a physical address of the data, a software object identifier, and a software object type.

Example 29 may comprise the subject matter of any of examples 27-28, wherein the first instruction comprises a cryptographic store instruction, the parameter comprises plaintext data, the cryptographic operation comprises encryption of the plaintext data to generate the data for storage in the main memory, and requesting transfer of the data comprises requesting transfer, from the processor core to the main memory, of the data for storage in the main memory.

Example 30 may comprise the subject matter of any of examples 27-28, wherein the first instruction comprises a cryptographic load instruction, the parameter comprises encrypted data stored in the main memory, requesting transfer of the data comprises requesting transfer of the encrypted data from the main memory to the processor core, and the cryptographic operation comprises decryption of the encrypted data.

Example 31 may comprise the subject matter of any of examples 27-30, wherein the parameter comprises the data for storage in the main memory and execution of the first instruction further comprises placing the parameter into a register of the plurality of registers.

Example 32 may comprise the subject matter of any of examples 27-31, wherein the parameter comprises an encrypted pointer referencing the data for storage in the main memory.

Example 33 may comprise the subject matter of any of examples 27-32, wherein the processor comprises a plurality of registers, the plurality of registers comprise a plurality of data registers and a plurality of registers dedicated to storing cryptographic keys, and wherein the reference to the wrapping key comprises an identifier of a register of the plurality of registers dedicated to storing cryptographic keys.

Example 34 may comprise the subject matter of example 33, wherein the reference to the encrypted encryption key comprises an identifier of a second register of the plurality of registers dedicated to storing cryptographic keys.

Example 35 may comprise the subject matter of any of examples 27-34, wherein the parameter comprises an object identifier of a plurality of object identifiers, the object identifier is associated with the data for storage in the main memory, and the wrapping key comprises a master key used by a parent function to encrypt the plurality of object identifiers to generate a plurality of derived keys to be distributed to a plurality of child functions.

Example 36 may comprise the subject matter of example 35, wherein the code is executable to cause the processor to execute an instruction issued by a child function of the plurality of child functions, wherein the instruction issued by the child function includes a reference to a derived key of the plurality of derived keys and a reference to data encrypted by the derived key.

Example 37 may comprise the subject matter of any of examples 27-36, wherein the code is executable to cause the processor to implement a hierarchy of encryption keys, wherein a first function having access to a first wrapping key that is a root of a second wrapping key obtains access to data encrypted using an encryption key wrapped by the first wrapping key and data encrypted using a second encryption key wrapped by the second wrapping key and wherein a second function having access to the second wrapping key but not the first wrapping key obtains access to data encrypted using the second encryption key but not data encrypted using the first encryption key.

Example 38 may comprise the subject matter of any of examples 27-37, wherein the code is executable to cause the processor to execute a second instruction, the second instruction including a reference to the wrapping key and a reference to the encryption key, wherein execution of the second instruction comprises encrypting the encryption key using the wrapping key to generate the encrypted encryption key; and outputting the encrypted encryption key.