EP4684315A1

EP4684315A1 - Automatic shadowing for nonvolatile memory express (nvme) inline encryption

Info

Publication number: EP4684315A1
Application number: EP24708913.9A
Authority: EP
Inventors: Kishalay Haldar; Tanya Mahajan; Amit Gil
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2023-03-18
Filing date: 2024-01-05
Publication date: 2026-01-28
Also published as: CN120858359A; KR20250160139A; WO2024196453A1; WO2024196453A9

Abstract

Various embodiments include methods that may be implemented in an inline cryptographic module of a nonvolatile memory express (NVMe) device. The inline cryptographic module of a processing system for a NVMe device may automatically shadow all active PRPs within the NVMe device. In addition, a computing device may be configured to selectively encrypt data for storage using the inline encryption circuits by distinguishing data communicated over a PCIe link from driver, readout, page and buffer address data communicated over the PCIe link, and encrypting only the data.

Description

TITLE

Automatic Shadowing for Nonvolatile Memory Express (NVMe) Inline Encryption

RELATED APPLICATIONS

[0001] This application claims the benefit of priority to India Patent Application No. 202341018627 entitled “AUTOMATIC SHADOWING FOR NONVOLATILE MEMORY EXPRESS (NVME) INLINE ENCRYPTION” filed on March 18, 2023, and to India Patent Application No. 202341032985 entitled “AUTOMATIC SHADOWING FOR NONVOLATILE MEMORY EXPRESS (NVME) INLINE ENCRYPTION” filed on May 10, 2023, the entire contents of all of which are hereby incorporated by reference for all purposes.

BACKGROUND

[0002] The nonvolatile memory express (NVMe) is a protocol designed specifically for solid-state drives (SSDs) to communicate with a computer’s central processing unit (CPU) through a high-speed peripheral component interconnect express (PCIe) bus interface. NVMe is different from traditional storage interfaces, such as serial advanced technology attachment (SATA) or serial attached small computer system interface (SAS), because it was developed to take better advantage of the low latency and high throughput of modem SSDs, which may read and write data much faster than traditional hard disk drives (HDDs). NVMe may also support features such as multiple input/output (I/O) queues and parallelism, which may enable it to deliver much faster random read and write performance than traditional storage interfaces. As a result, NVMe drives are becoming increasingly popular in high-performance computing, data centers, and consumer devices that require fast storage access, such as gaming PCs and laptops. SUMMARY

[0003] Various aspects include methods of providing encryption of data in a nonvolatile memory express (NVMe) memory device that may include selectively encrypting data for storage using an inline encryption circuits by distinguishing data communicated over a PCIe link from driver, readout, page and buffer address data communicated over the PCIe link, and encrypting only the data. Some aspects may further include identifying likely address ranges for based on operations being performed in the NVMe memory device, and storing the likely address ranges in memory, in which distinguishing data communicated over a PCIe link from driver, readout, page and buffer address data communicated over the PCIe link may include recognizing as data for encryption any data with addresses that do not fall within the likely address ranges in memory stored in memory. In some aspects, identifying likely address ranges for based on operations being performed in the NVMe memory device may include maintaining a shadow of only those pages that the NVMe memory device has read in from system memory.

[0004] Various aspects include methods of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol by an inline cryptographic module of a processing system that may include identifying a first transaction from an NVMe device for reading a command entry of a command submission queue, reading command entry data of the command entry, generating a shadow of at least one page- level read/write pointer (PRP) of the command entry data in a first data structure, and modifying the command entry data to enable reading of the shadow of the at least one PRP, thereby generating modified command entry data.

[0005] In some aspects, generating the shadow of the at least one PRP of the command entry data in the first data structure may include generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from the command entry data. [0006] In some aspects, modifying the command entry data to enable reading of the shadow of the at least one PRP may include modifying an address of the at least one PRP of the command entry data to point to the shadow of the at least one PRP.

[0007] In some aspects, generating the shadow of the at least one PRP of the command entry data in the first data structure may include generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure.

[0008] In some aspects, the command entry data includes a reference to an entry for the at least one PRP in the second data structure. Some aspects may further include reading the entry for the at least one PRP in the second data structure, the entry for the at least one PRP in the second data structure including the address of the at least one PRP and the security context for the at least one PRP from the command entry data.

[0009] In some aspects, modifying the command entry data to enable reading of the shadow of the at least one PRP may include removing a reference to an entry for the at least one PRP in a second data structure.

[0010] Some aspects may further include sending the modified command entry data to the NVMe device, identifying a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP, and implementing a cryptographic operation for data associated with the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP.

[0011] Some aspects may further include generating a shadow of a PRP list (PRPL) of the command entry data in the first data structure, and modifying the command entry data to enable reading of the shadow of the PRPL, thereby generating the modified command entry data.

[0012] In some aspects, generating the shadow of the PRPL of the command entry data in the first data structure may include generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command entry data.

[0013] Some aspects may further include sending the modified command entry data to the NVMe device, identifying a second transaction from the NVMe device for reading the shadow of the PRPL, generating a shadow of each PRP of the PRPL in the first data structure, and modifying the each PRP of the PRPL to point to the shadow of the each PRP, generating a modified PRPL.

[0014] In some aspects, generating the shadow of the each PRP of the PRPL in the first data structure may include generating an entry for the each PRP of the PRPL in the first data structure, the entries for the each PRP of the PRPL in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP of the PRPL from an entry of the PRPL in the first data structure.

[0015] Some aspects may further include sending the modified PRPL to the NVMe device, identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP, and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

[0016] In some aspects, modifying the command entry data to enable reading of the shadow of the PRPL may include modifying an address of a PRPL pointer for the PRPL of the command entry data to point to the shadow of the PRPL.

[0017] In some aspects, generating the shadow of the PRPL of the command entry data in the first data structure may include generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure. [0018] Some aspects may further include sending the modified command entry data to the NVMe device, identifying a second transaction from the NVMe device for reading the PRPL, in which generating the shadow of the PRPL of the command entry data in the first data structure occurs in response to identifying the second transaction from the NVMe device, and modifying the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL.

[0019] Some aspects may further include sending the modified PRPL to the NVMe device, identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP, and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

[0020] In some aspects, modifying the command entry data to enable reading of the shadow of the PRPL may include removing a reference to an entry for the PRPL in a second data structure.

[0021] In some aspects, the command entry data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL. Some aspects may further include writing the PRPL pointer to the second data structure at a location associated with the reference to the entry in the second data structure.

[0022] In some aspects, the modified command entry data includes a virtual address. Some aspects may further include fetching a virtual address to physical address mapping for the virtual address in parallel with generating the shadow of the at least one PRP of the command entry data in the first data structure.

[0023] In some aspects, identifying the first transaction from the NVMe device for reading the command entry of the command submission queue may include identifying an address of the transaction that is within at least one range of addresses for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline cryptographic module.

[0024] Various aspects include methods of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol executed by a processing system, may include acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference, writing a cryptographic enable to a command entry of the command for a submission queue, writing the cryptographic key slot reference to the command entry of the command for the submission queue, and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

[0025] Some aspects may further include acquiring a page-level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference, and writing the PRPLT slot reference to the command entry of the command for the submission queue, in which submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue may include submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue.

[0026] In some aspects, the command has more than one page-level read/write pointer (PRP). Some aspects may further include writing a logical block address offset to part of at least one PRP of the command entry of the command for the submission queue, and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue may include submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the at least one PRP having the logical block offset. [0027] In some aspects, data of the command is larger than two system memory pages. Some aspects may further include writing a logical block address offset to part of at least one PRP of a PRP list (PRPL).

[0028] In some aspects, data of the command is larger than two system memory pages. Some aspects may further include writing a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP, and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue may include submitting the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

[0029] In some aspects, data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL. Some aspects may further include writing a PRPL pointer to a PRP of a PRPL.

[0030] Some aspects may further include configuring a first set of one or more registers of an inline cryptographic module corresponding with a number of command submission queues, and setting each of the first set of one or more registers with an address range of a different one of the command submission queues.

[0031] In some aspects, setting each of the first set of one or more registers with the address range of a different one of the command submission queues may include setting each of the first set of one or more registers with a start address and a size of a different one of the command submission queues.

[0032] In some aspects, setting each of the first set of one or more registers with the address range of a different one of the command submission queues may include setting each of the first set of one or more registers with a start address and an end address of a different one of the command submission queues.

[0033] Some aspects may further include configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues, and seting each of the second set of one or more registers with a start address and a size of a different one of the command submission queues.

[0034] Some aspects may further include configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges, and seting each of the second set of one or more registers with a start address and a size of a different one of the exclusive address ranges.

[0035] Further aspects include computing devices including a non-volatile memory express (NVMe) inline cryptographic module configured to perform operations of any of the methods summarized above. Further aspects include computing devices including a processing system configured to perform operations of any of the methods summarized above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate example embodiments of various embodiments, and together with the general description given above and the detailed description given below, serve to explain the features of the claims.

[0037] FIG. 1 is a component block diagram illustrating an example computing device suitable for implementing various embodiments.

[0038] FIG. 2 is a component block diagram illustrating an example inline cryptography nonvolatile memory express (NVMe) system suitable for implementing various embodiments.

[0039] FIG. 3 is a component block diagram illustrating an example inline cryptographic module for implementing various embodiments.

[0040] FIG. 4 is a component block diagram illustrating an example NVMe system that does not include encryption support. [0041] FIG. 5 is a component block diagram illustrating an example NVMe system that includes encryption support in accordance with some embodiments.

[0042] FIG. 6 is a component block diagram illustrating an example NVMe data structure that is suitable for use by some embodiments.

[0043] FIG. 7 is a component block diagram illustrating access blocks that need cyphering and access blocks that should not be cyphered.

[0044] FIGs. 8 through 17 are component block diagrams illustrating various information structures and operations in computing systems configured to implement various embodiments.

[0045] FIG. 18 is a component block diagram illustrating an example inline cryptographic module for implementing various embodiments.

[0046] FIG. 19 is an information structure diagram illustrating an example submission common command format in computing systems configured to implement various embodiments.

[0047] FIG. 20 is an information structure diagram illustrating an example look up table in computing systems configured to implement various embodiments.

[0048] FIG. 21 is a component block and processes flow diagram illustrating a method for implementing an initialization phase for NVMe inline cryptographic processes using shadowing of physical region pages or page-level read/write pointers (PRPs) in computing systems configured to implement various embodiments.

[0049] FIG. 22 is a component block and processes flow diagram illustrating a method for implementing a command creation stage for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. [0050] FIGS. 23 A and 23B are component block and processes flow diagrams illustrating methods for implementing command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0051] FIG. 24 is an information structure diagram illustrating an example submission common command format in computing systems configured to implement various embodiments.

[0052] FIG. 25 is an information structure diagram illustrating an example look up table in computing systems configured to implement various embodiments.

[0053] FIG. 26 is a component block and processes flow diagram illustrating a method for implementing command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0054] FIG. 27 is an information structure diagram illustrating an example of modifying a PRP list in computing systems configured to implement various embodiments.

[0055] FIG. 28 is an information structure diagram illustrating an example look up table in computing systems configured to implement various embodiments.

[0056] FIG. 29 is a component block and processes flow diagram illustrating a method for implementing write command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0057] FIG. 30 is a component block and processes flow diagram illustrating a method for implementing read command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. [0058] FIG. 31 is a component block and processes flow diagram illustrating a method for command completion for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0059] FIG. 32A and 32B are component block and processes flow diagrams illustrating a method for command processes using Peripheral Component Interconnect Express (PCIe) address translation service for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0060] FIG. 33 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0061] FIG. 34 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0062] FIG. 35 is a component block diagram illustrating an example server suitable for implementing various embodiments.

DETAILED DESCRIPTION

[0063] The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0064] Various embodiments include methods, and computing devices implementing such methods, for implementing an inline cryptographic module of a processing system for a nonvolatile memory express (NVMe) device. In some embodiments, the inline cryptographic module may be configured to automatically “shadow” all active physical region pages or page-level read/write pointers (PRPs) and/or scatter gather lists (SGLs) within the NVMe device. The NVMe device may also maintain 32 address ranges in registers that are associated with submission queues and programmed by device drivers during initialization. Access from the device in one of these ranges may indicate that it is trying to read commands from the submission queue (SQ). The data returned may be used to extract PRPs and/or SGLs, which may be used to determine the data that should be encrypted and the data that should remain unencrypted and unaltered.

[0065] The terms “computing device” and “mobile device” are used interchangeably herein to refer to any one or all of cellular telephones, smartphones, personal or mobile multi-media players, personal data assistants (PDA’s), laptop computers, tablet computers, convertible laptop s/tablets (2-in-l computers), smartbooks, ultrabooks, netbooks, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, mobile gaming consoles, wireless gaming controllers, and similar personal electronic devices that include a memory, and a programmable processor. The term “computing device” may further refer to stationary computing devices including personal computers, desktop computers, all-in-one computers, workstations, super computers, mainframe computers, embedded computers, servers, home theater computers, and game consoles.

[0066] Embodiments and examples are described in terms of PRPs for ease of explanation and clarity. However, one of skill in the art would realize that the embodiments and examples described in terms of PRPs may be similarly implemented for and using SGLs in place of PRPs, and that any mention of PRPs are not intended to limit the scope of the claims and specification to exclude SGLs from such embodiments and examples.

[0067] A PRP refers to a data structure or mechanism used in memory management to keep track of the current position within a page of memory. The PRP may indicate an offset or location within a page where the next read or write operation should occur, allowing the system to access and manipulate specific portions of memory pages without having to work with the entire page at once. PRPs may be organized in a PRP list (PRPL), which may be a data structure that maintains a collection or list of PRPs. Each entry in the PRPL may correspond to a particular memory page and may contain the PRP associated with that page. The PRPL may be used to manage multiple PRPs, typically for various pages of memory, within a system.

[0068] The NVMe protocol for memory devices enables a fast and high throughput communication between an NVMe memory device and a processing system. A peripheral component interface express (PCIe) controller may be configured to implement NVMe protocol communications between an NVMe device and components of a processing system.

[0069] There is currently a strong market demand for NVMe inline encryption, which may provide hardware-based encryption of data stored on NVMe-based solid- state drives (SSDs). Inline encryption means that the encryption process happens automatically as data is written to the SSD, without any additional software or hardware intervention. This provides a high level of security without any significant impact on performance. In addition, NVMe Inline Encryption may use Advanced Encryption Standard (AES) with 512-bit or 256-bit keys to encrypt data. The encryption keys may be stored securely in the SSD controller and are not exposed to the host system. This may provide an additional layer of protection against data breaches. In addition, NVMe inline encryption may provide end-to-end encryption of data so that the data is encrypted from the moment it leaves the host system until it is decrypted by the SSD controller. This may help protect data against unauthorized access or theft, both while it is being transferred and while it is stored on the SSD.

[0070] There are many challenges with implementing NVMe inline encryption. For example, there currently is no standard way to encrypt data that is being accessed and stored in an NVMe device in-line, with the encryption process occurring at the same time as the data storage and access. Currently, one must either lobby to change the NVMe specifications, impose impractical restrictions on device drivers, or bear the hefty silicon cost of maintaining a large number of descriptors in order to use inline encryption with an NVMe device. Changing the NVMe specification would require significant effort and may not be feasible in the short term. Imposing restrictions on device drivers may limit the functionality of the device and could lead to compatibility issues.

[0071] Another option is to simply bear the hefty silicon cost of maintaining a large number of descriptors in order to use inline encryption with an NVMe device. Descriptors are data structures that describe the properties of data stored on the device. Maintaining a large number of descriptors may be resource-intensive. As an example of the significant silicon cost, the NVMe sends out Advanced extensible Interface (AXI) access commands for command fetching, descriptor fetching, and user data buffering. The computing system may be required to identify these commands for encryption. Yet, there are 4 million PRPs in a double data rate (DDR) memory and it may be difficult to search the incoming AXI address from that many choices. A conventional solution would need 4MB of SRAM in order to store the PRPs, along with complex search logic, resulting in a significant silicon cost.

[0072] The embodiments may eliminate the need for the costly silicon cost associated with accessing the descriptors. As mentioned above, some embodiments may automatically “shadow” all active PRPs within the NVMe device, maintain 32 address ranges in registers that are associated with submission queues and programmed by device drivers during initialization, and access from the NVMe device in one of these 32 address ranges could indicate that it is trying to read commands from the submission queue (SQ). The data returned could be used to extract PRPs used to determine the data that should be encrypted.

[0073] By maintaining only 32 register address ranges of submission queues, all PRPs may be shadowed inside NVMe device and simplify the search logic for identifying incoming user data buffer accesses. Another benefit or advantage of the embodiments is that the complex search logic of finding PRPs from 4 million possibilities reduces to merely 32 ranges, which may be efficiently implemented in HW. Yet another advantage of the embodiments is that they may significantly reduce the SRAM volume to 8KB (whereas conventional solutions could require 4MB SRAM with a complex search logic beforehand). For these and other reasons, the various embodiments may reduce costs significantly. The embodiments may allow access to inline encryption without sacrificing system cost or performance when using an NVMe device.

[0074] FIG. 1 illustrates a system including a computing device 10 suitable for use with various embodiments. The computing device 10 may include a processing system 12 with one or more processors 14, memory 16, a memory interface 34, an inline cryptographic module 38, a communication interface 18, a storage memory interface 20, a clock controller 30, and an interconnect 32. The computing device 10 may further include a communication component 22, such as a wired or wireless modem, a storage memory 24, an antenna 26 for establishing a wireless communication link, a power manager 28, and a memory 36. The processor 14 may include any of a variety of processing devices, for example a number of processor cores.

[0075] The term “system-on-chip” (SoC) is used herein to refer to a set of interconnected electronic circuits typically, but not exclusively, including a processing device, a memory, and a communication interface. A processing system 12 may include a variety of different types of processors 14 some of which may include multiple processor cores. Non-limiting examples of processors that may be included in a computing device 10 and implemented in or coupled to a processing system 12 include a general purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a secure processing unit (SPU), a neural network processing unit (NPU), a subsystem processor of specific components of the computing device, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, a multicore processor, a controller, and a microcontroller. A processing system 12 may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material in what may be referred to as a system-on-chip (SoC).

[0076] The processing system 12 may be implemented in an SoC and/or may include circuitry in multiple chips coupled to an SoC. The computing device 10 may include more than one processing system 12, thereby increasing the number of processors 14 any one or more of which may include multiple processor cores. The computing device 10 may also include other processors (not shown) that are not associated with the processing system 12. The processors 14 may each be configured for specific purposes that may be the same as or different from other processors 14 of the computing device 10. One or more of the processors 14 and processor cores of the same or different configurations may be grouped together.

[0077] The processing system 12 may be implemented with a bus architecture, represented generally by the bus 32. The bus 32 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 12 and the overall design constraints. The bus 32 links together various circuits including one or more processors 14 and/or hardware components, represented by the processor (or processing circuitry) 14, the illustrated components, and the computer-readable medium / memory (or memory circuitry) 16. The processor(s) 14 may include multiple processors. The memory 16 may include multiple memories. The bus 32 may also link various other circuits, such as a clock controller 30, interface circuitry 18, 20, voltage regulators (not shown), and/or power management circuits (e.g., power manager 28). [0078] The computing device 10 may include any number and combination of memories, such as the memory 16 integral to the processing system 12 and the memory 36 separate from the processing system 12. Any of the memories 16, 36 may be a volatile or non-volatile memory configured for storing data and processorexecutable code for access by the processor 14. The computing device 10 and/or the processing system 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memories such as random access memory (RAM) or main memory, including static RAM (SRAM), such as the memory 16, dynamic RAM (DRAM), such as the memory 36, or cache memory.

[0079] The memories 16, 36 may be configured to temporarily store a limited amount of data. For example, the data may be received from a data sensor or subsystem. As another example, the data may be data and/or processor-executable code instructions that are requested from a non-volatile memory 16, 24, 36 loaded to the memories 16, 36 from the non-volatile memory 16, 24, 36 in anticipation of future access based on a variety of factors. As another example, the data may be intermediary processing data and/or processor-executable code instructions produced by the processor 14 and temporarily stored for future quick access without being stored in non-volatile memory 16, 24, 36.

[0080] The memory interface 34 may work in unison with the memory 36 to enable the computing device 10 to store and retrieve data and processor-executable code on and from the memory 36. The memory interface 34 may control access to the storage memory 36 and allow the processor 14 to read data from and write data to the memory 36.

[0081] The storage memory interface 20 and the storage memory 24 may work in unison to allow the computing device 10 to store data and processor-executable code on a non-volatile storage medium, such as a nonvolatile memory express (NVMe) memory device. The storage memory 24 may be configured much like an embodiment of the memory 16 in which the storage memory 24 may store the data or processor-executable code for access by one or more of the processors 14. The storage memory 24, being non-volatile, may retain the information after the power of the computing device 10 has been shut off. When the power is turned back on and the computing device 10 reboots, the information stored on the storage memory 24 may be available to the computing device 10. The storage memory interface 20 may control access to the storage memory 24 and allow the processor 14 to read data from and write data to the storage memory 24.

[0082] The inline cryptographic module 38 may be configured to implement cryptographic functions, such as encryption and decryption, of data for transactions of the memory storage device 24. Data transmitted between the memory 36 and the storage memory 24 may be encrypted and decrypted by the inline cryptographic module 38 to secure the data stored and the memory storage device 24 by encrypting the data, and make usable, by the SoC, the encrypted data retrieved from the memory storage device 24 by decrypting the data. The inline cryptographic module 38 may be configured to implement hash generation and validation for device hints related to the data transmitted between the memory 36 and the storage memory 24 to assess integrity of the device hints for use in evaluating whether to use the data.

[0083] The power manager 28 may be configured to control power states of one or more power rails (not shown) for power delivery to the components of the processing system 12. In some embodiments, the power manager 28 may be configured to control amounts of power provided to the components of the processing system 12. For example, the power manager 28 may be configured to control connections between components of the processing system 12 and the power rails. As another example, the power manager 28 may be configured to control amounts of power on the power rails connected to the components of the processing system 12. The power manager 28 may be configured as a power management integrated circuit (power management ICs or PMIC). [0084] A clock controller 30 may be configured to control clock signals transmitted to the components of the processing system 12. For example, the clock controller 30 may gate a component of the processing system 12 by disconnecting the component of the processing system 12 from a clock signal and may ungate the component of the processing system 12 by connecting the component of the processing system 12 to the clock signal.

[0085] The interconnect 32 may be a communication fabric, such as a communication bus, configured to communicatively connect the components of the processing system 12. The interconnect 32 may transmit signals between the components of the processing system 12. In some embodiments, the interconnect 32 may be configured to control signals between the components of the processing system 12 by controlling timing and/or transmission paths of the signals.

[0086] Some or all of the components of the computing device 10 and/or the processing system 12 may be arranged differently and/or combined while still serving the functions of the various embodiments. The computing device 10 may not be limited to one of each of the components, and multiple instances of each component may be included in various configurations of the computing device 10.

[0087] FIG. 2 illustrates an example of an inline cryptography NVMe system 200 suitable for implementing various embodiments. With reference to FIGs. 1 and 2, the inline cryptography NVMe system 200 may be implemented in a computing device (e.g., computing device 10 in FIG. 1), include the memory 36, an processing system 202 (e.g., processing system 12 in FIG. 1), and an NVMe device 214 (or NVMe memory device) (e.g., storage memory 24 in FIG. 1) connected to each other by various communication buses.

[0088] The processing system 202, which may be implemented as an SoC, may include one or more processors 14, a peripheral component interface express (PCIe) controller 212 (e.g., storage memory interface 20 in FIG. 1), and an inline cryptographic module 38 connected to each other by various communication buses. The one or more processors 14 may be configured to implement software, such as applications 204, including a high-level operating system, a kernel 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 may manage communication between components of the processing system 202, including the inline cryptographic module 38, and the NVMe device 214. Such communications may include communications for preparation and implementation of NVMe commands from the one or more processors 14 for data transactions, such as read and/or write transactions, at the NVMe device 214.

[0089] The inline cryptographic module 38 may be a hardware module integral to the processing system 202. The inline cryptographic module 38 may implement cryptographic functions, such as encrypting, decrypting, and/or bypassing, for data of the NVMe commands. For example, the inline cryptographic module 38 may encrypt data sent to the NVMe device 214 and decrypt data received from the NVMe device 214. The cryptographic functions implemented by the inline cryptographic module 38 may be of any known, proprietary, and/or to be developed encryption and decryption methods and/or circuitry. For example, the inline cryptographic module 38 may provide per application, folder-based, and/or file-based cryptographic functions. As another example, the inline cryptographic module 38 may implement cryptographic functions using AES with 512-bit or 256-bit keys.

[0090] A software running on the processing system 202, the NVMe driver 208, and/or the application 204, may issue a request to use a specific algorithm for encryption and a set of encryption keys, use a specific security context, and/or ask to send data without encryption. Setting the security context, encryption keys, and/or encryption algorithm may be implemented by any of the software running on the processing system 202, the NVMe driver 208, and/or the application 204 while using a security context, encryption keys, and/or an encryption algorithm to encrypt or decrypt the data can be done by another software entity. [0091] The inline cryptographic module 38 may also support secure key management. In some examples, the inline cryptographic module 38 may function independently of PCIe structures and its different layers, enable scalable storage throughput, and be compliant with NVMe device protocols. In other examples, the inline cryptographic module 38 may be part of the PCIe controller 212. The inline cryptographic module 38 is described further herein.

[0092] FIG. 3 illustrates an example of the inline cryptographic module 38 for implementing various embodiments. With reference to FIGs. 1-3, the inline cryptographic module 38 may be configured with a buffer address lookup structure 300, a security context structure 302, an encryption module 304 and a decryption module 306. The encryption module 304 and the decryption module 306 are described herein as separate components for ease of explanation and clarity consistent with a nonlimiting embodiment. However, such separate descriptions are not intended to limit the scope of the claims and specification and in some implementations and embodiments, the encryption module 304 and the decryption module 306 may be implemented as a single combined module.

[0093] The buffer address lookup structure 300 may be a data structure, such as a table, array, linked list, graph, etc., configured to store various data in association with each other. For example, the buffer address lookup structure 300 may store data of at least a buffer address of the memory 36, referred to herein as buffer address, and an NVMe security identifier (ID) for an NVMe command in association with each other.

[0094] The buffer address may be used for the NVMe command to write out data from the buffer address of the memory 36 to the NVMe device 214 and/or to read in data from the NVMe device 214 to the buffer address of the memory 36.

[0095] The NVMe security ID may be a combination of data, such as an NVMe command submission queue identifier and an NVMe command identifier for the NVMe command. The NVMe command submission queue identifier may identify an NVMe command submission queue to which the NVMe driver 208 may write the NVMe command.

[0096] The NVMe command submission queue may trigger a doorbell signal configured to indicate to the NVMe device 214 that the NVMe command in the NVMe command submission queue is ready for execution when the NVMe command reaches an end of the NVMe command submission queue. The NVMe command ID may identify the NVMe command.

[0097] The buffer address lookup structure 300 may also store data of a sector offset for the NVMe command in association with the buffer address and the NVMe security ID. The sector offset may be used in generation of an initialization vector for a cryptographic function. The initialization vector may be used as input to an encryption algorithm and be configured to affect encryption of data in a maimer in which the data encrypted multiple times may result in different encrypted values. The buffer address lookup structure 300 may store any amount of associated data, such as more than one set of associated data for more than one NVMe command.

[0098] The security context structure 302 may be a data structure, such as a table, array, linked list, graph, etc., configured to store various data in association with each other. For example, the security context structure 302 may store data of the NVMe security ID and a security context for the NVMe command in association with each other. The NVMe security ID in the buffer address lookup structure 300 and the security context structure 302 for the same NVMe command may be the same. The security context may include a combination of security related information, such as an encryption algorithm, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, etc. In some examples, the security context may be provided by an application executed by the processor 14 from the execution of which the NVMe command originates. The security context structure 302 may store any amount of associated data, such as more than one set of associated data for more than one NVMe command. [0099] The buffer address lookup structure 300 and the security context structure 302 may be configured at the inline cryptographic module 38 during an NVMe command submission stage. In some examples, the NVMe driver (e.g., NVMe driver 208 in FIG. 2) may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command issued by a processor (e.g., processor 14). The NVMe driver may provide the inline cryptographic module 38 with the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data as the buffer address lookup structure 300 and the security context structure 302. Such data may include any combination of buffer addresses, NVMe security IDs, sector offsets, and/or security contexts for NVMe commands. In such examples, the NVMe driver may maintain the same address information at two different locations, a processing system memory (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2) and at the buffer address lookup structure 300.

[0100] In some embodiments, the inline cryptographic module 38 may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command from the NVMe driver. The inline cryptographic module 38 may process the NVMe command, extracting the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data as the buffer address lookup structure 300 and the security context structure 302. The inline cryptographic module 38 configuring the buffer address lookup structure 300 and the security context structure 302, rather than the NVMe driver, eliminates the previously described address redundancy issue and maintains data integrity. Further, overhead on software to configure the buffer address lookup structure 300 in the inline cryptographic module 38 is reduced. [0101] The inline cryptographic module 38 may be configured to forward a doorbell signal configured to indicate to an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2) of a pending NVMe command. For example, the inline cryptographic module 38 may update an NVMe command submission queue tail point to a “doorbell” register of the NVMe device. Forwarding the doorbell signal may enable bypassing or foregoing inclusion of software configured to write two doorbells, and may ensure that the operation of the cryptographic module 38 and the NVMe device are synchronized.

[0102] In response to receiving an NVMe transaction from the NVMe device, the inline cryptographic module 38 may use information from the NVMe transaction to implement a cryptographic function for the data of the NVMe transaction. For example, the inline cryptographic module 38 may retrieve a buffer address from the NVMe transaction and use the buffer address to retrieve the associated data, such as the NVMe security ID, from the buffer address lookup structure 300. In some examples, the inline cryptographic module 38 may use the buffer address to retrieve the associated sector offset from the buffer address lookup structure 300. The inline cryptographic module 38 may use the retrieved NVMe security ID to retrieve the associated security context for the NVMe command from the security context structure 302.

[0103] Using the retrieved information, such as the sector offset and/or the security context, the encryption module 304 and/or the decryption module 306 may implement the cryptographic function for the data of the NVMe transaction. For example, the retrieved information may include the security context from the security context structure 302, which may include an encryption algorithm, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, etc. The encryption module 304 may use the retrieved information of the security context to encrypt the data to be sent to the NVMe device for the NVMe transaction. The decryption module 306 may use the retrieved information of the security context to decrypt the data received from the NVMe device for the NVMe transaction.

[0104] In some embodiments, the retrieved information may include the sector offset from the buffer address lookup structure 300. The encryption module 304 may use the retrieved sector offset to generate an initialization vector, and use the initialization vector with the retrieved information of the security context to encrypt the data to be sent to the NVMe device for the NVMe transaction. The decryption module 306 may use the retrieved sector offset to generate an initialization vector, and use the initialization vector with the information of the retrieved information of the security context to decrypt the data received from the NVMe device for the NVMe transaction. The encryption module 304 may input unencrypted data for the NVMe command, one or more encryption keys, and/or an initialization vector to an encryption algorithm and generate encrypted data for the NVMe command. The decryption module 306 may input encrypted data for the NVMe command, one or more encryption keys, and/or an initialization vector to an encryption algorithm and generate decrypted data for the NVMe command.

[0105] FIGs. 4 and 5 illustrate systems suitable for NVMe transactions without implementing NVMe Inline Encryption in FIG. 4 and implementing NVMe Inline Encryption in FIG. 5, which may include new encryption layer that is placed inline to the NVMe transaction flow. NVMe Inline Encryption may provide data confidentiality while maintaining end-to-end performance and low latency. The encryption layer may be deployed at the device side and configured to handle the NVMe command processing and completion, taking advantage of its proximity to the device controller.

[0106] With reference to FIGs. 1-4, FIG. 4 illustrates an example in which the command submission includes: (1) an NVMe Device driver (e.g., NVMe driver 208 in FIG. 2) at a Host 400 (e.g., processing system 12 in FIG. 1, processor 14 in FIGs. 1 and 2, processing system 202 in FIG. 2) writing commands to a submission queue (SQ) 404 at a host memory 402 (e.g., memory 16, 36 in FIG. 1); and (2) the NVMe Device driver (e.g., NVMe driver 208 in FIG. 2) at the Host 400 writing an updated SQ Tail pointer (ptr) (“Tail” in FIG. 4) to a Doorbell 408 (“SQ Tail doorbell” in FIG. 4) (e.g., a “doorbell” register) at the NVMe device 214. The command processing may include: (3) the NVMe Device fetching commands from the SQ 404, and the NVMe Device updating the SQ Head ptr (“Head” in FIG. 4) with a next command; and (4) the NVMe device processing the fetched commands. Command Completion may include: (5) the NVMe Device 214 updating completion (or command or command completion) queue (CQ) Tail ptr (“Tail” in FIG. 4) and writing updated CQ tail ptr to Doorbell; (6) the NVMe device 214 generating a CQ Platform specific interrupt, such as an MSI-X interrupt, for notification of completion status to a host driver; (7) the NVME Device Driver at the Host 400 processing the completion of the command; and (8) the NVME Device Driver at the Host 400 writing a CQ Head ptr (“Head” in FIG. 4) to a Doorbell 410 (“CQ Head doorbell” in FIG. 4) (e.g., a “doorbell” register) at the NVMe device controller 214.

[0107] With reference to FIGs. 1-5, in the example illustrated in FIG. 5, the host memory 402 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2) includes a NVMe-ICE module 500 (e.g., inline cryptographic module 38 in FIGs. 1-3), which may be an encryption/decryption layer between the host driver and the NVMe device controller 214. The Command Submission operations may include: (1) the NVMe Device driver (e.g., NVMe driver 208 in FIG. 2) at the Host 400 (e.g., processing system 12 in FIG. 1, processor 14 in FIGs. 1 and 2, processing system 202 in FIG. 2) writing commands to the submission queue (SQ) 404 at the host memory 402; (2) the NVMe Device driver at the Host 400 configuring the NVMe-ICE module 500 for inlining encryption of NVMe transactions; and (3) the NVMe Device driver at the Host 400 writing an updated SQ Tail ptr (“ Tail” in FIG. 5) to the Doorbell 408 (“SQ Tail doorbell” in FIG. 5) (e.g., a “doorbell” register) at the NVMe device controller 214. The Command Processing operations may include: (4) the NVMe device controller 214 fetching a command from the SQ 404 and updates the SQ head ptr (“Head” in FIG. 5) with a next command; (5) the NVMe device controller 214 processing the command and/or the updated SQ head ptr; and (6) the NVMe-ICE module 500 encrypting/decrypting the data for the command. For example, the NVMe-ICE module 500 may encrypt write data sent to the NVMe device controller 214 for a write command and/or decrypt read data received from the NVMe device controller 214 for a read command. The Command Completion operations may include: (7) the NVMe device controller 214 writing completion of the command to the completion queue (CQ) 406 at the host memory 402 and updating CQ tail ptr (“Tail” in FIG. 5) to doorbell; (8) the NVMe device controller 214 generating a CQ Platform specific interrupt, such as an MSI-X interrupt, for notification of completion status to the host driver; (9) the host 400 processing completion of the command, and (10) the host 400 writing the CQ Head ptr (“Head” in FIG. 5) to the Doorbell 410 (“CQ Head doorbell” in FIG. 5) (e.g., a “doorbell” register) at the NVMe device controller 214.

[0108] The SQ 404 and the CQ 406 are used to manage communications between the Host 400 and the NVMe device 214. The SQ 404 may be used by the Host 400 to queue commands to be sent to the NVMe device 214. These commands may include any command from the NVMe standard, such as read, write, management commands, etc. The CQ 406 may be used by the NVMe device 214 to notify the Host 400 about a completion status of command processed from the SQ 404, such as successful completion or failure to complete. When a command is executed, the NVMe device controller 214 may place a completion entry in the CQ 406 to inform the Host 400 about the completion of the operation. The SQ 404 and CQ 406 may be circular buffers, arrays, etc. for which locations may be statically or dynamically indicated as a starting location (head) and an ending location (tail). An entry at the head of the SQ 404 may be for a next command to be implemented and an entry at the tail of the SQ 404 may be for a last command to be implemented. An entry at the head of the CQ 404 may be for an oldest completed command and an entry at the tail of the CQ 404 may be for a most recently completed command. The SQ 404 and the CQ 406 may be sized to store at least two entries, including thousands of entries, such as 64,000 entries.

[0109] The NVMe-ICE module 500 may provide data security and privacy at the storage level by enabling encryption of data that is sent from the host 400 to the NVMe device 214. This may be achieved by inserting a layer of encryption between the host 400 and the NVMe device 214, which may allow each command issued to be processed as an encrypted command before being passed on to the NVMe device controller 214 for further processing. When a command is written by the host driver and queued onto the submission queue (SQ) 404, it may be first picked up by the NVME-ICE module 500 for encryption/decryption before being passed on to the NVMe device controller 214 for further processing. The NVMe device controller 214 may then process the command and update the SQ head pointer before passing it back to the NVME-ICE module 500 for decryption or encryption as appropriate. The NVMe device controller 214 may then write information to a completion queue (CQ) and generate an MSI-X interrupt for the host driver.

[0110] The process flows described above may ensure that all data sent between the host CPU and NVMe device controller 214 are encrypted and secure while providing a performance-efficient solution that maintains low latency regardless of workload or data size due to its position in line with other required steps in the process of sending commands from a host CPU and receiving results back from a NVMe device controller 214. Further, in some embodiments, all data may be secured using hardware-based encryption mechanisms so that no additional software implementation is required on either the host CPU or NVMe device side. As a result, the embodiments may be implemented without any major changes to existing architectures and systems for users looking for improved security solutions for their workloads without sacrificing performance or latency.

[0111] With reference to FIGs. 1-6, FIG. 6 illustrates a processing system 600 (e.g., processing system 12 in FIG. 1, processing system 202 in FIG. 2, host 400 in FIG. 5), which may be implemented as an SoC, that includes a system memory space 602 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5), a network on chip (NOC) 604, a PCIe Root complex 606, and a PCIe link 608 to an NVMe Device 214 that includes a completion queue (CQ) head pointer (ptr) 610, a CQ tail ptr 612, a submission queue (SQ) tail ptr 614, and an SQ head ptr 616. The system memory space may include a completion queue (CQ) 618, a submission queue (SQ) 620, and a page-level read/write pointers list (PRPL) 622.

[0112] The CQ head ptr 610 may point to a next completion entry in the completion queue 618, and the CQ tail ptr 612 may point to a last completion entry in the completion queue 618. The SQ head ptr 616 may point to a next command (CMD) 624 in the submission queue 620, and the SQ tail ptr 614 may point to a last command in the submission queue 620. Each command 624 may include multiple PRPs 626 and/or PRPL pointers (ptrs) 628. Each PRP 626 may be a pointer with an association to a location 630 in the system memory space 602, such as a page buffer. Each PRPL pointer 628 may be a pointer with an association to a PRPL 622. Each PRPL 622 may include multiple PRPs 626.

[0113] FIG. 7 illustrates some of the technical challenges associated with determining which accesses (e.g., SQ, CQ, PRPL, I/O access, etc.) need cyphering in order to be able to securely transfer data from an NVMe device. With reference to FIGs. 1-7, NVMe devices (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIGs. 2, 5, and 6) use SQ, CQ, PRPL, and I/O access for various data transfer activities. The four primary types of access in the NVMe processing system that are illustrated in FIG. 7 are write address, read address, write data, and read data. As a nonlimiting example, various types of access using Advanced extensible Interface (AXI) protocols may include AXI write address (AWADDR), AXI read address (ARADDR), AXI write data (WDATA), and AXI read data (RD ATA). FIG. 7 also illustrates that SQ access for command fetch should not be cyphered, CQ access for completion entry should not be cyphered, PRPL access for descriptor fetch should not be cyphered, but I/O access with user data transfer should be cyphered.

[0114] With reference to FIGs. 1-8, to determine which accesses (such as SQ, CQ, PRPL, and I/O access) should be encrypted, some embodiments may match the incoming address of the NVMe device against a database of addresses (e.g., content search engine 806 in FIG. 8) stored in the internal SRAM (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6). The address database may include entries containing the start and end address of each SQ (e.g., submission queue 620 in FIG. 6) (SQ table), CQ (e.g., completion queue 620 in FIG. 6) (CQ table), PRP list (e.g., PRPL 622 in FIG. 6) (PRPL table 800 in FIG. 8), and PRP (e.g., PRP 626 in FIG. 6) (PRP table 802 in FIG. 8). When an incoming address matches an entry in the SQ table, for example, it may be inferred that the NVMe device is trying to read a command. Similarly, when an incoming address matches an entry in the CQ table, it may be inferred that the device is trying to write a completion entry. By matching the incoming address with this database, the system (e.g., processing system 12 in FIG. 1, processing system 202 in FIG. 2, host 400 in FIG. 5, processing system 600 in FIG. 6) may determine what type of access is being attempted, as well as whether or not it should be encrypted. For instance, the system may determine all I/O accesses involving user data transfer should be encrypted for security purposes.

[0115] Thus, after matching, the system may decide which access needs cyphering. The system may be configured so that any access with matching addresses in SQ, CQ and PRPL tables is control or status related data that does not need to be cyphered. On the other hand, the system may determine that any access with matching addresses in PRP table 802 may need to be cyphered because this may include a user data transfer.

[0116] The theoretical maximum size for the databases that hold start and end addresses for each SQ, CQ, PRP List and PRP is 384KB, 384KB, 3TB and 1536TB, respectively. These sizes may be prohibitive for consumer-grade laptops or desktops, for which the following requirements may be applicable: NVMe device supports 32 SQs and 32 CQs; SQ table holds 32 entries (192B storage); CQ table holds 32 entries (192B storage); 8K commands, with 2MB per transaction may enough to keep PCIe links busy; PRPL Table 800 holds 8K entries (8K * 1) and thus 48KB storage; each PRPL may include up to 512 PRP entries, PRP Table 802 may include 4 million entries (8K * 512) - 24MB storage.

[0117] Another technical challenge is how to keep the PRP Table 802 in internal SRAM, so that it may be accessed quickly and efficiently. To accomplish this, the size of the PRP Table 802 may have to be reduced significantly. One way to do that is by predicting or identifying which user data buffers will be accessed by the NVMe device.

[0118] With reference to FIGs. 1-9, to overcome these and other technical challenges, some embodiments may trap device accesses and interpret them as per the NVMe specification. The system may look at each access request to determine whether it is legitimate before allowing it to proceed further. To accomplish this, the system may extract PRPs from each request on-the-fly. In some embodiments, registers may be configured with submission queue start and end addresses in order to identify when a read address falls within one of these ranges. This may allow the system to determine the PRPs that are cached in the NVMe Device. In addition, a portion of an NVMe command 900 in FIG. 9A, such as part of an address field, including a reserved field (RSVD in FIG. 9A), and/or other field in the NVMe command 900, may hold a page-level read/write pointers list (PRPL) Index of a command entry 902 in FIG. 9B (e.g., command 624 in FIG. 6). This may provide an accurate shadow of all PRPs that are dynamically cached inside the NVMe device.

[0119] Some embodiments may take advantage of reserved fields in an NVMe command structure that hold a PRPL Index of a command entry, so as to create a shadow of all PRPs cached inside the NVMe Device. The system may initiate this process by configuring its submission queues (SQs) with their base addresses and queue size (Qsize) values, then performing the same operations for the completion queues (CQs). As a result, the system may enqueue the commands without requiring PRPLs.

[0120] Depending on how much user data needs transferring there may be different processes required for completing a successful transfer. For example, if user data fits into one or two system memory pages, security context information may be written at one or two PRP lookup table (PRPLT) locations (“N”). The system may then proceed with creating the command before pushing the command into an SQ along with maintaining its mapping {SQ identifier (SQID), Command identifier (CID)} -> N or {SQID, CID, namespace identifier (NSID)} -> N. If user data requires more than 2 system memory pages, up to a threshold of system memory pages, however, then a PRP may be created for a first system memory page and a PRPL would need to be created for all other system memory pages such that for all PRP entries of the PRPL a logical block (LB) offset is put as lower 12 bits and bit[ 1 :0] = 2’b00). If user data requires more than the threshold of system memory pages, then multiple chained PRPLs may be created by inserting in a last entry of a PRPL a pointer to a next PRPL entry of another PRPL. The threshold of system memory pages may be configured based on the system memory page size. In some embodiments, the threshold of system memory pages may be the system memory page size divided by 8. For example, for a system memory page size of 4KB, the threshold of system memory pages may be 512 system memory pages. The threshold of system memory pages may be similarly configured based on any system memory page size, such as 8KB, 16KB, etc.

[0121] That is, when enqueuing commands, no page-level read/write pointers lists (PRPLs) may be required if user data fits inside one or two system memory pages. However, if more than two pages, up to the threshold of system memory pages are needed, then a PRPL may be used. If more than the threshold of system memory pages are needed, then multiple PRPLs may be required for chaining together (PRPL creation process). For more than 2 pages, LB offset into lower 12 bits may be inserted into each PRP entry after a first PRP entry, including each entry in each PRPL. For more than the threshold of system memory pages a pointer to the next PRPL may be in the last PRP entry(s) of each prior PRPL. When processing commands, security context information may also be written at PRPLT location N. In examples using at least one PRPL, a first PRPL pointer may be inserted into a PRP2 field if its more than, such as when the data requires more than 2 pages while pushing into SQ and maintaining mapping {SQID, CID} -> N or {SQID, CID, NSID} -> N. These embodiments may reduce the total SRAM requirement for caching all PRP entries down only 8KB even with a large number of commands present making implementation using internal SRAM possible without sacrificing performance efficiency.

[0122] FIGs. 10A-12B illustrate some examples of command and PRPL structures for commands with data requiring varying numbers of page buffers. With reference to FIGs. 1-12B, the command structures 1000, 1002, 1102, 1202 (e.g., command 624 in FIG. 6, e.g., command 902 in FIG. 9) may be for commands, such as the commands described above, received from a memory (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6), such as from the SQ (e.g., SQ 404 in FIG. 5, submission queue 620 in FIG. 6) by an NVMe inline cryptographic module (e.g., inline cryptographic module 38 in FIGs. 1-3, NVMe-ICE module 500 in FIG. 5). Each of the command structures 1000, 1002, 1102, 1202 may include a PRPLT pointer (or index) to a location (“N”) at a PRPLT. The PRPL structures 1100, 1200 (e.g., PRPL 622 in FIG. 6), such as the PRPLs described above, may be referenced by PRPL pointers (e.g., PRPL pointer 628 in FIG. 6) of the commands 1102, 1202.

[0123] The example illustrated in FIG. 10A shows a command structure 1000 having data that requires a one page buffer. In addition to the PRPLT pointer, the command structure 1000 may include a PRP (“PRP1”) (e.g., PRP 626 in FIG. 6) with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer. As the data requires a one page buffer, another PRP (“PRP2”) may have default data (e.g., zeros, null value, etc.) configured to indicate no association to a location in the memory.

[0124] The example illustrated in FIG. 10B shows a command structure 1002 having data that requires two page buffers. In addition to the PRPLT pointer, the command structure 1002 may include a PRP (“PRP1”) (e.g., PRP 626 in FIG. 6) with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer. Additionally, the command structure 1002 may include another PRP (“PRP2”) with an association to another location in the memory, such as another page buffer. In some embodiments, the other PRP may include an LB offset (“Loffsef ’). The LB offset is optional and may be used and vary in size, depending on page size and on logical block address (LBA) size, to match the page size.

[0125] The examples illustrated in FIGs. 11A and 1 IB show a PRPL structure 1100 and an associated command structure 1102 having data that requires more than two page buffers, up to the threshold of system memory pages page buffers. The PRPL structure 1100 may include at least two PRPs (“PRP2”, “PRP3”, “PRP4”) (e.g., PRP 626 in FIG. 6), up to 510 PRPs, each with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer, respectively. The PRPL structure 1100 may include an LB offset (“Loffsetl”, “Loffset2”, “Loffset3”) for each PRP. In addition to the PRPLT pointer, the command structure 1102 may include a PRP (“PRP1”) with an association to a location in the memory, such as a page buffer. Additionally, the command structure 1102 may include a PRPL (“PRPL Pointer”) with an association to the PRPL structure 1100.

[0126] The examples illustrated in FIGs. 12A and 12B show a PRPL structure 1200, which may be representative of multiple PRPL structures 1200, and an associated command structure 1202 having data that requires more than the threshold of system memory pages page buffers. The PRPL structure 1200 may include at least two PRPs (“PRP2”, “PRP3”) (e.g., PRP 626 in FIG. 6), up to 510 PRPs, each with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer, respectively. For the PRPL structure 1200 being insufficient to hold all of the PRPs, an entry in the PRPL structure 1200 may be pointer to a next PRPL structure 1200 (“ptr to next PRPL”). A last PRPL structure 1200 having a last PRP for the command structure 1202 may exclude the pointer to a next PRPL structure 1200, like the PRPL structure 1100. The PRPL structure 1200 may include an LB offset (“Loffsetl”, “Loffset2”) for each PRP. In addition to the PRPLT pointer, the command structure 1202 may include a PRP (“PRP1”) with an association to a location in the memory, such as a page buffer. Additionally, the command structure 1202 may include a PRPL (“PRPL Pointer”) with an association to the PRPL structure 1200.

[0127] FIGs. 13-17 illustrate example information structures and operations in computing systems configured to implement various embodiments. With refence to FIGs. 1-17, the information structures and operations may be implemented in a computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) and/or an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIGs. 2, 5, and 6). For example, the information structures and operations may be implemented in any combination of components of the computing system, including a host memory (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6), a host processing system (e.g., processing system 12 in FIG. 1, processing system 202 in FIG. 2, host 400 in FIG. 5, processing system 600 in FIG. 6) configured to execute a host software (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via one or more processors (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module (e.g., NVMe inline cryptographic module 38 in FIGs. 1-3, NVMe-ICE module 500 in FIG. 5) and a PCIe root complex (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6). In some examples, the host software may be an operating system (e.g., Android, Windows, iOS, etc.).

[0128] The information structures may include a PRPLT SRAM 1300 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6, PRPL Table 800 in FIG. 8) and a look up table (LUT) SRAM 1302 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6, PRP Table 802 in FIG. 8). The information structures may also include command 1000, 1002 (e.g., command 624 in FIG. 6), command 1502 (e.g., e.g., command 624 in FIG. 6, command 1102 in FIG. 11B, command 1202 in FIG. 12B), modified commands 1304, 1400, 1500, PRPLs 1100, 1200 (e.g., PRPL 622 in FIG. 6), and modified PRPLs 1600, 1700.

[0129] The operations may include the operations illustrated in blocks 1310, 1312, 1314, 1316, 1318, 1410, 1412, 1510, 1610, 1612, 1614, 1710, 1712. Like numbered blocks may be implemented in a similar manner across the examples illustrated in FIGs. 13-17.

[0130] Another technical challenge is how to read and parse data from a DDR (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2) into the shadow of a NVMe device in order to access it later. The embodiments may break down into multiple stages, such as reading the data from DDR and parsing the command structure.

[0131] The first stage may include reading the data for this access from a DDR memory. That is, the first stage may include identifying the data that requires access, which includes the physical address of the data, as well as the command structure defining how this access should be handled. The second stage may include parsing the command structure 1000, 1002, 1502 and extracting PRP details so they may be put into the “shadow” of a NVMe device. The “shadow” may be an area within the host memory, such as the PRPLT SRAM 1300 and/or the LUT SRAM 1302, where data shares are kept so that they may be easily accessed when needed without having to go through any other processes such as booting up or accessing another type of file storage system. An item “shadow”, or “shadow” of an item, refers to the data of that item within the “shadow” specifically for the item. To “shadow” an item means to put the data of that item in the “shadow” for the item. In addition, if there is a pointer to PRPL (e.g., PRPL pointer 628 in FIG. 6) inside the command 1502, then it should be cached in a temporary small storage, such as the PRPLT SRAM 1300 and/or the LUT SRAM 1302, before being sent to the final destination (the NVMe device).

[0132] As an example, as illustrated in FIG. 13, if the system receives a command (CMD) 1000 with only one PRP (e.g., PRP 626 in FIG. 6), “PRP1”, valid, then, in block 1310, the system could use a physical region page list table (PRPLT) index field of a command 1000 to read PRPLT [N], a location in the PRPLT SRAM 1300, which may contain a start logical block address (SLBA) and/or a namespace identifier (NSID) for the command 1000. In block 1312, the system may look for a free location in a look up table (LUT) (e.g., in the LUT SRAM 1302) to enter relevant PRP1 details (which may include the NSID), and calculate a logical block address (LB A) for which the LB A and/or the NSID map to the buffer in block 1314. The system may delete the pointer related to the PRPLT from command 1000 and make it reserved (“RSVD”) in block 1316, overwrite part of PRP 1 with the pointer related to the PRPLT in block 1317, and send the modified command 1304 towards its destination, the NVMe device, in block 1318. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRP as the NVMe device).

[0133] As an example, as illustrated in FIG. 14, if the system receives a command (CMD) 1002 with two valid PRPs (e.g., PRP 626 in FIG. 6), “PRP1” and “PRP2”, then, in block 1310, the system could use a PRPLT index field of a command 1002 to read PRPLT [N] (i.e., a location in the PRPLT SRAM 1300), which may contain a start logical block address (SLBA) and/or a namespace identifier (NSID) for the command 1002. [0134] In block 1410, the system may look for a free location in an LUT (e.g., in the LUT SRAM 1302) to enter relevant PRP1 details with a recalculated LB A and/or the NSID that the buffer maps to. The system may delete the pointer related to the PRPLT from command 1002 and make it reserved (“RSVD”) in block 1316 and send the modified command 1400 towards its destination, the NVMe device, in block 1318. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0135] As an example, as illustrated in FIG. 15, if the system receives a command (CMD) 1502 with a PRP (e.g., PRP 626 in FIG. 6), “PRP1”, and a pointer to a PRPL (e.g., PRPL pointer 628 in FIG. 6), “PRPL Pointer”, that are valid, then, in block 1310, the system could use a PRPLT index field of a command 1502 to read PRPLT [N], a location in the PRPLT SRAM 1300, which may contain a start logical block address (SLBA) and/or a namespace identifier (NSID) for the command 1502. In block 1410, the system may look for a free location in an LUT (e.g., in the LUT SRAM 1302) to enter relevant PRP1 details with a recalculated LB A and/or the NSID that the buffer maps to. In block 1510, the system may transfer the PRPL Pointer from the command 1502 to the PRPLT [N] location in the PRPLT SRAM 1300. The system may delete the pointer related to PRPLT from command 1502 and make it reserved (“RSVD”) in block 1316, and send the modified command 1500 towards its destination, the NVMe device, in block 1318. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRP and PRPL Pointer as the NVMe device).

[0136] Continuing from the example illustrated in FIG. 15, in the example illustrated in FIG. 16, a PRPL 1100 may be associated with the PRPL Pointer (e.g., PRPL pointer 628 in FIG. 6) of the command 1502 that was written to the PRPLT SRAM 1300. Each entry of incoming data for the command 1502 may be one PRP (e.g., PRP 626 in FIG. 6) of the PRPL 1100. In block 1610, the system may find a free location in the LUT (e.g., in the LUT SRAM 1302) for each PRP of the PRPL 1100, and enter that PRP into that LUT location, with a recalculated LBA and/or a namespace identifier (NSID) that the buffer maps to. The system may delete a logical block offset (“Loffsetl”, “Loffset2”, “Loffset3”) for each PRP from the PRPL 1100 in block 1612, such as by overwriting the Loffset with zeros, and send the modified PRPL 1600 towards its destination, the NVMe device, in block 1614. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0137] Continuing from the examples illustrated in FIG. 15, in the example illustrated in FIG. 17, a PRPL 1200 may be associated with the PRPL Pointer (e.g., PRPL pointer 628 in FIG. 6) of the command 1502 that was written to the PRPLT SRAM 1300 and contain a pointer to a next PRPL. Each entry of incoming data, except for a last entry, for the command 1502 may be one PRP (e.g., PRP 626 in FIG. 6) of the PRPL 1200. The last entry may be the pointer to a next PRPL. In block 1710, the system may find a free location in the LUT (e.g., in the LUT SRAM 1302) for each PRP of the PRPL 1200, and enter that PRP into that LUT location, with a recalculated LBA and/or a namespace identifier (NSID) that the buffer maps to.

[0138] In block 1712, the system may transfer the pointer to a next PRPL 1100, 1200 from the PRPL 1200 to the PRPLT [N] location in the PRPLT SRAM 1300. The system may delete a logical block offset (“Loffsetl”, “Loffset2”) for each PRP from the PRPL 1200 in block 1612, such as by overwriting the Loffset with zeros, and send the modified PRPL 1700 towards its destination, the NVMe device, in block 1614.

[0139] In some embodiments, the pointer to a next PRPL in the PRPL 1200 and written to the PRPLT [N] location in the PRPLT SRAM 1300 may point to another PRPL 1200, and the example illustrated in FIG. 17 may repeat implementation. Such repetitions may occur for each subsequent PRPL 1200. In some embodiments, the pointer to a next PRPL in the PRPL 1200 and written to the PRPLT [N] location in the PRPLT SRAM 1300 may point to a PRPL 1100, and the example illustrated in FIG. 16 may be implemented. This implementation may occur following one or more implementations of the example illustrated in FIG. 17. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0140] Thus, some embodiments may trap device accesses, interpret them as per NVMe specification and extract PRPs from it on-the-fly. Some embodiments may maintain 32 address ranges in registers for 32 Submission Queues. In some embodiments, the NVMe device driver (e.g., NVMe driver 208 in FIG. 2) may configure these registers with SQ start and end address. When the NVMe device issues a read address in any of these ranges, the system may determine that it is for reading commands from that SQ (e.g., SQ 404 in FIG. 5).

[0141] Some embodiments may repurpose a reserved field in NVMe CMD, that holds PRPLT Index of the command entry. As such, the system may now have 100% true shadow of all PRPs, that are dynamically cached inside the NVMe Device.

[0142] In some embodiments, the NVMe Driver may configure SQ Table with Base address and Qsize. In some embodiments, the NVMe Driver may configure the CQ Table with Base address and Qsize.

[0143] In some embodiments, the NVMe Driver may enqueue a command such that no PRPLs are required. The computing system may acquire a free PRPLT slot from NVMe ICE HW (N), or NVMe inline cryptographic module (N). The computing system may acquire a Crypto Key slot index from secured process.

[0144] As an example, in relation to the example illustrated in FIG. 13, if user data fits in the first system memory page, the system may write Security Context information at PRPLT location N in the PRPLT SRAM 1300, write PRPLT Index = N in the command 1000, proceed with other steps for Command creation and push the command 1000 into an SQ, and maintain a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0145] As another example, in relation to the example illustrated in FIG. 14, in block 1412, if user data fits in two system memory pages, the computing system may write Security Context information at PRPLT location N in the PRPLT SRAM 1300, write PRPLT Index = N and insert LB offset into lower 12 bits in PRP2 (Page boundary aligned) in the command 1002, proceed with other steps for Command creation and push the command 1002 into an SQ, and maintain a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0146] As another example, in relation to the examples illustrated in FIGs. 15 and 16, if user data requires more than 2 system memory pages and up to the threshold of system memory pages, the system may determine that only one PRPL is required. The PRPL creation process may include for each PRP entry (the PRPs are all Page boundary aligned), insert LB offset into lower 12 bits (bit[ 1 :0] = 2’b00) in the PRPL 1100. The command processing may include writing Security Context information at PRPLT location N in the PRPLT SRAM 1300, writing PRPLT Index = N and inserting a PRPL Pointer in a PRP2 field in the command 1502, proceeding with other steps for Command creation and pushing the command 1502 into an SQ, and maintaining a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0147] As another example, in relation to the examples illustrated in FIGs. 15-17, user data requires more than the threshold of system memory pages. Multiple PRPLs 1100, 1200 are required (chained PRPL), the PRPL creation process may include for all but the last PRP entry in PRPL 1200 (the PRPs are all Page boundary aligned) insert LB offset into lower 12 bits (bit[ 1 :0] = 2’b00) in the PRPLs 1100, 1200, and put pointer to next PRPL 1200 in to the last PRP entry in the PRPL 1100. The command processing may include writing Security Context information at PRPLT location N in the PRPLT SRAM 1300, writing PRPLT Index = N and inserting a First PRPL Pointer in a PRP2 field in the command 1502, proceeded with other steps for Command creation, and pushing the command 1502 into an SQ, and maintaining a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0148] In some embodiments, when the Read data for this access arrives from DDR, the system may parse the Command structure 1000, 1002, 1502 and extract the PRP details and put into the shadow, such as the PRPLT SRAM 1300 and/or the LUT SRAM 1302. If the Command 1502 includes a pointer to PRPL, the system may cache it in a temporary small storage, such as the PRPLT SRAM 1300 and/or the LUT SRAM 1302.

[0149] As an example, if the command (CMD) 1000, 1002, 1502 has PRP1 valid, the system may use PRPLT Index field of command to read PRPLT [N] (it has SLBA and/or a namespace identifier (NSID)). The system may find a free location in the LUT, in the LUT SRAM 1302, and enter PRP1 into that LUT location. The system may (re)calculate LB A for which the LB A and/or the NSID map to this buffer, delete PRPLT Pointer from CommandlOOO, 1002, 1502 and make is RSVD, and send the modified Command 1304, 1400, 1500 to NVMe device. The final result may be that the system includes in its shadow the same PRP that the NVMe device has.

[0150] When the NVMe device issues a read address (N) for reading a PRPL 1100, 1200, the system may perform a content search on the PRPLT, in the PRPLT SRAM 1300. It may hit for location N. This read access may be for reading PRPs from that PRPL 1100, 1200. The system may insert “N” into a Read Tracking FIFO (not shown), and forward the read access to the system memory. When the Read data for this access arrives from system memory, the system may pop the Read tracking FIFO, such as by using a get “N” operation. The system may parse the PRPL structure 1100, 1200 and extract the PRP details and put into the shadow, such as the PRPLT SRAM 1300 and/or the LUT SRAM 1302.

[0151] When the NVMe device issues an access that hits one of the shadowed PRPs in the LUT SRAM 1302, it may be for user data access. The system may execute a Cypher operation for data associated with PRPs of the ranges of shadowed PRPs. When access to a data (e.g., 4KB, 16KB, 64KB, etc.) associated with a PRP is completed, the system may evict the PRP from the shadow. They system now has 100% true shadow of all PRPs, that are dynamically maintained inside the NVMe Device using only 8KB.

[0152] Some embodiments may be implemented using an LUT (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17), and without using a PRPLT (e.g., PRPL Table 800 in FIG. 8 in FIG. 8, PRPLT SRAM 1300 in FIGs, 13-17). Advantages of embodiments that are implemented using an LUT without using a PRPLT may include less software overhead than the software overhead created by implementation and management of a PRPLT and an LUT, including overhead created by implementing and managing the PRPLT itself and the data relationship of the PRPLT and the LUT. Advantages may further include lifting restrictions on a number of command submissions for the NVMe device 214 (e.g., storage memory 24 in FIG. 1) as compared to embodiments in which the PRPLT and LUT are implemented together. Other advantages may include support for PCIe address translation service (ATS) for virtual address to physical address mapping, and reduced silicon area from not implementing and managing a PRPLT.

[0153] FIG. 18 illustrates an NVMe inline cryptographic module. With reference to FIGS. 1-18, the NVMe inline cryptographic module 38 (e.g., inline cryptographic module 38 in FIGS. 1-3, NVMe-ICE module 500 in FIG. 5) may be configured to manage command parsing and an LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) for implementing NVMe inline cryptographic processes using PRPs (e.g., PRP 626 in FIG. 6) in computing systems (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2). The NVMe inline cryptographic module 38 may also include other components for implementing NVMe inline cryptographic processes using PRPs, including exclusive address range registers 1804, which may be for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. The NVMe inline cryptographic module 38 may include SQ and CQ address range registers 1806, which may be configured for storing start addresses, end addresses, and/or sizes of one or more submission queues (e.g., SQ 404 in FIG. 5) and/or SQ entries and command queues (e.g., completion queue 406 in FIG. 5) and/or CQ entries.

[0154] Oher components of the NVMe inline cryptographic module 38 may include a cryptographic datapath 1802, including cryptographic engines 1810 (e.g., encryption module 304 and decryption module 306 in FIG. 3) and at least one cryptographic key table 1812 configured to store keys for implementing cryptographic processes. The NVMe inline cryptographic module 38 may include additional components 1808, which may include any combination of configuration registers, which may be used during initialization of the NVMe inline cryptographic module 38, FIFOs modules, clock modules, reset modules, debug modules, etc.

[0155] FIG. 19 illustrates an example of a structure of a command processed by the NVMe inline cryptographic module 38. With reference to FIGS 1-19, a structure of a command 1900 (e.g., command 902, 1000, 1002, 1102, 1202, 1502 in FIGs. 9B-15) may be for I/O accesses involving user data transfer that should be encrypted for security purposes, including read and/or write commands. The structure of the command 1900 may be a modified version of a common submission command format for NVMe implementation. For example, the structure of a command 1900 may include aspects typically included in a submission command format, such as a command identifier (CID), a PRP or SGL for data transfer indicator (PSDT), a fuse indicator, and opcode, a namespace identifier (NSID), a metadata pointer (MPTR), and PRP pointers (e.g., PRP1, PRP2) (e.g., PRP 626 in FIG. 6) and/or PRPL pointers (e.g., at PRP2) (e.g., PRPL pointer 628 in FIG. 6). The modifications to the structure of a command 1900 may include a cryptographic function enable indicator (CE), which may include a bit located at a commonly reserved space, for example, command word (CWD) 0, bit 10. The cryptographic function enable indicator may be configured to enable and/or disable the cryptographic functions of the NVMe inline cryptographic module 38. The modifications may also include a key slot locator, which may be any combination of bits, such as 8 bits, located at commonly reserved space, for example, CWD3, bits 23 : 16. The key slot locator be configured to enable the NVMe inline cryptographic module 38 to locate an appropriate cryptographic key from a key table 1812 to implement the cryptographic functions.

[0156] The NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIGs. 2, 5, and 6) may read the command 1900 and a PRP and/or PRP list (e.g., PRPL 622, 1100, 1200 in FIGs. 6, 11A, 12A, 16, 17), which may prompt the NVMe inline cryptographic module 38 to parse the command entry and the PRP and/or the PRP list. The NVMe inline cryptographic module 38 may read the cryptographic function enable indicator and the key slot data from the command 1900. In some examples, the NVMe inline cryptographic module 38 may overwrite the cryptographic function enable indicator and the key slot data in the data of the command 1900, such as by writing zeros in the appropriate locations in the data structure of the command 1900.

[0157] The NVMe inline cryptographic module 38 may update the LUT 1800 with PRP entries from the command 1900 and/or the PRP list and security context that may be parsed and read from the command 1900. FIG. 20 illustrates an example of a structure of the LUT 1800. With reference to FIGS 1-20, a structure of the LUT 1800 may include an index for each entry of the LUT 1800, and a PRP entry and/or PRP list (PRPL) pointer (ptr) entry and a security context associated with each index. The PRP entry and/or PRPL pointer entry may include a corresponding PRP base address. The security context may include a logical block address (LBA), a namespace identifier (NS ID), a cryptographic function enable indicator (CE) and the key slot data (KS), a pointer type, including PRP or PRP list (PRPL) pointer (ptr), data the from metadata of the command 1900 referenced by the metadata pointer, etc.

[0158] The NVMe inline cryptographic module 38 may perform on the fly PRP address modification at the data of the command 1900, replacing PRP address bits (e.g., PRP1 and/or PRP2) with the corresponding LUT index. For example, the NVMe inline cryptographic module 38 may replace some of the address bits, such as in the range of bits 63 : 12. Replacing some of the address bits may enable maintaining an original PRP address offset within a page, such as 4KB page. In some examples, the NVMe inline cryptographic module 38 may tag the PRP address as modified through setting of one or more specific bits of the PRP address, such as bit 63. In some embodiments, the PRP address may be modified such that the modified address may be within a range defined by a software (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2) configured to not overlap with an exclusion range or other range used by the software and that is not in the LUT 1800. The NVMe inline cryptographic module 38 may use the index of the LUT 1800 to locate the PRP entry and/or PRPL pointer entry and the security context associated with a command as described further herein.

[0159] FIG. 21 illustrates a system and method for implementing an initialization phase for NVMe inline cryptographic processes using shadowing of PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-21, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0160] The host software 2100 may enumerate one or more NVMe devices 214 by implementing a process 2102 and detect the PCIe root complex 212 and an NVMe device 214 by implementing a process(es) 2104. The host software 2100 may load an NVMe driver (e.g., NVMe driver 208 in FIG. 2) for the NVMe device 214 by implementing a process 2106 and initialize a PCIe controller, of the PCIe root complex 212, by implementing a process 2108.

[0161] The host software 2100 and NVMe inline cryptographic module 38 may initialize the NVMe inline cryptographic module 38 by implementing various processes 2110. These processes may include configuring various registers of the NVMe inline cryptographic module 38. These processes may include configuring exclusive address range registers 1804 by implementing a process 2112. The exclusive address range registers 1804 may be configured for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. These processes may include configuring SQ address range registers 1806 by implementing a process 2114, and configure CQ address range registers 1806 by implementing a process 2116. The SQ and CQ address range registers 1806 may be configured for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. for any number of submission queues (e.g., SQ 404 in FIG. 5) and command queues (e.g., completion queue 406 in FIG. 5), such as 8, 16, 32, 64, etc. These processes may include configuring other configuration registers of the NVMe inline cryptographic module 38 (e.g., additional components 1808 in FIG. 18) by implementing a process 2118.

[0162] The host software 2100 and NVMe inline cryptographic module 38 may configure other aspects of the NVMe inline cryptographic module 38, including administrative functions (Admin), input/output functions (IO), and SQ and CQ entries by implementing a process 2120. The processes may also include writing start and/or end address and/or address range sizes to the SQ and CQ address range registers 1806 by implementing a process 2122.

[0163] FIG. 22 illustrates a method for implementing a command creation stage for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-22, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0164] The host software 2100 may execute a command creation stage in which the host software 2100 may create a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in FIGS. 9B-15, 19) for reading from and/or writing to the host memory 36. Such commands may be for I/O accesses involving user data transfer that should be encrypted for security purposes. The host software 2100 may implement various processes for creating the command that enable cryptographic functions of the NVMe inline cryptographic module 38 for implementing the command. The host software 2100 may acquire cryptographic key slot data for a command that requires cryptographic functions by implementing a process 2200. The host software 2100 may create the command, programming the data of the command in a submission queue command entry, including key slot data and a cryptographic function enable in a process 2202. The key slot data may be configured to enable the NVMe inline cryptographic module 38 to locate an appropriate cryptographic key from a key table (e.g., key table 1812 in FIG. 18) to implement the cryptographic functions. The cryptographic function enable indicator may be set to enable cryptographic functions of the NVMe inline cryptographic module 38. [0165] The host software 2100 may submit the command to the host memory 36 for addition to the submission queue (e.g., SQ 404 in FIG. 5) in response to the submission queue command entry by implementing a process 2204. The host software 2100 may update the submission queue doorbell (e.g., Doorbell 408 in FIG. 5) at the NVMe device 214 by implementing a process 2206.

[0166] FIGS. 23 A and 23B illustrate methods for implementing command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-23B, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG.

5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0167] The embodiment illustrated in FIG. 23A relates to a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in FIGS. 9B-15, 19) having PRP entries (e.g., PRP 626 in FIG. 6) and not PRPL entries (e.g., PRPL pointer 628 in FIG.

6). The embodiment illustrated in FIG. 23B relates to a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in FIGS. 9B-15, 19) having at least one PRP entry (e.g., PRP 626 in FIG. 6) and at least one PRPL entry (e.g., PRPL pointer 628 in FIG. 6). The processes of the embodiments illustrated in FIGS. 23 A and 23B may be implemented in a similar maimer unless otherwise noted. [0168] The NVMe device 214 may implement a transaction with the NVMe inline cryptographic module 38 for reading a command entry from the command submission queue (e.g., SQ 404 in FIG. 5) by implementing a process 2300. In some embodiments, the transaction may be an AXI transaction. The NVMe inline cryptographic module 38 may respond to the transaction by parsing and validating the incoming transaction by implementing a process 2302. The data of the validated transaction may be used by the NVMe inline cryptographic module 38 to forward the transaction for reading a command entry from the command submission queue (e.g., SQ 404 in FIG. 5) to the host memory 36 by implementing a process 2304. The host memory 36 may respond to the transaction by returning read data from the corresponding command submission entry by implementing a process 2306.

[0169] In the embodiment illustrated in FIG. 23 A, for which the read data from the corresponding command submission entry includes PRP entries and not PRPL entries, the NVMe inline cryptographic module 38 may update the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) and modify the data from the command submission entry on the fly by implementing a process 2308. For example, with reference to FIGS. 1-25, the NVMe inline cryptographic module 38 may update the LUT 1800 by adding entries for the PRP entries of the submission command by adding an index, the PRP addresses, and security context for each PRP entry, an example of which is shown in the LUT 1800 in FIG. 25. The NVMe inline cryptographic module 38 may modify the data of the command submission entry by replacing the PRP address data with the corresponding index of the LUT 1800, an example of which is shown in the data of the command 1900 in FIG. 24.

[0170] In the embodiment illustrated in FIG. 23B, for which the read data from the corresponding command submission entry includes at least one PRP entry (e.g., PRP 626 in FIG. 6) and at least one PRPL entry (e.g., PRPL pointer 628 in FIG. 6), the NVMe inline cryptographic module 38 may update the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) and modify the data from the command submission entry on the fly by implementing a process 2312. For example, the NVMe inline cryptographic module 38 may update the LUT 1800 by adding entries for the at least one PRP entry and the at least one PRPL entry of the submission command by adding an index, the PRP address and the PRPL address, and security context for each PRP and PRPL entry, an example of which is shown in the LUT 1800 in FIG. 25. The NVMe inline cryptographic module 38 may modify the data of the command submission entry by replacing the PRP address data and the PRPL address data with the corresponding index of the LUT 1800, an example of which is shown in the data of the command 1900 in FIG. 24.

[0171] The NVMe inline cryptographic module 38 may return the modified data of the command submission entry to the NVMe device 214 by implementing a process 2310.

[0172] FIG. 26 illustrates a method for implementing command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-26, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0173] When the entry read from the command submission queue (e.g., SQ 404 in

FIG. 5) includes a PRP list (e.g., PRPL 622, 1100, 1200 in FIGs. 6, 11A, 12A, 16, 17), such as the embodiment described with reference to FIG. 23B, the entries of the PRP list may also be read. The NVMe device 214 may implement a transaction with the NVMe inline cryptographic module 38 for reading each PRP entry (e.g., PRP 626 in FIG. 6) from the PRP list by implementing a process 2600. In some embodiment, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP list received in the modified data of the command submission entry in the embodiment described with reference to FIG. 23B. The NVMe inline cryptographic module 38 may find the LUT index in the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) and retrieve the corresponding PRP list address and security context by implementing a process 2602. The NVMe inline cryptographic module 38 may forward the transaction for reading the PRP list entries from the command submission queue to the host memory 36 by implementing a process 2604. The host memory 36 may respond to the transaction by returning read data from the corresponding command submission entry by implementing a process 2606.

[0174] The NVMe inline cryptographic module 38 may update the LUT 1800 and modify the data from the command submission entry for each PRP entry of the PRP list on the fly by implementing a process 2608. For example, with reference to FIGS. 1-28, the NVMe inline cryptographic module 38 may update the LUT 1800 by adding entries for each PRP entry of the PRP list by adding an index, the PRP address, and security context for each PRP entry, an example of which is shown in the LUT 1800 in FIG. 28. The NVMe inline cryptographic module 38 may modify the data of each PRP entry of the PRP list by replacing the PRP address data with the corresponding index of the LUT 1800, an example of which is shown in FIG. 27. The NVMe inline cryptographic module 38 may return the modified data of the command submission entry to the NVMe device 214 by implementing a process 2610.

[0175] FIG. 29 illustrates a method for implementing write command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-29, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some e embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0176] The NVMe device 214 may transmit a transaction to the NVMe inline cryptographic module 38 for writing data from the host memory 36 by implementing a process 2900. In some embodiments, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP (e.g., PRP 626 in FIG. 6) received in the modified data of the command submission entry in the embodiments described with reference to FIGS. 23 A and 26. The NVMe inline cryptographic module 38 may parse and validate the transaction by implementing a process 2902. Data parsed from the transaction may include the LUT index. The NVMe inline cryptographic module 38 may use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in FIG. 6) subject to the write command and the security context from the LUT 1800 by implementing a process 2904. The data of the validated transaction and retrieved from the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) may be used by the NVMe inline cryptographic module 38 to forward the transaction for reading from the address of the PRP to the host memory 36 by implementing a process 2906. The host memory 36 may respond to the transaction by reading write data from the host memory 36 and returning write data from the corresponding address of the PRP by implementing a process 2908. The NVMe inline cryptographic module 38 may encrypt the received write data by implementing a process 2910. For example, encryption may be implemented by using the key slot of the security context to retrieve the cryptographic key for implementing encryption. The NVMe inline cryptographic module 38 may transmit the encrypted write data to the NVMe device 214 by implementing a process 2912.

[0177] FIG. 30 illustrates a method for implementing read command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-30, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0178] The NVMe device 214 may transmit a transaction to the NVMe inline cryptographic module 38 for reading data from an NVMe device logical block address to write the host memory 36 by implementing a process 3000. In some embodiments, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP (e.g., PRP 626 in FIG. 6) received in the modified data of the command submission entry in the embodiments described with reference to FIGS. 23 A and 26. The NVMe device 214 may transmit encrypted data from the NVMe device logical block address by implementing a process 3002. The NVMe inline cryptographic module 38 may parse and validate the transaction by implementing a process 3004. Data parsed from the transaction may include the LUT index. The NVMe inline cryptographic module 38 may use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in FIG. 6) subject to the read command and the security context from the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) by implementing a process 3006. The NVMe inline cryptographic module 38 may decrypt the received encrypted data by implementing a process 3008. For example, decryption may be implemented by using the key slot of the security context to retrieve the cryptographic key for implementing decryption. The data of the validated transaction and retrieved from the LUT 1800 may be used by the NVMe inline cryptographic module 38 to forward the transaction for writing to the address of the PRP to the host memory 36 by implementing a process 3010. The NVMe inline cryptographic module 38 may transmit the decrypted data for writing to the address of the PRP to the host memory 36 by implementing a process 3012.

[0179] FIG. 31 illustrates a method for command completion for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-31, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5) , a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.). [0180] The NVMe device 214 may a write a command completion entry to the command queue (e.g., CQ 406 in FIG. 5) and update the command queue’s tail doorbell point at the host memory 36 by implementing a process 3100. The NVMe device 214 may transmit a command completion interrupt to the host software 2100 by implementing a process 3102. The host software 2100 may implement a driver process command completion by implementing a process 3104. The host software 2100 may write the command queue head pointer to the command queue head pointer doorbell (e.g., Doorbell 410 in FIG. 5) at the NVMe device 214 by implementing a process 3106.

[0181] FIGS. 32A and 32B illustrate a method for command processes using Peripheral Component Interconnect Express (PCIe) address translation service for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-32B, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5), a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a memory management unit (MMU) 3200 (e.g., memory interface 34 in FIG. 1), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0182] The processes of the examples illustrated in FIGS. 32A and 32B may be implemented in the same maimer as described herein. For example, the command creation stage may be implemented as described with reference to FIG. 22, the command process 2300, 2302, 2304, 2306, 2308, 2310, 2312 may be implemented as described with reference to FIGS. 23 A and 23B, the NVMe device initiating data transfer may be implemented as described with reference to FIGS. 29 and 30, and the command completion stance may be implemented as described with reference to FIG. 31.

[0183] The NVMe inline cryptographic module 38 may fetch a virtual address to physical address mapping from the MMU 3200 for the addresses of PRPs (e.g., PRP 626 in FIG. 6) and/or PRPLs (e.g., PRPL 622, 1100, 1200 in FIGs. 6, 11A, 12A, 16, 17) by implementing a process 3202. The addresses used by the NVMe device may be in virtual address format, and the addresses used by the host device 36 may be in physical address format. The NVMe device 214 may parse received command entry data and require reading the PRP entries e.g., PRP 626 in FIG. 6) of a PRP list (e.g., PRPL 622, 1100, 1200 in FIGs. 6, 11A, 12A, 16, 17) by performing a process 3206. The NVMe inline cryptographic module 38 may fetch a virtual address to physical address mapping from the MMU 3200 for the addresses of each PRP of the PRP list by implementing a process 3204.

[0184] Various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-32B) may be implemented in a wide variety of computing systems including mobile computing devices, an example of which suitable for use with the various embodiments is illustrated in FIG. 33. The mobile computing device 3300 may include a processor 3302 coupled to a touchscreen controller 3304 and an internal memory 3306. The processor 3302 may be one or more multicore integrated circuits designated for general or specific processing tasks. The internal memory 3306 may be volatile or non-volatile memory and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. Examples of memory types that can be leveraged include but are not limited to DDR, LPDDR, GDDR, WIDER), RAM, SRAM, DRAM, P-RAM, R- RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 3304 and the processor 3302 may also be coupled to a touchscreen panel 3312, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the mobile computing device 3300 need not have touch screen capability.

[0185] The mobile computing device 3300 may have one or more radio signal transceivers 3308 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and antennae 3310, for sending and receiving communications, coupled to each other and/or to the processor 3302. The transceivers 3308 and antennae 3310 may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The mobile computing device 3300 may include a cellular network wireless modem chip 3316 that enables communication via a cellular network and is coupled to the processor.

[0186] The mobile computing device 3300 may include a peripheral device connection interface 3318 coupled to the processor 3302. The peripheral device connection interface 3318 may be singularly configured to accept one type of connection or may be configured to accept various types of physical and communication connections, common or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 3318 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0187] The mobile computing device 3300 may also include speakers 3314 for providing audio outputs. The mobile computing device 3300 may also include a housing 3320, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components described herein. The mobile computing device 3300 may include a power source 3322 coupled to the processor 3302, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile computing device 3300. The mobile computing device 3300 may also include a physical buton 3324 for receiving user inputs. The mobile computing device 3300 may also include a power buton 3326 for turning the mobile computing device 3300 on and off

[0188] The various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-32B) may be implemented in a wide variety of computing systems including a laptop computer 3400 an example of which is illustrated in FIG. 34. Many laptop computers include a touchpad touch surface 3417 that serves as the computer’s pointing device, and thus may receive drag, scroll, and flick gestures similar to those implemented on computing devices equipped with a touch screen display and described above. A laptop computer 3400 will typically include a processor 3402 coupled to volatile memory 3412 and a large capacity nonvolatile memory, such as a disk drive 3413 of Flash memory. Additionally, the computer 3400 may have one or more antenna 3408 for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver 3416 coupled to the processor 3402. The computer 3400 may also include a floppy disc drive 3414 and a compact disc (CD) drive 3415 coupled to the processor 3402. In a notebook configuration, the computer housing includes the touchpad 3417, the keyboard 3418, and the display 3419 all coupled to the processor 3402. Other configurations of the computing device may include a computer mouse or trackball coupled to the processor (e.g., via a USB input) as are well known, which may also be used in conjunction with the various embodiments.

[0189] The various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-32B) may also be implemented in fixed computing systems, such as any of a variety of commercially available servers. An example server 3500 is illustrated in FIG. 35. Such a server 3500 typically includes one or more multicore processor assemblies 3501 coupled to volatile memory 3502 and a large capacity nonvolatile memory, such as a disk drive 3504. As illustrated in FIG. 35, multicore processor assemblies 3501 may be added to the server 3500 by inserting them into the racks of the assembly. The server 3500 may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) disc drive 3506 coupled to the processor 3501. The server 3500 may also include network access ports 3503 coupled to the multicore processor assemblies 3501 for establishing network interface connections with a network 3505, such as a local area network coupled to other broadcast system computers and servers, the Internet, the public switched telephone network, and/or a cellular data network (e.g., CDMA, TDM A, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network).

[0190] Computer program code or “program code” for execution on a programmable processor for carrying out operations of the various embodiments may be written in a high-level programming language such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, a Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or programs stored on a computer readable storage medium as used in this application may refer to machine language code (such as object code) whose format is understandable by a processor.

[0191] Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of example systems, devices, or methods, further example implementations may include: the example systems or devices discussed in the following paragraphs implemented as a method executing operations of the example systems or devices; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising an NVMe inline cryptographic module configured to perform operations of the example systems, devices, or methods; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising a processing system configured with processing deviceexecutable instructions to perform operations of the example systems, devices, or methods; a computing device including means for performing functions of the example systems, devices, or methods; and the example systems, devices, or methods discussed in the following paragraphs implemented as a non-transitory processor- readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform the operations of the example systems, devices, or methods..

[0192] Example 1. A method of providing encryption of data in a nonvolatile memory express (NVMe) memory device, including selectively encrypting data for storage using an inline encryption circuits by: distinguishing data communicated over a PCIe link from driver, readout, page and buffer address data communicated over the PCIe link; and encrypting only the data.

[0193] Example 2. The method of example 1, further including: identifying likely address ranges for based on operations being performed in the NVMe memory device; and storing the likely address ranges in memory, in which distinguishing data communicated over a PCIe link from driver, readout, page and buffer address data communicated over the PCIe link includes recognizing as data for encryption data with addresses that do not fall within the likely address ranges in memory stored in memory.

[0194] Example 3. The method of example 2, in which identifying likely address ranges for based on operations being performed in the NVMe memory device includes maintaining a shadow of only those pages that the NVMe memory device has read in from system memory.

[0195] Example 4. A method implemented in an inline cryptographic module of a system on chip (SoC) for a nonvolatile memory express (NVMe) device, including: automatically shadowing all active PRPs within the NVMe device.

[0196] Example 5. The method of example 4, further including: maintaining 32 address ranges in registers that are associated with submission queues and programmed by device drivers during initialization; determining, based on access from the NVMe device in one of 32 address ranges, whether the NVMe device requested to read commands from the submission queue (SQ); determining, based on extracted PRPs, whether to encrypt access data.

[0197] Example 6. The method of any of examples 4-5, further including: shadowing all PRPs inside NVMe device in 32 register address ranges of submission queues to simplify the search logic for identifying incoming user data buffer accesses.

[0198] Example 7. The method of any of examples 4-6, further including: comparing an incoming address from the NVMe device against a database of addresses stored in memory that includes a start and end address of a submission queue (SQ) table, completion queues (CQs) table, PRP list table, and a PRP table; and determining whether to encrypt data based on whether the incoming address matches an entry in the database of addresses stored in memory.

[0199] Example 8. The method of any of examples 4-7, further including: trapping device accesses for interpretation as per the NVMe specification; and extracting PRPs from each request on-the-fly and evaluating each access request to determine whether it is legitimate.

[0200] Example 9. The method of any of examples 4-8, further including: configuring registers with submission queue start and end addresses in order to identify whether a read address falls within one of 32 address ranges; determining the PRPs that are cached in the NVMe device; storing in a reserved field in an NVMe command a PRP list (PRPL) Index of a command entry that provides an accurate shadow of all PRPs that are dynamically cached inside the NVMe device.

[0201] Example 10. The method of any of examples 4-9, further including: configuring a submission queue (SQ) with base addresses and Qsize values; configuring a completion queue (CQ) with base addresses and Qsize values; and using fields in an NVMe command structure to store a PRPL Index of a command entry so as to create a shadow of all PRPs cached inside the NVMe Device. [0202] Example 11. The method of any of examples 4-10, in which in response to determining that user data fits into one system memory page: writing security context information at physical region page list table (PRPLT) location N; writing PRPLT Index = N in the command; creating the command and pushing into SQ; and maintaining the mapping of ({SQID, CommandID} -> N).

[0203] Example 12. The method of any of examples 4-11, in which in response to determining that user data fits into two system memory pages: writing security context information at physical region page list table (PRPLT) location N; inserting LB offset into lower 12 bits of PRP2 (page boundary aligned); creating the command and pushing into SQ; and maintaining the mapping of ({SQID, CID} -> N).

[0204] Example 13. The method of any of examples 4-12, in which in response to determining that user data fits into more than 2 but less than 512 system memory pages: for each page boundary aligned PRP entry inserting LB offset into lower 12 bits and setting bit[ 1 :0] = 2’b00; writing security context information at physical region page list table (PRPLT) location N inserting PRPL pointer in PRP2 field; creating the command and pushing into SQ; and maintaining the mapping of ({SQID, CID} -> N).

[0205] Example 14. The method of any of examples 4-13, in which in response to determining that user data fits into more than 512 system memory pages: for all but the last page boundary aligned PRP entry inserting LB offset into lower 12 bits, setting bit[ 1 :0] = 2’b00, and putting a pointer to next PRPL in to the last PRP entry; writing security context information at physical region page list table (PRPLT) location N inserting a first PRPL pointer in PRP2 field; creating the command and pushing into SQ; and maintaining the mapping of ({SQID, CID} -> N).

[0206] Example 15. The method of any of examples 4-14, further including: using PRPLT Index field of command, read PRPLT [N] (SLBA); finding a free location in LUT and entering PRP1 into that LUT location; calculating LB A to which this buffer maps; deleting PRPLT Pointer from Command and make it RSVD; and sending the modified Command to NVMe device.

[0207] Example 16. The method of any of examples 4-15, further including: receiving a command; parsing a command structure of the command, extracting the PRP details, and adding the extracted PRP details into the shadow in response to receiving read data for an access from memory; and storing a pointer to PRPL included in the command.

[0208] Example 17. The method of any of examples 4-16, further including: performing a content search on a PRPLT in response to determining that the device issued a request to read address (N) for reading PRPL to get a hit for location N; insert “N” into Read Tracking FIFO; forwarding the read access to system memory; popping the Read tracking FIFO to get “N” in response to determining that a read data for the access arrives from system memory; parsing the PRPL structure to extract the PRP details; and adding the PRP details to the shadow.

[0209] Example 18. The method of example 17, further including retrieving the PRP details from the shadow in response to receiving a request for user data access that hits one of the shadowed PRP.

[0210] Example 19. A method of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol by an inline cryptographic module of a processing system, including: identifying a first transaction from an NVMe device for reading a command entry of a command submission queue; reading command entry data of the command entry; generating a shadow of at least one page-level read/write pointer (PRP) of the command entry data in a first data structure; and modifying the command entry data to enable reading of the shadow of the at least one PRP, thereby generating modified command entry data.

[0211] Example 20. The method of example 19, in which generating the shadow of the at least one PRP of the command entry data in the first data structure includes generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from the command entry data.

[0212] Example 21. The method of either of examples 19 or 20, in which modifying the command entry data to enable reading of the shadow of the at least one PRP includes modifying an address of the at least one PRP of the command entry data to point to the shadow of the at least one PRP.

[0213] Example 22. The method of example 19, in which generating the shadow of the at least one PRP of the command entry data in the first data structure includes generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure.

[0214] Example 23. The method of example 22, in which the command entry data includes a reference to an entry for the at least one PRP in the second data structure, the method further including reading the entry for the at least one PRP in the second data structure, the entry for the at least one PRP in the second data structure including the address of the at least one PRP and the security context for the at least one PRP from the command entry data.

[0215] Example 24. The method of any of examples 19, 22, or 23, in which modifying the command entry data to enable reading of the shadow of the at least one PRP includes removing a reference to an entry for the at least one PRP in a second data structure.

[0216] Example 25. The method of any of examples 19-24, further including: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP; and implementing a cryptographic operation for data associated with the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP.

[0217] Example 26. The method of any of examples 19-25, further including: generating a shadow of a PRP list (PRPL) of the command entry data in the first data structure; and modifying the command entry data to enable reading of the shadow of the PRPL, thereby generating the modified command entry data.

[0218] Example 27. The method of any of examples 19-21, 25, or 26, in which generating the shadow of the PRPL of the command entry data in the first data structure includes generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command entry data.

[0219] Example 28. The method of any of examples 19-21 or 25-27, further including: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for reading the shadow of the PRPL; generating a shadow of each PRP of the PRPL in the first data structure; and modifying the each PRP of the PRPL to point to the shadow of the each PRP, generating a modified PRPL.

[0220] Example 29. The method of example 28, in which generating the shadow of the each PRP of the PRPL in the first data structure includes generating an entry for the each PRP of the PRPL in the first data structure, the entries for the each PRP of the PRPL in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP of the PRPL from an entry of the PRPL in the first data structure.

[0221] Example 30. The method of either of examples 28 or 29, further including: sending the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

[0222] Example 31. The method of any of examples 28-30, in which modifying the command entry data to enable reading of the shadow of the PRPL includes modifying an address of a PRPL pointer for the PRPL of the command entry data to point to the shadow of the PRPL.

[0223] Example 32. The method of any of examples 19 or 22-26, in which generating the shadow of the PRPL of the command entry data in the first data structure includes generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure.

[0224] Example 33. The method of example 32, further including: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for reading the PRPL, in which generating the shadow of the PRPL of the command entry data in the first data structure occurs in response to identifying the second transaction from the NVMe device; and modifying the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL.

[0225] Example 34. The method of example 33, further including: sending the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP. [0226] Example 35. The method of any of examples 19, 22-26, or 33-34, in which modifying the command entry data to enable reading of the shadow of the PRPL includes removing a reference to an entry for the PRPL in a second data structure.

[0227] Example 36. The method of any of examples 19, 22-26, or 33-35, in which the command entry data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL, the method further including writing the PRPL pointer to the second data structure at a location associated with the reference to the entry in the second data structure.

[0228] Example 37. The method of any of examples 19-36, in which the modified command entry data includes a virtual address, the method further including fetching a virtual address to physical address mapping for the virtual address in parallel with generating the shadow of the at least one PRP of the command entry data in the first data structure.

[0229] Example 38. The method of any of examples 19-37, in which identifying the first transaction from the NVMe device for reading the command entry of the command submission queue includes identifying an address of the transaction that is within at least one range of addresses for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline cryptographic module.

[0230] Example 39. A method of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol executed by a processing system, including: acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; writing a cryptographic enable to a command entry of the command for a submission queue; writing the cryptographic key slot reference to the command entry of the command for the submission queue; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue. [0231] Example 40. The method of example 39, further including: acquiring a page- level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to the command entry of the command for the submission queue, in which submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue includes submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue.

[0232] Example 41. The method of either of examples 39 or 40, in which: the command has more than one page-level read/write pointer (PRP); the method further including writing a logical block address offset to part of at least one PRP of the command entry of the command for the submission queue; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue includes submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the at least one PRP having the logical block offset.

[0233] Example 42. The method of either of examples 39 or 40, in which data of the command is larger than two system memory pages, the method further including writing a logical block address offset to part of at least one PRP of a PRP list (PRPL).

[0234] Example 43. The method of any of examples, 39, 40, or 42, in which: data of the command is larger than two system memory pages; the method further including writing a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue includes submitting the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer. [0235] Example 44. The method of any of examples, 39, 40, 42, or 43, in which data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL, the method further including writing a PRPL pointer to a PRP of a PRPL.

[0236] Example 45. The method of any of examples 39-44, further including: configuring a first set of one or more registers of an inline cryptographic module corresponding with a number of command submission queues; and setting each of the first set of one or more registers with an address range of a different one of the command submission queues.

[0237] Example 46. The method of example 45, in which setting each of the first set of one or more registers with the address range of a different one of the command submission queues includes setting each of the first set of one or more registers with a start address and a size of a different one of the command submission queues.

[0238] Example 47. The method of example 45, in which setting each of the first set of one or more registers with the address range of a different one of the command submission queues includes setting each of the first set of one or more registers with a start address and an end address of a different one of the command submission queues.

[0239] Example 48. The method of any of examples 45-47, further including: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues; and setting each of the second set of one or more registers with a start address and a size of a different one of the command submission queues.

[0240] Example 47. The method of examples 45-47, further including: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges; and setting each of the second set of one or more registers with a start address and a size of a different one of the exclusive address ranges.

[0241] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of operations in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.

[0242] The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the various embodiments may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0243] The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

[0244] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non- transitory computer-readable medium or a non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer- readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product. [0245] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

What is claimed is:

1. A method of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol by an inline cryptographic module of a processing system, comprising: identifying a first transaction from an NVMe device for reading a command entry of a command submission queue; reading command entry data of the command entry; generating a shadow of at least one page-level read/write pointer (PRP) of the command entry data in a first data structure; and modifying the command entry data to enable reading of the shadow of the at least one PRP, thereby generating modified command entry data.

2. The method of claim 1, wherein generating the shadow of the at least one PRP of the command entry data in the first data structure comprises generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from the command entry data.

3. The method of claim 1, wherein modifying the command entry data to enable reading of the shadow of the at least one PRP comprises modifying an address of the at least one PRP of the command entry data to point to the shadow of the at least one PRP.

4. The method of claim 1, wherein generating the shadow of the at least one PRP of the command entry data in the first data structure comprises generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure. 5. The method of claim 4, wherein the command entry data includes a reference to an entry for the at least one PRP in the second data structure, the method further comprising reading the entry for the at least one PRP in the second data structure, the entry for the at least one PRP in the second data structure including the address of the at least one PRP and the security context for the at least one PRP from the command entry data.

6. The method of claim 1, wherein modifying the command entry data to enable reading of the shadow of the at least one PRP comprises removing a reference to an entry for the at least one PRP in a second data structure.

7. The method of claim 1, further comprising: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP; and implementing a cryptographic operation for data associated with the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP.

8. The method of claim 1, further comprising: generating a shadow of a PRP list (PRPL) of the command entry data in the first data structure; and modifying the command entry data to enable reading of the shadow of the PRPL, thereby generating the modified command entry data.

9. The method of claim 8, wherein generating the shadow of the PRPL of the command entry data in the first data structure comprises generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command entry data.

10. The method of claim 8, further comprising: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for reading the shadow of the PRPL; generating a shadow of each PRP of the PRPL in the first data structure; and modifying the each PRP of the PRPL to point to the shadow of the each PRP, generating a modified PRPL.

11. The method of claim 10, wherein generating the shadow of the each PRP of the PRPL in the first data structure comprises generating an entry for the each PRP of the PRPL in the first data structure, the entries for the each PRP of the PRPL in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP of the PRPL from an entry of the PRPL in the first data structure.

12. The method of claim 10, further comprising: sending the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

13. The method of claim 8, wherein modifying the command entry data to enable reading of the shadow of the PRPL comprises modifying an address of a PRPL pointer for the PRPL of the command entry data to point to the shadow of the PRPL. 14. The method of claim 8, wherein generating the shadow of the PRPL of the command entry data in the first data structure comprises generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure.

15. The method of claim 14, further comprising: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for reading the PRPL, wherein generating the shadow of the PRPL of the command entry data in the first data structure occurs in response to identifying the second transaction from the NVMe device; and modifying the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL.

16. The method of claim 15, further comprising: sending the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

17. The method of claim 8, wherein modifying the command entry data to enable reading of the shadow of the PRPL comprises removing a reference to an entry for the PRPL in a second data structure.

18. The method of claim 8, wherein the command entry data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL, the method further comprising writing the PRPL pointer to the second data structure at a location associated with the reference to the entry in the second data structure.

19. The method of claim 1, wherein the modified command entry data includes a virtual address, the method further comprising fetching a virtual address to physical address mapping for the virtual address in parallel with generating the shadow of the at least one PRP of the command entry data in the first data structure.

20. The method of claim 1, wherein identifying the first transaction from the NVMe device for reading the command entry of the command submission queue comprises identifying an address of the transaction that is within at least one range of addresses for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline cryptographic module.

21. A method of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol executed by a processing system, comprising: acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; writing a cryptographic enable to a command entry of the command for a submission queue; writing the cryptographic key slot reference to the command entry of the command for the submission queue; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

22. The method of claim 21, further comprising: acquiring a page-level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to the command entry of the command for the submission queue, wherein submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue comprises submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue.

23. The method of claim 21, wherein: the command has more than one page-level read/write pointer (PRP); the method further comprises writing a logical block address offset to part of at least one PRP of the command entry of the command for the submission queue; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue comprises submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the at least one PRP having the logical block offset.

24. The method of claim 21, wherein data of the command is larger than two system memory pages, the method further comprising writing a logical block address offset to part of at least one PRP of a PRP list (PRPL).

25. The method of claim 21, wherein: data of the command is larger than two system memory pages; the method further comprises writing a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue comprises submitting the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

26. The method of claim 21, wherein data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL, the method further comprising writing a PRPL pointer to a PRP of a PRPL.

27. The method of claim 21, further comprising: configuring a first set of one or more registers of an inline cryptographic module corresponding with a number of command submission queues; and setting each of the first set of one or more registers with an address range of a different one of the command submission queues.

28. The method of claim 27, wherein setting each of the first set of one or more registers with the address range of a different one of the command submission queues comprises setting each of the first set of one or more registers with a start address and a size of a different one of the command submission queues.

29. The method of claim 27, wherein setting each of the first set of one or more registers with the address range of a different one of the command submission queues comprises setting each of the first set of one or more registers with a start address and an end address of a different one of the command submission queues.

30. The method of claim 27, further comprising: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues; and setting each of the second set of one or more registers with a start address and a size of a different one of the command submission queues. 31. The method of claim 27, further comprising: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges; and setting each of the second set of one or more registers with a start address and a size of a different one of the exclusive address ranges.

32. A computing device, comprising: a processing system; and a nonvolatile memory express (NVMe) inline cryptographic module coupled to the processing system, the NVMe inline cryptographic module configured to: identify a first transaction from an NVMe device for reading a command entry of a command submission queue; read command entry data of the command entry; generate a shadow of at least one page-level read/write pointer (PRP) of the command entry data in a first data structure; and modify the command entry data to enable reading of the shadow of the at least one PRP, thereby generating modified command entry data.

33. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to generate an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from the command entry data, to generate the shadow of the at least one PRP of the command entry data in the first data structure.

34. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to modify an address of the at least one PRP of the command entry data to point to the shadow of the at least one PRP to modify the command entry data to enable reading of the shadow of the at least one PRP. 35. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to generate an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure, to generate the shadow of the at least one PRP of the command entry data in the first data structure.

36. The computing device of claim 35, wherein: the command entry data includes a reference to an entry for the at least one PRP in the second data structure; and the NVMe inline cryptographic module is further configured to read the entry for the at least one PRP in the second data structure, the entry for the at least one PRP in the second data structure including the address of the at least one PRP and the security context for the at least one PRP from the command entry data.

37. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to remove a reference to an entry for the at least one PRP in a second data structure to modify the command entry data to enable reading of the shadow of the at least one PRP.

38. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to: send the modified command entry data to the NVMe device; identify a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP; and implement a cryptographic operation for data associated with the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP. 39. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to: generate a shadow of a PRP list (PRPL) of the command entry data in the first data structure; and modify the command entry data to enable reading of the shadow of the PRPL, thereby generating the modified command entry data.

40. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to generate an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command entry data, to generate the shadow of the PRPL of the command entry data in the first data structure.

41. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to: send the modified command entry data to the NVMe device; identify a second transaction from the NVMe device for reading the shadow of the PRPL; generate a shadow of each PRP of the PRPL in the first data structure; and modify the each PRP of the PRPL to point to the shadow of the each PRP, generating a modified PRPL.

42. The computing device of claim 41, wherein the NVMe inline cryptographic module is further configured to generate an entry for the each PRP of the PRPL in the first data structure, the entries for the each PRP of the PRPL in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP of the PRPL from an entry of the PRPL in the first data structure, to generate the shadow of the each PRP of the PRPL in the first data structure. 43. The computing device of claim 41, wherein the NVMe inline cryptographic module is further configured to: send the modified PRPL to the NVMe device; identify a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implement a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

44. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to modify an address of a PRPL pointer for the PRPL of the command entry data to point to the shadow of the PRPL to modifying the command entry data to enable reading of the shadow of the PRPL.

45. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to generate an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure, to generate the shadow of the PRPL of the command entry data in the first data structure.

46. The computing device of claim 45, wherein the NVMe inline cryptographic module is further configured to: send the modified command entry data to the NVMe device; identify a second transaction from the NVMe device for reading the PRPL, and in response to identifying the second transaction from the NVMe device, generate the shadow of the PRPL of the command entry data in the first data structure occurs; and modify the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL. 47. The computing device of claim 46, wherein the NVMe inline cryptographic module is further configured to: send the modified PRPL to the NVMe device; identify a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implement a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

48. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to remove a reference to an entry for the PRPL in a second data structure to modify the command entry data to enable reading of the shadow of the PRPL.

49. The computing device of claim 39, wherein: the command entry data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL; and the NVMe inline cryptographic module is further configured to write the PRPL pointer to the second data structure at a location associated with the reference to the entry in the second data structure.

50. The computing device of claim 32, wherein: the modified command entry data includes a virtual address; and the NVMe inline cryptographic module is further configured to fetch a virtual address to physical address mapping for the virtual address in parallel with generating the shadow of the at least one PRP of the command entry data in the first data structure.

51. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to identifying an address of the transaction that is within at least one range of addresses for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline encryption module, to identify the first transaction from the NVMe device for reading the command entry of the command submission queue.

52. A computing device, comprising: a nonvolatile memory express (NVMe) inline cryptographic module; and a processing system coupled to the NVMe inline cryptographic module, the processing system configured to: acquire a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; write a cryptographic enable to a command entry of the command for a submission queue; write the cryptographic key slot reference to the command entry of the command for the submission queue; and submit the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

53. The computing device of claim 52, wherein the processing system is further configured to: acquire a page-level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; write the PRPLT slot reference to the command entry of the command for the submission queue; and submit the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue to submit the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

54. The computing device of claim 52, wherein: the command has more than one page-level read/write pointer (PRP); and the processing system is further configured to: write a logical block address offset to part of at least one PRP of the command entry of the command for the submission queue; and submit the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the at least one PRP having the logical block offset to submit the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

55. The computing device of claim 52, wherein: data of the command is larger than two system memory pages; and the processing system is further configured to write a logical block address offset to part of at least one PRP of a PRP list (PRPL).

56. The computing device of claim 52, wherein: data of the command is larger than two system memory pages; and the processing system is further configured to: write a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submit the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer to submit the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue. 57. The computing device of claim 52, wherein: data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL; and the processing system is further configured to write a PRPL pointer to a PRP of a PRPL.

58. The computing device of claim 52, wherein the processing system is further configured to: configure a first set of one or more registers of an inline cryptographic module corresponding with a number of command submission queues; and set each of the first set of one or more registers with an address range of a different one of the command submission queues.

59. The computing device of claim 58, wherein the processing system is further configured to set each of the first set of one or more registers with a start address and a size of a different one of the command submission queues to set each of the first set of one or more registers with the address range of a different one of the command submission queues.

60. The computing device of claim 58, wherein the processing system is further configured to set each of the first set of one or more registers with a start address and an end address of a different one of the command submission queues to set each of the first set of one or more registers with the address range of a different one of the command submission queues.

61. The computing device of claim 58, wherein the processing system is further configured to: configure a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues; and set each of the second set of one or more registers with a start address and a size of a different one of the command submission queues.

62. The computing device of claim 58, wherein the processing system is further configured to: configure a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges; and set each of the second set of one or more registers with a start address and a size of a different one of the exclusive address ranges.

ABSTRACT

TITLE

Automatic Shadowing for Nonvolatile Memory Express (NVMe) Inline Encryption

RELATED APPLICATIONS

BACKGROUND

[0012] In some aspects, generating the shadow of the PRPL of the command entry data in the first data structure may include generating an entry for the PRPL in the first

3 data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command entry data.

[0017] In some aspects, generating the shadow of the PRPL of the command entry data in the first data structure may include generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure.

4 [0018] Some aspects may further include sending the modified command entry data to the NVMe device, identifying a second transaction from the NVMe device for reading the PRPL, in which generating the shadow of the PRPL of the command entry data in the first data structure occurs in response to identifying the second transaction from the NVMe device, and modifying the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL.

[0023] In some aspects, identifying the first transaction from the NVMe device for reading the command entry of the command submission queue may include identifying an address of the transaction that is within at least one range of addresses

5 for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline cryptographic module.

[0026] In some aspects, the command has more than one page-level read/write pointer (PRP). Some aspects may further include writing a logical block address offset to part of at least one PRP of the command entry of the command for the submission queue, and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue may include submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the at least one PRP having the logical block offset.

6 [0027] In some aspects, data of the command is larger than two system memory pages. Some aspects may further include writing a logical block address offset to part of at least one PRP of a PRP list (PRPL).

BRIEF DESCRIPTION OF THE DRAWINGS

[0040] FIG. 4 is a component block diagram illustrating an example NVMe system that does not include encryption support.

8 [0041] FIG. 5 is a component block diagram illustrating an example NVMe system that includes encryption support in accordance with some embodiments.

[0049] FIG. 22 is a component block and processes flow diagram illustrating a method for implementing a command creation stage for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

9 [0050] FIGS. 23 A and 23B are component block and processes flow diagrams illustrating methods for implementing command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

[0057] FIG. 30 is a component block and processes flow diagram illustrating a method for implementing read command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

10 [0058] FIG. 31 is a component block and processes flow diagram illustrating a method for command completion for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments.

DETAILED DESCRIPTION

[0064] Various embodiments include methods, and computing devices implementing such methods, for implementing an inline cryptographic module of a processing system for a nonvolatile memory express (NVMe) device. In some embodiments, the inline cryptographic module may be configured to automatically “shadow” all active physical region pages or page-level read/write pointers (PRPs) and/or scatter gather lists (SGLs) within the NVMe device. The NVMe device may also maintain 32

11 address ranges in registers that are associated with submission queues and programmed by device drivers during initialization. Access from the device in one of these ranges may indicate that it is trying to read commands from the submission queue (SQ). The data returned may be used to extract PRPs and/or SGLs, which may be used to determine the data that should be encrypted and the data that should remain unencrypted and unaltered.

[0067] A PRP refers to a data structure or mechanism used in memory management to keep track of the current position within a page of memory. The PRP may indicate an offset or location within a page where the next read or write operation should occur, allowing the system to access and manipulate specific portions of memory pages without having to work with the entire page at once. PRPs may be organized in

12 a PRP list (PRPL), which may be a data structure that maintains a collection or list of PRPs. Each entry in the PRPL may correspond to a particular memory page and may contain the PRP associated with that page. The PRPL may be used to manage multiple PRPs, typically for various pages of memory, within a system.

[0070] There are many challenges with implementing NVMe inline encryption. For example, there currently is no standard way to encrypt data that is being accessed and stored in an NVMe device in-line, with the encryption process occurring at the same time as the data storage and access. Currently, one must either lobby to change the NVMe specifications, impose impractical restrictions on device drivers, or bear the hefty silicon cost of maintaining a large number of descriptors in order to use inline

13 encryption with an NVMe device. Changing the NVMe specification would require significant effort and may not be feasible in the short term. Imposing restrictions on device drivers may limit the functionality of the device and could lead to compatibility issues.

[0073] By maintaining only 32 register address ranges of submission queues, all PRPs may be shadowed inside NVMe device and simplify the search logic for identifying incoming user data buffer accesses. Another benefit or advantage of the embodiments is that the complex search logic of finding PRPs from 4 million possibilities reduces to merely 32 ranges, which may be efficiently implemented in

14 HW. Yet another advantage of the embodiments is that they may significantly reduce the SRAM volume to 8KB (whereas conventional solutions could require 4MB SRAM with a complex search logic beforehand). For these and other reasons, the various embodiments may reduce costs significantly. The embodiments may allow access to inline encryption without sacrificing system cost or performance when using an NVMe device.

[0075] The term “system-on-chip” (SoC) is used herein to refer to a set of interconnected electronic circuits typically, but not exclusively, including a processing device, a memory, and a communication interface. A processing system 12 may include a variety of different types of processors 14 some of which may include multiple processor cores. Non-limiting examples of processors that may be included in a computing device 10 and implemented in or coupled to a processing system 12 include a general purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a secure processing unit (SPU), a neural network processing unit (NPU), a subsystem processor of specific components of the computing device, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, a multicore processor, a controller, and a

15 microcontroller. A processing system 12 may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material in what may be referred to as a system-on-chip (SoC).

[0077] The processing system 12 may be implemented with a bus architecture, represented generally by the bus 32. The bus 32 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 12 and the overall design constraints. The bus 32 links together various circuits including one or more processors 14 and/or hardware components, represented by the processor (or processing circuitry) 14, the illustrated components, and the computer-readable medium / memory (or memory circuitry) 16. The processor(s) 14 may include multiple processors. The memory 16 may include multiple memories. The bus 32 may also link various other circuits, such as a clock controller 30, interface circuitry 18, 20, voltage regulators (not shown), and/or power management circuits (e.g., power manager 28).

16 [0078] The computing device 10 may include any number and combination of memories, such as the memory 16 integral to the processing system 12 and the memory 36 separate from the processing system 12. Any of the memories 16, 36 may be a volatile or non-volatile memory configured for storing data and processorexecutable code for access by the processor 14. The computing device 10 and/or the processing system 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memories such as random access memory (RAM) or main memory, including static RAM (SRAM), such as the memory 16, dynamic RAM (DRAM), such as the memory 36, or cache memory.

[0081] The storage memory interface 20 and the storage memory 24 may work in unison to allow the computing device 10 to store data and processor-executable code on a non-volatile storage medium, such as a nonvolatile memory express (NVMe) memory device. The storage memory 24 may be configured much like an

17 embodiment of the memory 16 in which the storage memory 24 may store the data or processor-executable code for access by one or more of the processors 14. The storage memory 24, being non-volatile, may retain the information after the power of the computing device 10 has been shut off. When the power is turned back on and the computing device 10 reboots, the information stored on the storage memory 24 may be available to the computing device 10. The storage memory interface 20 may control access to the storage memory 24 and allow the processor 14 to read data from and write data to the storage memory 24.

[0083] The power manager 28 may be configured to control power states of one or more power rails (not shown) for power delivery to the components of the processing system 12. In some embodiments, the power manager 28 may be configured to control amounts of power provided to the components of the processing system 12. For example, the power manager 28 may be configured to control connections between components of the processing system 12 and the power rails. As another example, the power manager 28 may be configured to control amounts of power on the power rails connected to the components of the processing system 12. The power manager 28 may be configured as a power management integrated circuit (power management ICs or PMIC).

18 [0084] A clock controller 30 may be configured to control clock signals transmitted to the components of the processing system 12. For example, the clock controller 30 may gate a component of the processing system 12 by disconnecting the component of the processing system 12 from a clock signal and may ungate the component of the processing system 12 by connecting the component of the processing system 12 to the clock signal.

[0088] The processing system 202, which may be implemented as an SoC, may include one or more processors 14, a peripheral component interface express (PCIe) controller 212 (e.g., storage memory interface 20 in FIG. 1), and an inline cryptographic module 38 connected to each other by various communication buses.

19 The one or more processors 14 may be configured to implement software, such as applications 204, including a high-level operating system, a kernel 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 may manage communication between components of the processing system 202, including the inline cryptographic module 38, and the NVMe device 214. Such communications may include communications for preparation and implementation of NVMe commands from the one or more processors 14 for data transactions, such as read and/or write transactions, at the NVMe device 214.

[0090] A software running on the processing system 202, the NVMe driver 208, and/or the application 204, may issue a request to use a specific algorithm for encryption and a set of encryption keys, use a specific security context, and/or ask to send data without encryption. Setting the security context, encryption keys, and/or encryption algorithm may be implemented by any of the software running on the processing system 202, the NVMe driver 208, and/or the application 204 while using a security context, encryption keys, and/or an encryption algorithm to encrypt or decrypt the data can be done by another software entity.

20 [0091] The inline cryptographic module 38 may also support secure key management. In some examples, the inline cryptographic module 38 may function independently of PCIe structures and its different layers, enable scalable storage throughput, and be compliant with NVMe device protocols. In other examples, the inline cryptographic module 38 may be part of the PCIe controller 212. The inline cryptographic module 38 is described further herein.

[0095] The NVMe security ID may be a combination of data, such as an NVMe command submission queue identifier and an NVMe command identifier for the NVMe command. The NVMe command submission queue identifier may identify an

21 NVMe command submission queue to which the NVMe driver 208 may write the NVMe command.

[0098] The security context structure 302 may be a data structure, such as a table, array, linked list, graph, etc., configured to store various data in association with each other. For example, the security context structure 302 may store data of the NVMe security ID and a security context for the NVMe command in association with each other. The NVMe security ID in the buffer address lookup structure 300 and the security context structure 302 for the same NVMe command may be the same. The security context may include a combination of security related information, such as an encryption algorithm, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, etc. In some examples, the security context may be provided by an application executed by the processor 14 from the execution of which the NVMe command originates. The security context structure 302 may store any amount of associated data, such as more than one set of associated data for more than one NVMe command.

22 [0099] The buffer address lookup structure 300 and the security context structure 302 may be configured at the inline cryptographic module 38 during an NVMe command submission stage. In some examples, the NVMe driver (e.g., NVMe driver 208 in FIG. 2) may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command issued by a processor (e.g., processor 14). The NVMe driver may provide the inline cryptographic module 38 with the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data as the buffer address lookup structure 300 and the security context structure 302. Such data may include any combination of buffer addresses, NVMe security IDs, sector offsets, and/or security contexts for NVMe commands. In such examples, the NVMe driver may maintain the same address information at two different locations, a processing system memory (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2) and at the buffer address lookup structure 300.

[0100] In some embodiments, the inline cryptographic module 38 may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command from the NVMe driver. The inline cryptographic module 38 may process the NVMe command, extracting the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data as the buffer address lookup structure 300 and the security context structure 302. The inline cryptographic module 38 configuring the buffer address lookup structure 300 and the security context structure 302, rather than the NVMe driver, eliminates the previously described address redundancy issue and maintains data integrity. Further, overhead on software to configure the buffer address lookup structure 300 in the inline cryptographic module 38 is reduced.

23 [0101] The inline cryptographic module 38 may be configured to forward a doorbell signal configured to indicate to an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2) of a pending NVMe command. For example, the inline cryptographic module 38 may update an NVMe command submission queue tail point to a “doorbell” register of the NVMe device. Forwarding the doorbell signal may enable bypassing or foregoing inclusion of software configured to write two doorbells, and may ensure that the operation of the cryptographic module 38 and the NVMe device are synchronized.

[0103] Using the retrieved information, such as the sector offset and/or the security context, the encryption module 304 and/or the decryption module 306 may implement the cryptographic function for the data of the NVMe transaction. For example, the retrieved information may include the security context from the security context structure 302, which may include an encryption algorithm, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, etc. The encryption module 304 may use the retrieved information of the security context to encrypt the data to be sent to the NVMe device for the NVMe transaction. The decryption module 306 may use the retrieved information of the

24 security context to decrypt the data received from the NVMe device for the NVMe transaction.

[0107] With reference to FIGs. 1-5, in the example illustrated in FIG. 5, the host memory 402 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2) includes a NVMe-ICE module 500 (e.g., inline cryptographic module 38 in FIGs. 1-3), which may be an encryption/decryption layer between the host driver and the NVMe device controller 214. The Command Submission operations may include: (1) the NVMe Device driver (e.g., NVMe driver 208 in FIG. 2) at the Host 400 (e.g., processing system 12 in FIG. 1, processor 14 in FIGs. 1 and 2, processing system 202 in FIG. 2) writing commands to the submission queue (SQ) 404 at the host memory 402; (2) the NVMe Device driver at the Host 400 configuring the NVMe-ICE module 500 for inlining encryption of NVMe transactions; and (3) the NVMe Device driver at the Host 400 writing an updated SQ Tail ptr (“ Tail” in FIG. 5) to the Doorbell 408 (“SQ Tail doorbell” in FIG. 5) (e.g., a “doorbell” register) at the NVMe device controller 214. The Command Processing operations may include: (4) the NVMe device controller 214 fetching a command from the SQ 404 and updates the SQ head ptr

26 (“Head” in FIG. 5) with a next command; (5) the NVMe device controller 214 processing the command and/or the updated SQ head ptr; and (6) the NVMe-ICE module 500 encrypting/decrypting the data for the command. For example, the NVMe-ICE module 500 may encrypt write data sent to the NVMe device controller 214 for a write command and/or decrypt read data received from the NVMe device controller 214 for a read command. The Command Completion operations may include: (7) the NVMe device controller 214 writing completion of the command to the completion queue (CQ) 406 at the host memory 402 and updating CQ tail ptr (“Tail” in FIG. 5) to doorbell; (8) the NVMe device controller 214 generating a CQ Platform specific interrupt, such as an MSI-X interrupt, for notification of completion status to the host driver; (9) the host 400 processing completion of the command, and (10) the host 400 writing the CQ Head ptr (“Head” in FIG. 5) to the Doorbell 410 (“CQ Head doorbell” in FIG. 5) (e.g., a “doorbell” register) at the NVMe device controller 214.

[0108] The SQ 404 and the CQ 406 are used to manage communications between the Host 400 and the NVMe device 214. The SQ 404 may be used by the Host 400 to queue commands to be sent to the NVMe device 214. These commands may include any command from the NVMe standard, such as read, write, management commands, etc. The CQ 406 may be used by the NVMe device 214 to notify the Host 400 about a completion status of command processed from the SQ 404, such as successful completion or failure to complete. When a command is executed, the NVMe device controller 214 may place a completion entry in the CQ 406 to inform the Host 400 about the completion of the operation. The SQ 404 and CQ 406 may be circular buffers, arrays, etc. for which locations may be statically or dynamically indicated as a starting location (head) and an ending location (tail). An entry at the head of the SQ 404 may be for a next command to be implemented and an entry at the tail of the SQ 404 may be for a last command to be implemented. An entry at the head of the CQ 404 may be for an oldest completed command and an entry at the tail of the CQ 404 may be for a most recently completed command. The SQ 404 and the CQ 406 may be

27 sized to store at least two entries, including thousands of entries, such as 64,000 entries.

[0113] FIG. 7 illustrates some of the technical challenges associated with determining which accesses (e.g., SQ, CQ, PRPL, I/O access, etc.) need cyphering in order to be able to securely transfer data from an NVMe device. With reference to FIGs. 1-7, NVMe devices (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIGs. 2, 5, and 6) use SQ, CQ, PRPL, and I/O access for various data transfer activities. The four primary types of access in the NVMe processing system that are illustrated in FIG. 7 are write address, read address, write data, and read data. As a nonlimiting example, various types of access using Advanced extensible Interface (AXI) protocols may include AXI write address (AWADDR), AXI read address (ARADDR), AXI write data (WDATA), and AXI read data (RD ATA). FIG. 7 also illustrates that SQ access for command fetch should not be cyphered, CQ access for

29 completion entry should not be cyphered, PRPL access for descriptor fetch should not be cyphered, but I/O access with user data transfer should be cyphered.

[0116] The theoretical maximum size for the databases that hold start and end addresses for each SQ, CQ, PRP List and PRP is 384KB, 384KB, 3TB and 1536TB,

30 respectively. These sizes may be prohibitive for consumer-grade laptops or desktops, for which the following requirements may be applicable: NVMe device supports 32 SQs and 32 CQs; SQ table holds 32 entries (192B storage); CQ table holds 32 entries (192B storage); 8K commands, with 2MB per transaction may enough to keep PCIe links busy; PRPL Table 800 holds 8K entries (8K * 1) and thus 48KB storage; each PRPL may include up to 512 PRP entries, PRP Table 802 may include 4 million entries (8K * 512) - 24MB storage.

[0119] Some embodiments may take advantage of reserved fields in an NVMe command structure that hold a PRPL Index of a command entry, so as to create a shadow of all PRPs cached inside the NVMe Device. The system may initiate this

31 process by configuring its submission queues (SQs) with their base addresses and queue size (Qsize) values, then performing the same operations for the completion queues (CQs). As a result, the system may enqueue the commands without requiring PRPLs.

[0121] That is, when enqueuing commands, no page-level read/write pointers lists (PRPLs) may be required if user data fits inside one or two system memory pages. However, if more than two pages, up to the threshold of system memory pages are needed, then a PRPL may be used. If more than the threshold of system memory

32 pages are needed, then multiple PRPLs may be required for chaining together (PRPL creation process). For more than 2 pages, LB offset into lower 12 bits may be inserted into each PRP entry after a first PRP entry, including each entry in each PRPL. For more than the threshold of system memory pages a pointer to the next PRPL may be in the last PRP entry(s) of each prior PRPL. When processing commands, security context information may also be written at PRPLT location N. In examples using at least one PRPL, a first PRPL pointer may be inserted into a PRP2 field if its more than, such as when the data requires more than 2 pages while pushing into SQ and maintaining mapping {SQID, CID} -> N or {SQID, CID, NSID} -> N. These embodiments may reduce the total SRAM requirement for caching all PRP entries down only 8KB even with a large number of commands present making implementation using internal SRAM possible without sacrificing performance efficiency.

[0123] The example illustrated in FIG. 10A shows a command structure 1000 having data that requires a one page buffer. In addition to the PRPLT pointer, the command

33 structure 1000 may include a PRP (“PRP1”) (e.g., PRP 626 in FIG. 6) with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer. As the data requires a one page buffer, another PRP (“PRP2”) may have default data (e.g., zeros, null value, etc.) configured to indicate no association to a location in the memory.

[0126] The examples illustrated in FIGs. 12A and 12B show a PRPL structure 1200, which may be representative of multiple PRPL structures 1200, and an associated command structure 1202 having data that requires more than the threshold of system

34 memory pages page buffers. The PRPL structure 1200 may include at least two PRPs (“PRP2”, “PRP3”) (e.g., PRP 626 in FIG. 6), up to 510 PRPs, each with an association to a location (e.g., location 630 in FIG. 6) in the memory, such as a page buffer, respectively. For the PRPL structure 1200 being insufficient to hold all of the PRPs, an entry in the PRPL structure 1200 may be pointer to a next PRPL structure 1200 (“ptr to next PRPL”). A last PRPL structure 1200 having a last PRP for the command structure 1202 may exclude the pointer to a next PRPL structure 1200, like the PRPL structure 1100. The PRPL structure 1200 may include an LB offset (“Loffsetl”, “Loffset2”) for each PRP. In addition to the PRPLT pointer, the command structure 1202 may include a PRP (“PRP1”) with an association to a location in the memory, such as a page buffer. Additionally, the command structure 1202 may include a PRPL (“PRPL Pointer”) with an association to the PRPL structure 1200.

[0127] FIGs. 13-17 illustrate example information structures and operations in computing systems configured to implement various embodiments. With refence to FIGs. 1-17, the information structures and operations may be implemented in a computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) and/or an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIGs. 2, 5, and 6). For example, the information structures and operations may be implemented in any combination of components of the computing system, including a host memory (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2, host memory 402 in FIG. 5, system memory space 602 in FIG. 6), a host processing system (e.g., processing system 12 in FIG. 1, processing system 202 in FIG. 2, host 400 in FIG. 5, processing system 600 in FIG. 6) configured to execute a host software (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via one or more processors (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module (e.g., NVMe inline cryptographic module 38 in FIGs. 1-3, NVMe-ICE module 500 in FIG. 5) and a PCIe root complex (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6).

35 In some examples, the host software may be an operating system (e.g., Android, Windows, iOS, etc.).

[0133] As an example, as illustrated in FIG. 14, if the system receives a command (CMD) 1002 with two valid PRPs (e.g., PRP 626 in FIG. 6), “PRP1” and “PRP2”, then, in block 1310, the system could use a PRPLT index field of a command 1002 to read PRPLT [N] (i.e., a location in the PRPLT SRAM 1300), which may contain a start logical block address (SLBA) and/or a namespace identifier (NSID) for the command 1002.

37 [0134] In block 1410, the system may look for a free location in an LUT (e.g., in the LUT SRAM 1302) to enter relevant PRP1 details with a recalculated LB A and/or the NSID that the buffer maps to. The system may delete the pointer related to the PRPLT from command 1002 and make it reserved (“RSVD”) in block 1316 and send the modified command 1400 towards its destination, the NVMe device, in block 1318. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0136] Continuing from the example illustrated in FIG. 15, in the example illustrated in FIG. 16, a PRPL 1100 may be associated with the PRPL Pointer (e.g., PRPL pointer 628 in FIG. 6) of the command 1502 that was written to the PRPLT SRAM 1300. Each entry of incoming data for the command 1502 may be one PRP (e.g., PRP

38 626 in FIG. 6) of the PRPL 1100. In block 1610, the system may find a free location in the LUT (e.g., in the LUT SRAM 1302) for each PRP of the PRPL 1100, and enter that PRP into that LUT location, with a recalculated LBA and/or a namespace identifier (NSID) that the buffer maps to. The system may delete a logical block offset (“Loffsetl”, “Loffset2”, “Loffset3”) for each PRP from the PRPL 1100 in block 1612, such as by overwriting the Loffset with zeros, and send the modified PRPL 1600 towards its destination, the NVMe device, in block 1614. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0139] In some embodiments, the pointer to a next PRPL in the PRPL 1200 and written to the PRPLT [N] location in the PRPLT SRAM 1300 may point to another PRPL 1200, and the example illustrated in FIG. 17 may repeat implementation. Such repetitions may occur for each subsequent PRPL 1200. In some embodiments, the

39 pointer to a next PRPL in the PRPL 1200 and written to the PRPLT [N] location in the PRPLT SRAM 1300 may point to a PRPL 1100, and the example illustrated in FIG. 16 may be implemented. This implementation may occur following one or more implementations of the example illustrated in FIG. 17. These operations may ensure that information present within the shadow corresponds to the information stored in NVMe Device (e.g., the shadow includes the same PRPs as the NVMe device).

[0144] As an example, in relation to the example illustrated in FIG. 13, if user data fits in the first system memory page, the system may write Security Context information at PRPLT location N in the PRPLT SRAM 1300, write PRPLT Index = N in the command 1000, proceed with other steps for Command creation and push the

40 command 1000 into an SQ, and maintain a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0151] When the NVMe device issues an access that hits one of the shadowed PRPs in the LUT SRAM 1302, it may be for user data access. The system may execute a Cypher operation for data associated with PRPs of the ranges of shadowed PRPs.

42 When access to a data (e.g., 4KB, 16KB, 64KB, etc.) associated with a PRP is completed, the system may evict the PRP from the shadow. They system now has 100% true shadow of all PRPs, that are dynamically maintained inside the NVMe Device using only 8KB.

[0153] FIG. 18 illustrates an NVMe inline cryptographic module. With reference to FIGS. 1-18, the NVMe inline cryptographic module 38 (e.g., inline cryptographic module 38 in FIGS. 1-3, NVMe-ICE module 500 in FIG. 5) may be configured to manage command parsing and an LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) for implementing NVMe inline cryptographic processes using PRPs (e.g., PRP 626 in FIG. 6) in computing systems (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2). The NVMe inline cryptographic module 38 may also include other components for implementing NVMe inline cryptographic processes using PRPs, including exclusive address range registers 1804, which may be for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. The NVMe inline cryptographic module 38 may include SQ and CQ address

43 range registers 1806, which may be configured for storing start addresses, end addresses, and/or sizes of one or more submission queues (e.g., SQ 404 in FIG. 5) and/or SQ entries and command queues (e.g., completion queue 406 in FIG. 5) and/or CQ entries.

[0155] FIG. 19 illustrates an example of a structure of a command processed by the NVMe inline cryptographic module 38. With reference to FIGS 1-19, a structure of a command 1900 (e.g., command 902, 1000, 1002, 1102, 1202, 1502 in FIGs. 9B-15) may be for I/O accesses involving user data transfer that should be encrypted for security purposes, including read and/or write commands. The structure of the command 1900 may be a modified version of a common submission command format for NVMe implementation. For example, the structure of a command 1900 may include aspects typically included in a submission command format, such as a command identifier (CID), a PRP or SGL for data transfer indicator (PSDT), a fuse indicator, and opcode, a namespace identifier (NSID), a metadata pointer (MPTR), and PRP pointers (e.g., PRP1, PRP2) (e.g., PRP 626 in FIG. 6) and/or PRPL pointers (e.g., at PRP2) (e.g., PRPL pointer 628 in FIG. 6). The modifications to the structure of a command 1900 may include a cryptographic function enable indicator (CE), which may include a bit located at a commonly reserved space, for example, command word (CWD) 0, bit 10. The cryptographic function enable indicator may be configured to enable and/or disable the cryptographic functions of the NVMe inline

44 cryptographic module 38. The modifications may also include a key slot locator, which may be any combination of bits, such as 8 bits, located at commonly reserved space, for example, CWD3, bits 23 : 16. The key slot locator be configured to enable the NVMe inline cryptographic module 38 to locate an appropriate cryptographic key from a key table 1812 to implement the cryptographic functions.

[0158] The NVMe inline cryptographic module 38 may perform on the fly PRP address modification at the data of the command 1900, replacing PRP address bits (e.g., PRP1 and/or PRP2) with the corresponding LUT index. For example, the

45 NVMe inline cryptographic module 38 may replace some of the address bits, such as in the range of bits 63 : 12. Replacing some of the address bits may enable maintaining an original PRP address offset within a page, such as 4KB page. In some examples, the NVMe inline cryptographic module 38 may tag the PRP address as modified through setting of one or more specific bits of the PRP address, such as bit 63. In some embodiments, the PRP address may be modified such that the modified address may be within a range defined by a software (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2) configured to not overlap with an exclusion range or other range used by the software and that is not in the LUT 1800. The NVMe inline cryptographic module 38 may use the index of the LUT 1800 to locate the PRP entry and/or PRPL pointer entry and the security context associated with a command as described further herein.

[0160] The host software 2100 may enumerate one or more NVMe devices 214 by implementing a process 2102 and detect the PCIe root complex 212 and an NVMe

46 device 214 by implementing a process(es) 2104. The host software 2100 may load an NVMe driver (e.g., NVMe driver 208 in FIG. 2) for the NVMe device 214 by implementing a process 2106 and initialize a PCIe controller, of the PCIe root complex 212, by implementing a process 2108.

[0163] FIG. 22 illustrates a method for implementing a command creation stage for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-22, the computing

47 system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0164] The host software 2100 may execute a command creation stage in which the host software 2100 may create a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in FIGS. 9B-15, 19) for reading from and/or writing to the host memory 36. Such commands may be for I/O accesses involving user data transfer that should be encrypted for security purposes. The host software 2100 may implement various processes for creating the command that enable cryptographic functions of the NVMe inline cryptographic module 38 for implementing the command. The host software 2100 may acquire cryptographic key slot data for a command that requires cryptographic functions by implementing a process 2200. The host software 2100 may create the command, programming the data of the command in a submission queue command entry, including key slot data and a cryptographic function enable in a process 2202. The key slot data may be configured to enable the NVMe inline cryptographic module 38 to locate an appropriate cryptographic key from a key table (e.g., key table 1812 in FIG. 18) to implement the cryptographic functions. The cryptographic function enable indicator may be set to enable cryptographic functions of the NVMe inline cryptographic module 38.

48 [0165] The host software 2100 may submit the command to the host memory 36 for addition to the submission queue (e.g., SQ 404 in FIG. 5) in response to the submission queue command entry by implementing a process 2204. The host software 2100 may update the submission queue doorbell (e.g., Doorbell 408 in FIG. 5) at the NVMe device 214 by implementing a process 2206.

6). The embodiment illustrated in FIG. 23B relates to a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in FIGS. 9B-15, 19) having at least one PRP entry (e.g., PRP 626 in FIG. 6) and at least one PRPL entry (e.g., PRPL pointer 628 in FIG. 6). The processes of the embodiments illustrated in FIGS. 23 A and 23B may be implemented in a similar maimer unless otherwise noted.

49 [0168] The NVMe device 214 may implement a transaction with the NVMe inline cryptographic module 38 for reading a command entry from the command submission queue (e.g., SQ 404 in FIG. 5) by implementing a process 2300. In some embodiments, the transaction may be an AXI transaction. The NVMe inline cryptographic module 38 may respond to the transaction by parsing and validating the incoming transaction by implementing a process 2302. The data of the validated transaction may be used by the NVMe inline cryptographic module 38 to forward the transaction for reading a command entry from the command submission queue (e.g., SQ 404 in FIG. 5) to the host memory 36 by implementing a process 2304. The host memory 36 may respond to the transaction by returning read data from the corresponding command submission entry by implementing a process 2306.

[0170] In the embodiment illustrated in FIG. 23B, for which the read data from the corresponding command submission entry includes at least one PRP entry (e.g., PRP 626 in FIG. 6) and at least one PRPL entry (e.g., PRPL pointer 628 in FIG. 6), the NVMe inline cryptographic module 38 may update the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) and modify the data from the

50 command submission entry on the fly by implementing a process 2312. For example, the NVMe inline cryptographic module 38 may update the LUT 1800 by adding entries for the at least one PRP entry and the at least one PRPL entry of the submission command by adding an index, the PRP address and the PRPL address, and security context for each PRP and PRPL entry, an example of which is shown in the LUT 1800 in FIG. 25. The NVMe inline cryptographic module 38 may modify the data of the command submission entry by replacing the PRP address data and the PRPL address data with the corresponding index of the LUT 1800, an example of which is shown in the data of the command 1900 in FIG. 24.

[0173] When the entry read from the command submission queue (e.g., SQ 404 in

FIG. 5) includes a PRP list (e.g., PRPL 622, 1100, 1200 in FIGs. 6, 11A, 12A, 16, 17),

51 such as the embodiment described with reference to FIG. 23B, the entries of the PRP list may also be read. The NVMe device 214 may implement a transaction with the NVMe inline cryptographic module 38 for reading each PRP entry (e.g., PRP 626 in FIG. 6) from the PRP list by implementing a process 2600. In some embodiment, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP list received in the modified data of the command submission entry in the embodiment described with reference to FIG. 23B. The NVMe inline cryptographic module 38 may find the LUT index in the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) and retrieve the corresponding PRP list address and security context by implementing a process 2602. The NVMe inline cryptographic module 38 may forward the transaction for reading the PRP list entries from the command submission queue to the host memory 36 by implementing a process 2604. The host memory 36 may respond to the transaction by returning read data from the corresponding command submission entry by implementing a process 2606.

[0175] FIG. 29 illustrates a method for implementing write command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to

52 implement various embodiments. With reference to FIGS. 1-29, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5), a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some e embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0176] The NVMe device 214 may transmit a transaction to the NVMe inline cryptographic module 38 for writing data from the host memory 36 by implementing a process 2900. In some embodiments, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP (e.g., PRP 626 in FIG. 6) received in the modified data of the command submission entry in the embodiments described with reference to FIGS. 23 A and 26. The NVMe inline cryptographic module 38 may parse and validate the transaction by implementing a process 2902. Data parsed from the transaction may include the LUT index. The NVMe inline cryptographic module 38 may use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in FIG. 6) subject to the write command and the security context from the LUT 1800 by implementing a process 2904. The data of the validated transaction and retrieved from the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) may be used by the NVMe inline cryptographic module 38 to forward the transaction for reading from the address of the PRP to the host memory 36 by implementing a process 2906. The host memory 36 may respond to the transaction by reading write data from the host memory 36 and returning write data from the corresponding address of the PRP by

53 implementing a process 2908. The NVMe inline cryptographic module 38 may encrypt the received write data by implementing a process 2910. For example, encryption may be implemented by using the key slot of the security context to retrieve the cryptographic key for implementing encryption. The NVMe inline cryptographic module 38 may transmit the encrypted write data to the NVMe device 214 by implementing a process 2912.

[0178] The NVMe device 214 may transmit a transaction to the NVMe inline cryptographic module 38 for reading data from an NVMe device logical block address to write the host memory 36 by implementing a process 3000. In some embodiments, the transaction may be an AXI transaction. The transaction may specify the LUT index for the corresponding PRP (e.g., PRP 626 in FIG. 6) received in the modified data of the command submission entry in the embodiments described with reference to FIGS. 23 A and 26. The NVMe device 214 may transmit encrypted data from the NVMe device logical block address by implementing a process 3002. The NVMe

54 inline cryptographic module 38 may parse and validate the transaction by implementing a process 3004. Data parsed from the transaction may include the LUT index. The NVMe inline cryptographic module 38 may use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in FIG. 6) subject to the read command and the security context from the LUT 1800 (e.g., PRP Table 802 in FIG. 8, LUT SRAM 1302 in FIGs. 13-17) by implementing a process 3006. The NVMe inline cryptographic module 38 may decrypt the received encrypted data by implementing a process 3008. For example, decryption may be implemented by using the key slot of the security context to retrieve the cryptographic key for implementing decryption. The data of the validated transaction and retrieved from the LUT 1800 may be used by the NVMe inline cryptographic module 38 to forward the transaction for writing to the address of the PRP to the host memory 36 by implementing a process 3010. The NVMe inline cryptographic module 38 may transmit the decrypted data for writing to the address of the PRP to the host memory 36 by implementing a process 3012.

[0179] FIG. 31 illustrates a method for command completion for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various embodiments. With reference to FIGS. 1-31, the computing system (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200 in FIG. 2) may include a host memory 36 (e.g., host memory 402 in FIG. 5) , a host processing system 202 (e.g., host 400 in FIG. 5, processing system 600 in FIG. 6), which may be implemented as an SoC, configured to execute a host software 2100 (e.g., application 204, kernel 206, NVMe driver 208, PCIe driver 210 in FIG. 2), such as via a processor (e.g., processor 14 in FIGS. 1 and 2, host 400 in FIG. 5), and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in FIG. 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in FIG. 2, PCIe root complex 606 in FIG. 6), and a NVMe device 214 (e.g., storage memory 24, in FIG. 1). In some embodiments, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

55 [0180] The NVMe device 214 may a write a command completion entry to the command queue (e.g., CQ 406 in FIG. 5) and update the command queue’s tail doorbell point at the host memory 36 by implementing a process 3100. The NVMe device 214 may transmit a command completion interrupt to the host software 2100 by implementing a process 3102. The host software 2100 may implement a driver process command completion by implementing a process 3104. The host software 2100 may write the command queue head pointer to the command queue head pointer doorbell (e.g., Doorbell 410 in FIG. 5) at the NVMe device 214 by implementing a process 3106.

[0182] The processes of the examples illustrated in FIGS. 32A and 32B may be implemented in the same maimer as described herein. For example, the command creation stage may be implemented as described with reference to FIG. 22, the

56 command process 2300, 2302, 2304, 2306, 2308, 2310, 2312 may be implemented as described with reference to FIGS. 23 A and 23B, the NVMe device initiating data transfer may be implemented as described with reference to FIGS. 29 and 30, and the command completion stance may be implemented as described with reference to FIG. 31.

[0184] Various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-32B) may be implemented in a wide variety of computing systems including mobile computing devices, an example of which suitable for use with the various embodiments is illustrated in FIG. 33. The mobile computing device 3300 may include a processor 3302 coupled to a touchscreen controller 3304 and an internal memory 3306. The processor 3302 may be one or more multicore integrated circuits designated for general or specific processing tasks. The internal memory 3306 may be volatile or non-volatile memory and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. Examples of memory types that can be leveraged include but are not limited to DDR, LPDDR, GDDR, WIDER), RAM, SRAM, DRAM, P-RAM, R- RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 3304

57 and the processor 3302 may also be coupled to a touchscreen panel 3312, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the mobile computing device 3300 need not have touch screen capability.

[0187] The mobile computing device 3300 may also include speakers 3314 for providing audio outputs. The mobile computing device 3300 may also include a housing 3320, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components described herein. The mobile computing device 3300 may include a power source 3322 coupled to the processor 3302, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the mobile computing device 3300. The mobile computing device 3300

58 may also include a physical buton 3324 for receiving user inputs. The mobile computing device 3300 may also include a power buton 3326 for turning the mobile computing device 3300 on and off

[0189] The various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-32B) may also be implemented in fixed computing systems, such as any of a variety of commercially available servers. An example server 3500 is illustrated in FIG. 35. Such a server 3500 typically includes one or more multicore processor assemblies 3501 coupled to volatile memory 3502 and a large capacity nonvolatile memory, such as a disk drive 3504. As illustrated in FIG. 35, multicore processor assemblies 3501 may be added to the server 3500 by

59 inserting them into the racks of the assembly. The server 3500 may also include a floppy disc drive, compact disc (CD) or digital versatile disc (DVD) disc drive 3506 coupled to the processor 3501. The server 3500 may also include network access ports 3503 coupled to the multicore processor assemblies 3501 for establishing network interface connections with a network 3505, such as a local area network coupled to other broadcast system computers and servers, the Internet, the public switched telephone network, and/or a cellular data network (e.g., CDMA, TDM A, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network).

[0191] Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of example systems, devices, or methods, further example implementations may include: the example systems or devices discussed in the following paragraphs implemented as a method executing operations of the example systems or devices; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising an NVMe inline cryptographic module configured to perform operations of the example systems, devices, or methods; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising a processing system configured with processing deviceexecutable instructions to perform operations of the example systems, devices, or methods; a computing device including means for performing functions of the example systems, devices, or methods; and the example systems, devices, or methods

60 discussed in the following paragraphs implemented as a non-transitory processor- readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform the operations of the example systems, devices, or methods..

[0196] Example 5. The method of example 4, further including: maintaining 32 address ranges in registers that are associated with submission queues and programmed by device drivers during initialization; determining, based on access from the NVMe device in one of 32 address ranges, whether the NVMe device

61 requested to read commands from the submission queue (SQ); determining, based on extracted PRPs, whether to encrypt access data.

[0201] Example 10. The method of any of examples 4-9, further including: configuring a submission queue (SQ) with base addresses and Qsize values; configuring a completion queue (CQ) with base addresses and Qsize values; and using fields in an NVMe command structure to store a PRPL Index of a command entry so as to create a shadow of all PRPs cached inside the NVMe Device.

62 [0202] Example 11. The method of any of examples 4-10, in which in response to determining that user data fits into one system memory page: writing security context information at physical region page list table (PRPLT) location N; writing PRPLT Index = N in the command; creating the command and pushing into SQ; and maintaining the mapping of ({SQID, CommandID} -> N).

[0206] Example 15. The method of any of examples 4-14, further including: using PRPLT Index field of command, read PRPLT [N] (SLBA); finding a free location in LUT and entering PRP1 into that LUT location; calculating LB A to which this buffer

63 maps; deleting PRPLT Pointer from Command and make it RSVD; and sending the modified Command to NVMe device.

[0216] Example 25. The method of any of examples 19-24, further including: sending the modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP; and implementing a cryptographic operation for data associated with

65 the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP.

[0225] Example 34. The method of example 33, further including: sending the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implementing a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

67 [0226] Example 35. The method of any of examples 19, 22-26, or 33-34, in which modifying the command entry data to enable reading of the shadow of the PRPL includes removing a reference to an entry for the PRPL in a second data structure.

[0230] Example 39. A method of providing cryptographic functions for data in nonvolatile memory express (NVMe) protocol executed by a processing system, including: acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; writing a cryptographic enable to a command entry of the command for a submission queue; writing the cryptographic key slot reference to the command entry of the command for the submission queue; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

68 [0231] Example 40. The method of example 39, further including: acquiring a page- level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to the command entry of the command for the submission queue, in which submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue includes submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue.

[0234] Example 43. The method of any of examples, 39, 40, or 42, in which: data of the command is larger than two system memory pages; the method further including writing a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue includes submitting the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

69 [0235] Example 44. The method of any of examples, 39, 40, 42, or 43, in which data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL, the method further including writing a PRPL pointer to a PRP of a PRPL.

[0240] Example 47. The method of examples 45-47, further including: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges; and setting each of the second set of one

70 or more registers with a start address and a size of a different one of the exclusive address ranges.

[0243] The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed

71 to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

[0244] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non- transitory computer-readable medium or a non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer- readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.

72 [0245] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

73

Claims

CLAIMS What is claimed is:

4. The method of claim 1, wherein generating the shadow of the at least one PRP of the command entry data in the first data structure comprises generating an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure.

5. The method of claim 4, wherein the command entry data includes a reference to an entry for the at least one PRP in the second data structure, the method further comprising reading the entry for the at least one PRP in the second data structure, the entry for the at least one PRP in the second data structure including the address of the at least one PRP and the security context for the at least one PRP from the command entry data.

9. The method of claim 8, wherein generating the shadow of the PRPL of the command entry data in the first data structure comprises generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the

75 command entry data.

13. The method of claim 8, wherein modifying the command entry data to enable reading of the shadow of the PRPL comprises modifying an address of a PRPL pointer for the PRPL of the command entry data to point to the shadow of the PRPL.

14. The method of claim 8, wherein generating the shadow of the PRPL of the command entry data in the first data structure comprises generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows the each PRP in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP from a second data structure.

18. The method of claim 8, wherein the command entry data includes a reference to

77 an entry in a second data structure, the entry in the second data structure having a security context for the PRPL, the method further comprising writing the PRPL pointer to the second data structure at a location associated with the reference to the entry in the second data structure.

22. The method of claim 21, further comprising: acquiring a page-level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT

78 slot reference; and writing the PRPLT slot reference to the command entry of the command for the submission queue, wherein submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue comprises submitting the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue.

25. The method of claim 21, wherein: data of the command is larger than two system memory pages; the method further comprises writing a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue comprises

79 submitting the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

30. The method of claim 27, further comprising: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues; and setting each of the second set of one or more registers with a start address and a size of a different one of the command submission queues.

31. The method of claim 27, further comprising: configuring a second set of one or more registers of the inline cryptographic module corresponding with a number of exclusive address ranges; and setting each of the second set of one or more registers with a start address and a size of a different one of the exclusive address ranges.

34. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to modify an address of the at least one PRP of the command entry data to point to the shadow of the at least one PRP to modify the command entry data to enable reading of the shadow of the at least one PRP.

35. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to generate an entry for the at least one PRP in the first data structure, the entry for the at least one PRP in the first data structure including an address of the at least one PRP and a security context for the at least one PRP from a second data structure, to generate the shadow of the at least one PRP of the command entry data in the first data structure.

38. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to: send the modified command entry data to the NVMe device; identify a second transaction from the NVMe device for executing an operation for the shadow of the at least one PRP; and implement a cryptographic operation for data associated with the shadow of the at least one PRP based on a security context associated with the shadow of the at least one PRP.

39. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to: generate a shadow of a PRP list (PRPL) of the command entry data in the first data structure; and modify the command entry data to enable reading of the shadow of the PRPL, thereby generating the modified command entry data.

42. The computing device of claim 41, wherein the NVMe inline cryptographic module is further configured to generate an entry for the each PRP of the PRPL in the first data structure, the entries for the each PRP of the PRPL in the first data structure including an address of the each PRP of the PRPL from the PRPL and a security context for the each PRP of the PRPL from an entry of the PRPL in the first data structure, to generate the shadow of the each PRP of the PRPL in the first data structure.

83

43. The computing device of claim 41, wherein the NVMe inline cryptographic module is further configured to: send the modified PRPL to the NVMe device; identify a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implement a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

46. The computing device of claim 45, wherein the NVMe inline cryptographic module is further configured to: send the modified command entry data to the NVMe device; identify a second transaction from the NVMe device for reading the PRPL, and in response to identifying the second transaction from the NVMe device, generate the shadow of the PRPL of the command entry data in the first data structure occurs; and modify the each PRP of the PRPL to point to the shadow of the each PRP, thereby generating a modified PRPL.

84

47. The computing device of claim 46, wherein the NVMe inline cryptographic module is further configured to: send the modified PRPL to the NVMe device; identify a third transaction from the NVMe device for executing an operation for at least one of the shadows of the each PRP; and implement a cryptographic operation for data associated with the at least one of the shadows of the each PRP based on the security context associated with the at least one of the shadows of the each PRP.

51. The computing device of claim 32, wherein the NVMe inline cryptographic

85 module is further configured to identifying an address of the transaction that is within at least one range of addresses for a least one submission queue, the at least one range of addresses stored to a configuration register of the inline encryption module, to identify the first transaction from the NVMe device for reading the command entry of the command submission queue.

53. The computing device of claim 52, wherein the processing system is further configured to: acquire a page-level read/write pointer lookup table (PRPLT) slot for the command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; write the PRPLT slot reference to the command entry of the command for the submission queue; and submit the command entry of the command including the cryptographic enable, the cryptographic key slot reference, and the PRPLT slot reference to the submission queue to submit the command entry of the command having the cryptographic enable

86 and the cryptographic key slot reference to the submission queue.

56. The computing device of claim 52, wherein: data of the command is larger than two system memory pages; and the processing system is further configured to: write a PRPL pointer to the command entry of the command for the submission queue at a location for a PRP; and submit the command entry of the command having the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer to submit the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

57. The computing device of claim 52, wherein: data of the command is larger than a number system memory pages that may be referenced by a PRP and a PRPL; and the processing system is further configured to write a PRPL pointer to a PRP of a PRPL.

61. The computing device of claim 58, wherein the processing system is further configured to: configure a second set of one or more registers of the inline cryptographic module corresponding with a number of command completion queues; and

88 set each of the second set of one or more registers with a start address and a size of a different one of the command submission queues.

89