Automatic masking for non-volatile memory fast (NVMe) inline encryption

Abstract

Various embodiments include a method that may be implemented in an inline cryptographic module of a non-volatile memory express (NVMe) device. An inline cryptographic module of a processing system for an NVMe device may automatically mask all active PRP within the NVMe device. In addition, the computing device may be configured to selectively encrypt data for storage using the inline encryption circuit by: distinguishing data communicated over the PCIe link from driver, readout, page, and buffer address data communicated over the PCIe link; and encrypting only the data.

Description

[0001] Related applications

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

[0003] Non-Volatile Memory Fast (NVMe) is a protocol specifically designed for solid-state drives (SSDs) to communicate with a computer's central processing unit (CPU) via a high-speed peripheral component interconnect (PCIe) bus interface. NVMe differs from traditional storage interfaces such as Serial Advanced Technology Attachment (SATA) or Serial Attached Small Computer System Interface (SAS) because it was developed to better utilize the low latency and high throughput of modern SSDs, which can read and write data much faster than traditional hard disk drives (HDDs). NVMe also supports features such as multiple input / output (I / O) queues and parallelism, enabling it to deliver significantly faster random read and write performance than traditional storage interfaces. Therefore, NVMe drives are becoming increasingly popular in high-performance computing, data centers, and consumer devices requiring fast storage access, such as gaming PCs and laptops. Summary of the Invention

[0004] Various aspects include methods for providing data encryption in non-volatile memory fast (NVMe) memory devices, which may include selectively encrypting data for storage using inline encryption circuitry in such a way as to distinguish data transmitted via PCIe links from drive, read, page, and buffer address data transmitted via PCIe links, and encrypt only that data. Some aspects may also include identifying possible address ranges based on operations performed in the NVMe memory device, and storing the possible address ranges in memory, wherein distinguishing data transmitted via PCIe links from drive, read, page, and buffer address data transmitted via PCIe links may include identifying any data with addresses not within the possible address ranges stored in memory as data for encryption. In some aspects, identifying possible address ranges based on operations performed in the NVMe memory device may include maintaining only a shadow of those pages that the NVMe memory device has already read from system memory.

[0005] Various aspects include a method for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol by an inline cryptographic module of a processing system, the method comprising: identifying a first transaction from an NVMe device for reading command entries from a command submission queue; reading command entry data of the command entries; generating a shadow of at least one page-level read / write pointer (PRP) of the command entry data using a first data structure; and modifying the command entry data to enable reading of the shadow of at least one PRP, thereby generating modified command entry data.

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

[0007] In some respects, modifying command entry data to enable reading the shadow of at least one PRP may include modifying the address of at least one PRP in the command entry data to point to the shadow of at least one PRP.

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

[0009] In some aspects, the command entry data includes references to entries for at least one PRP using the second data structure. Some aspects may also include reading entries for at least one PRP using the second data structure, the entries including the address of at least one PRP and the security context for the at least one PRP from the command entry data.

[0010] In some respects, modifying command entry data to enable the reading of at least one PRP's shadow may include removing references to entries used for at least one PRP employing a second data structure.

[0011] Some aspects may also include: transmitting modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for performing operations on the shadow of at least one PRP; and performing encryption operations on data associated with the shadow of at least one PRP based on the security context associated with the shadow of at least one PRP.

[0012] Some aspects may also include: generating a shadow of a PRP list (PRPL) using a first data structure to generate command entry data; and modifying the command entry data to enable reading the shadow of the PRPL, thereby generating modified command entry data.

[0013] In some aspects, the shadow of a PRPL that generates command entry data using a first data structure may include generating an entry for a PRPL that uses the first data structure, the entry for which includes the address of the PRPL and a security context from the command entry data for the PRPL.

[0014] Some aspects may also include: transmitting 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 using the first data structure; and modifying each PRP of the PRPL to point to the shadow of each PRP, thereby generating the modified PRPL.

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

[0016] Some aspects may also include: transmitting the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for performing operations on at least one shadow of each PRP; and performing cryptographic operations on data associated with at least one shadow of each PRP based on the security context associated with at least one shadow of each PRP.

[0017] In some respects, modifying command entry data to enable reading the shadow of the PRPL may include modifying the address of the PRPL pointer used for command entry data to point to the shadow of the PRPL.

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

[0019] Some aspects may also include: transmitting modified command entry data to an NVMe device; identifying a second transaction from the NVMe device for reading the PRPL, wherein a shadow of the PRPL using a first data structure that generates the command entry data responds to the identification of the second transaction from the NVMe device; and modifying each PRP of the PRPL to point to the shadow of each PRP, thereby generating the modified PRPL.

[0020] Some aspects may also include: transmitting the modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for performing operations on at least one shadow of each PRP; and performing cryptographic operations on data associated with at least one shadow of each PRP based on the security context associated with at least one shadow of each PRP.

[0021] In some respects, modifying command entry data to enable reading the shadow of a PRPL may include removing references to entries used for PRPLs employing a second data structure.

[0022] In some aspects, the command entry data includes references to entries employing a second data structure, which has a security context for the PRPL. Some aspects may also include writing a PRPL pointer into the second data structure at a location associated with the reference to the entry employing the second data structure.

[0023] In some aspects, the modified command entry data includes virtual addresses. Some aspects may also include obtaining a virtual address-to-physical address mapping for the virtual address in parallel with the shadow of at least one PRP employing a first data structure that generated the command entry data.

[0024] In some respects, the first transaction identifying a command entry from an NVMe device for reading a command submission queue may include an address identifying the transaction within at least one address range for at least one submission queue, the at least one address range being stored in the configuration register of the inline cryptographic module.

[0025] Various aspects include a method for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol, executed by a processing system, which may include: obtaining a cryptographic key slot for a command from a security process, the cryptographic key slot including a cryptographic key slot reference; writing cryptographic enable to a command entry for a submission queue of the command; writing the cryptographic key slot reference to a command entry for a submission queue of the command; and submitting the command entry of the command having cryptographic enable and cryptographic key slot reference to the submission queue.

[0026] Some aspects may also include: obtaining a page-level read / write pointer lookup table (PRPLT) slot for a command from an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to a command entry for a submission queue, wherein submitting a command entry of a command with cipher enable and cipher key slot reference to the submission queue may include submitting a command entry of a command including cipher enable, cipher key slot reference, and PRPLT slot reference to the submission queue.

[0027] In some aspects, a command has more than one page-level read / write pointer (PRP). Some aspects may also include writing a logical block address offset to a portion of at least one PRP of the command entry for the commit queue, and committing a command entry with cipher enable and cipher key slot reference to the commit queue may include committing a command entry of the command that includes cipher enable, cipher key slot reference, and at least one PRP with a logical block offset.

[0028] In some respects, the data in the command is larger than two system storage pages. Some respects may also include writing the logical block address offset into at least one part of a PRP (Public Relations Program) list (PRPL).

[0029] In some respects, the data of the command is larger than two system storage pages. Some respects may also include writing the PRPL pointer to the command entry for the commit queue at the location used for the PRP, and submitting the command entry with password enable and password key slot reference to the commit queue may include submitting the command entry with password enable, password key slot reference, and PRPL pointer.

[0030] In some respects, the data in the command exceeds the number of system storage pages that can be referenced by the PRP and PRPL. Some respects may also include writing the PRPL pointer to the PRP of the PRPL.

[0031] Some aspects may also include configuring one or more registers in a first group corresponding to the number of command submission queues for the inline cryptographic module, and setting each register in the first group of one or more registers using address ranges of different command submission queues in the command submission queues.

[0032] In some respects, setting each register in one or more registers in the first group using the address range of different command submission queues in the command submission queue may include setting each register in one or more registers in the first group using the starting address and size of different command submission queues in the command submission queue.

[0033] In some respects, setting each register in one or more registers in the first group using the address range of different command submission queues in the command submission queue may include setting each register in one or more registers in the first group using the start address and end address of different command submission queues in the command submission queue.

[0034] Some aspects may also include configuring a second set of one or more registers corresponding to the number of command completion queues for the inline cryptographic module, and setting each register in the second set of one or more registers with the starting address and size of different command submission queues in the command submission queue.

[0035] Some aspects may also include configuring one or more registers in a second group corresponding to the number of exclusive address ranges for the inline cryptographic module, and setting each register in the one or more registers in the second group with the start address and size of different exclusive address ranges in the exclusive address range.

[0036] Other aspects include computing devices having a non-volatile memory high-speed (NVMe) inline cryptographic module configured to perform operations of any of the methods outlined above. Further aspects include computing devices having a processing system configured to perform operations of any of the methods outlined above. Attached Figure Description

[0037] The accompanying drawings, incorporated herein and forming part of this specification, illustrate exemplary embodiments of various implementations and, together with the general description given above and the detailed description given below, serve to interpret the features of the claims.

[0038] Figure 1 This is a component block diagram illustrating an example computing device suitable for implementing various implementation schemes.

[0039] Figure 2 This is a component block diagram illustrating an example inline cryptographic non-volatile memory fast (NVMe) system suitable for implementing various implementation schemes.

[0040] Figure 3 This is a component block diagram illustrating example inline cryptographic modules suitable for implementing various implementation schemes.

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

[0042] Figure 5 This is a component block diagram illustrating an example NVMe system with encryption support according to some implementation schemes.

[0043] Figure 6 This is a component block diagram illustrating an example NVMe data structure suitable for use in some implementation schemes.

[0044] Figure 7 This is a component block diagram illustrating access blocks that need to be encrypted and access blocks that should not be encrypted.

[0045] Figures 8 to 17 It is a component block diagram illustrating various information structures and operations configured to implement various implementation schemes in a computing system.

[0046] Figure 18 This is a component block diagram illustrating example inline cryptographic modules suitable for implementing various implementation schemes.

[0047] Figure 19 It is an information structure diagram illustrating a common command format for example submissions in a computing system configured to implement various implementation schemes.

[0048] Figure 20 This is an information structure diagram illustrating example lookup tables in a computing system configured to implement various implementation schemes.

[0049] Figure 21This is a component block diagram and process flowchart illustrating a method for implementing the initialization phase of an NVMe inline encryption process using the masking of physical region pages or page-level read / write pointers (PRPs) in a computing system configured to implement various implementation schemes.

[0050] Figure 22 This is a component block diagram and process flowchart illustrating a method for using PRP to implement the command creation phase of an NVMe inline encryption process in a computing system configured to implement various implementation schemes.

[0051] Figure 23A and Figure 23B These are component block diagrams and process flowcharts illustrating a method for implementing an NVMe inline encryption process using PRP in a computing system configured to implement various implementation schemes.

[0052] Figure 24 It is an information structure diagram illustrating a common command format for example submissions in a computing system configured to implement various implementation schemes.

[0053] Figure 25 This is an information structure diagram illustrating example lookup tables in a computing system configured to implement various implementation schemes.

[0054] Figure 26 These are component block diagrams and process flowcharts illustrating a method for implementing an NVMe inline encryption process using PRP in a computing system configured to implement various implementation schemes.

[0055] Figure 27 This is an information structure diagram illustrating an example of a modified PRP list configured to implement various implementation schemes in a computing system.

[0056] Figure 28 This is an information structure diagram illustrating example lookup tables in a computing system configured to implement various implementation schemes.

[0057] Figure 29 This is a component block diagram and process flowchart illustrating a method for using PRP to implement a write command procedure for an NVMe inline encryption process in a computing system configured to implement various implementation schemes.

[0058] Figure 30 This is a component block diagram and process flowchart illustrating a method for using PRP to implement a read command process for an NVMe inline encryption process in a computing system configured to implement various implementation schemes.

[0059] Figure 31These are component block diagrams and process flowcharts illustrating methods for command completion of NVMe inline encryption procedures using PRP in computing systems configured to implement various implementation schemes.

[0060] Figure 32A and Figure 32B These are component block diagrams and process flowcharts illustrating a command procedure for using a PRP in a computing system configured to implement various implementation schemes, the command procedure using the Peripheral Component Interconnect High Speed ​​(PCIe) address translation service for NVMe inline cryptographic procedures.

[0061] Figure 33 This is a component block diagram illustrating an example mobile computing device suitable for implementing various implementation schemes.

[0062] Figure 34 This is a component block diagram illustrating an example mobile computing device suitable for implementing various implementation schemes.

[0063] Figure 35 This is a component block diagram illustrating an example server suitable for implementing various implementation schemes. Detailed Implementation

[0064] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and embodiments are for illustrative purposes and are not intended to limit the scope of the claims.

[0065] Various implementations include methods for implementing inline cryptographic modules in processing systems for non-volatile memory fast (NVMe) devices and computing devices implementing such methods. In some implementations, the inline cryptographic module can be configured to automatically “mask” all active physical region pages or page-level read / write pointers (PRPs) and / or scatter-gathering lists (SGLs) within the NVMe device. The NVMe device may also maintain 32 address ranges in registers associated with a commit queue and programmed by the device driver during initialization. Access to one of these ranges from the device can indicate that it is attempting to read a command from the commit queue (SQ). The returned data can be used to extract PRPs and / or SGLs that can be used to determine which data should be encrypted and which should remain unencrypted and unchanged.

[0066] The terms “computing device” and “mobile device” are used interchangeably herein to refer to any or all of the following: cellular phone, smartphone, personal or mobile multimedia player, personal data assistant (PDA), laptop computer, tablet computer, convertible laptop / tablet computer (2-in-1 computer), smartbook, ultrabook, netbook, handheld computer, wireless email receiver, internet-enabled multimedia cellular phone, mobile game console, wireless game controller, and similar personal electronic devices including memory and a programmable processor. The term “computing device” may also refer to resident computing devices, including personal computers, desktop computers, standalone computers, workstations, supercomputers, mainframe computers, embedded computers, servers, home theater computers, and game consoles.

[0067] For ease of explanation and clarity, embodiments and examples are described according to the PRP. However, those skilled in the art will recognize that the embodiments and examples described according to the PRP can be similarly implemented using SGL instead of the PRP, and any reference to the PRP is not intended to limit the scope of the claims and specification to exclude SGL from such embodiments and examples.

[0068] PRP (Page Reference Provider) is a data structure or mechanism used in memory management to track the current location within a memory page. A PRP can indicate the 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 a memory page without having to process the entire page at once. PRPs can be organized in a PRP list (PRPL), which can be a data structure that maintains a collection or list of PRPs. Each entry in a PRPL can correspond to a specific memory page and can contain the PRPs associated with that page. PRPLs can be used to manage multiple PRPs typically used for individual memory pages within the system.

[0069] The NVMe protocol for storage devices enables fast and high-throughput communication between NVMe storage devices and processing systems. Peripheral Component Interface Fast (PCIe) controllers can be configured to enable NVMe protocol communication between NVMe devices and components of the processing system.

[0070] There is currently a strong market demand for NVMe inline encryption, which provides hardware-based encryption for data stored on NVMe-based solid-state drives (SSDs). Inline encryption means that the encryption process occurs automatically when 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. Furthermore, NVMe inline encryption can use the Advanced Encryption Standard (AES) with 512-bit or 256-bit keys to encrypt data. The encryption keys can be securely stored in the SSD controller and are not exposed to the host system. This provides an additional layer of protection against data leakage. Additionally, NVMe inline encryption provides end-to-end encryption of data, ensuring that data is encrypted from the moment it leaves the host system until it is decrypted by the SSD controller. This helps protect data from unauthorized access or theft during transmission and while it is stored on the SSD.

[0071] Implementing inline encryption in NVMe presents numerous challenges. For example, there is currently no standard method for encrypting data accessed online and stored on NVMe devices, where encryption occurs simultaneously with data storage and access. Currently, lobbying for changes to the NVMe specification, imposing unrealistic restrictions on device drivers, or bearing the high silicon costs of maintaining a large number of descriptors to use inline encryption with NVMe devices are either necessary. Changing the NVMe specification would require significant effort and may not be feasible in the short term. Imposing restrictions on device drivers could limit device functionality and potentially lead to compatibility issues.

[0072] Another option is to simply bear the high silicon cost of maintaining a large number of descriptors for inline encryption with NVMe devices. A descriptor is a data structure that describes the attributes of data stored on a device. Maintaining a large number of descriptors can be resource-intensive. As an example of high silicon cost, NVMe transmits Advanced Extensible Interface (AXI) access commands for command fetching, descriptor fetching, and user data buffering. The computing system may need to identify these commands for encryption. However, with 4 million PRPs in Double Data Rate (DDR) memory, searching for an incoming AXI address from many options can be difficult. A typical solution would require 4MB of SRAM to store the PRPs, along with complex search logic, thus resulting in high silicon cost.

[0073] The implementation can eliminate the need for expensive silicon costs associated with access descriptors. As mentioned above, some implementations can automatically “mask” all active PRPs within the NVMe device, maintaining 32 address ranges in registers associated with the commit queue and programmed by the device driver during initialization. Access made from the NVMe device within one of these 32 address ranges can indicate that it is attempting to read a command from the commit queue (SQ). The returned data can be used to extract the PRP used to determine the data that should be encrypted.

[0074] By maintaining only a 32-register address range for the commit queue, all PRPs can be masked within the NVMe device, simplifying the search logic used to identify incoming user data buffer accesses. Another benefit or advantage of the implementation is that the complex search logic for finding the PRP from 4 million possibilities is reduced to just 32 ranges that can be efficiently implemented in the hardware. Yet another advantage of the implementations is that they can significantly reduce the SRAM capacity to 8KB (while conventional solutions might require 4MB of SRAM pre-installed with complex search logic). For these and other reasons, various implementations can significantly reduce costs. When using NVMe devices, the implementations can allow access to inline encryption without sacrificing system cost or performance.

[0075] Figure 1 An example is illustrated comprising a computing device 10 suitable for use with various implementations. The computing device 10 may include a processing system 12 having 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 interconnects 32. The computing device 10 may also include communication components 22 (such as a wired or wireless modem), storage memory 24, an antenna 26 for establishing wireless communication links, a power manager 28, and memory 36. The processor 14 may include any of a variety of processing devices, such as multiple processor cores.

[0076] The term "System-on-a-Chip" (SoC) is used herein to refer to a collection of interconnected electronic circuits, generally but not exclusively including processing devices, memory, and communication interfaces. Processing system 12 may include various types of processors 14, some of which may include multiple processor cores. Non-limiting examples of processors that may be included in computing device 10 and implemented in or coupled to processing system 12 include general-purpose processors, central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), accelerated processing units (APUs), security processing units (SPUs), neural network processing units (NPUs), subsystem processors for specific components of computing devices (such as image processors for camera subsystems or display processors for displays), auxiliary processors, single-core processors, multi-core processors, controllers, and microcontrollers. Processing system 12 may also embody other hardware and hardware combinations such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), other programmable logic devices, discrete gate logic components, transistor logic components, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that components of the integrated circuit reside on a single piece of semiconductor material; this may be referred to as a System-on-a-Chip (SoC).

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

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

[0079] Computing device 10 may include any number and combination of memories, such as memory 16 integrated with processing system 12 and memory 36 separate from processing system 12. Any of the memories 16, 36 may be volatile or non-volatile memory configured to store data and processor-executable code accessible to processor 14. Computing device 10 and / or processing system 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memory, such as random access memory (RAM) or main memory, including static RAM (SRAM) (such as memory 16), dynamic RAM (DRAM) (such as memory 36), or cache memory.

[0080] Memory 16, 36 can be configured to temporarily store a limited amount of data. For example, data can be received from a data sensor or subsystem. As another example, the data can be data and / or processor-executable code instructions requested from non-volatile memory 16, 24, 36, which are loaded from non-volatile memory 16, 24, 36 into memory 16, 36 upon anticipated future access based on various factors. As another example, the data can be intermediate-processed data and / or processor-executable code instructions generated by processor 14 and temporarily stored for rapid future access without being stored in non-volatile memory 16, 24, 36.

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

[0082] Storage interface 20 and storage memory 24 can operate in concert to allow computing device 10 to store data and processor-executable code on a non-volatile storage medium, such as a non-volatile memory fast (NVMe) memory device. Storage memory 24 can be configured very similarly to an embodiment of memory 16, wherein storage memory 24 can store data or processor-executable code for access by one or more processors in processor 14. Non-volatile storage memory 24 can retain information after computing device 10 has been powered off. When power is restored and computing device 10 restarts, the information stored on storage memory 24 becomes available to computing device 10. Storage interface 20 can control access to storage memory 24 and allow processor 14 to read data from and write data to storage memory 24.

[0083] The inline cryptographic module 38 can be configured to implement cryptographic functions, such as encryption and decryption, for data transactions used with the memory storage device 24. Data transmitted between memory 36 and memory storage device 24 can be encrypted and decrypted by the inline cryptographic module 38 to protect the stored data and memory storage device 24 by encrypting the data, and the encrypted data retrieved from memory storage device 24 can be made available by the SoC by decrypting the data. The inline cryptographic module 38 can be configured to implement hash generation and verification of device hints associated with data transmitted between memory 36 and memory storage device 24 to assess the integrity of the device hints for use when evaluating whether to use the data.

[0084] Power manager 28 can be configured to control the power state of one or more power rails (not shown) for power delivery to components of processing system 12. In some embodiments, power manager 28 can be configured to control the amount of power supplied to components of processing system 12. For example, power manager 28 can be configured to control the connection between components of processing system 12 and power rails. As another example, power manager 28 can be configured to control the amount of power on power rails connected to components of processing system 12. Power manager 28 can be configured as a power management integrated circuit (power management IC or PMIC).

[0085] The clock controller 30 can be configured to control the clock signals sent to the components of the processing system 12. For example, the clock controller 30 can gate the components of the processing system 12 by disconnecting them from the clock signals, and can degated them by connecting them to the clock signals.

[0086] Interconnector 32 may be a communication structure, such as a communication bus, configured to communicatively connect components of processing system 12. Interconnector 32 may transmit signals between components of processing system 12. In some embodiments, interconnector 32 may be configured to control signals between components of processing system 12 by controlling the timing and / or transmission path of control signals.

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

[0088] Figure 2 An example of an inline cryptographic NVMe system 200 suitable for implementing various implementation schemes is shown. References Figure 1 and Figure 2 The inline cryptographic NVMe system 200 can be used on computing devices (e.g., Figure 1 Implemented in a computing device 10), the computing device including a memory 36 interconnected with each other via various communication buses, a processing system 202 (e.g., Figure 1 The processing system 12) and NVMe device 214 (or NVMe storage device) (e.g., Figure 1 (Storage memory 24 in the middle).

[0089] The processing system 202, which can be implemented as a SoC, may include one or more processors 14 interconnected with each other via various communication buses, and a peripheral component interface fast (PCIe) controller 212 (e.g., Figure 1 The system 202 includes a storage memory interface 204 and an inline cryptographic module 38. One or more processors 14 can be configured to implement software such as an application 204 (including an advanced operating system), a kernel 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 can manage communication between the components of the processing system 202 (including the inline cryptographic module 38) and the NVMe device 214. Such communication may include communication for preparing and implementing NVMe commands from one or more processors 14 for data transactions, such as read and / or write transactions, at the NVMe device 214.

[0090] The inline cryptographic module 38 may be a hardware module integrated into the processing system 202. The inline cryptographic module 38 can implement cryptographic functions for data used in NVMe commands, such as encryption, decryption, and / or bypassing. For example, the inline cryptographic module 38 can encrypt data transmitted to the NVMe device 214 and decrypt data received from the NVMe device 214. The cryptographic functions implemented by the inline cryptographic module 38 can be any known, proprietary, and / or to-be-developed encryption and decryption methods and / or circuits. For example, the inline cryptographic module 38 can provide application-specific, folder-based, and / or file-based cryptographic functions. As another example, the inline cryptographic module 38 can use AES with a 512-bit or 256-bit key to implement cryptographic functions.

[0091] Software running on processing system 202, NVMe drive 208, and / or application 204 can issue requests to use a specific algorithm and a set of encryption keys, a specific security context, and / or request the transmission of data without encryption. Setting the security context, encryption keys, and / or encryption algorithm can be implemented by any software running on processing system 202, NVMe drive 208, and / or application 204, while encrypting or decrypting data using the security context, encryption keys, and / or encryption algorithm can be performed by another software entity.

[0092] The inline cryptographic module 38 can also support secure key management. In some examples, the inline cryptographic module 38 can operate independently of the PCIe architecture and its different layers, achieving scalable storage throughput and conforming to the NVMe device protocol. In other examples, the inline cryptographic module 38 can be part of the PCIe controller 212. The inline cryptographic module 38 is further described herein.

[0093] Figure 3 Examples of inline cryptographic modules 38 for implementing various implementation schemes are shown. (Reference) Figures 1 to 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. For ease of explanation and clarity in accordance with non-limiting embodiments, the encryption module 304 and the decryption module 306 are described herein as separate components. However, such separate description is not intended to limit the scope of the claims and specification, and in some specific embodiments and implementations, the encryption module 304 and the decryption module 306 may be implemented as a single combined module.

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

[0095] The buffer address can be used for NVMe commands to write data from the buffer address of memory 36 to NVMe device 214 and / or read data from NVMe device 214 into the buffer address of memory 36.

[0096] An NVMe security ID can be a combination of data, such as an NVMe command submission queue identifier and an NVMe command identifier used for NVMe commands. The NVMe command submission queue identifier identifies the NVMe drive 208 that can write NVMe commands to the NVMe command submission queue.

[0097] The NVMe command submission queue can trigger a doorbell signal, which is configured to indicate to NVMe device 214 that an NVMe command in the queue is ready for execution when it reaches the end of the queue. An NVMe command ID identifies the NVMe command.

[0098] The buffer address lookup structure 300 can also store sector offset data used for NVMe commands in association with buffer addresses and NVMe security IDs. Sector offsets can be used in the generation of initialization vectors for encryption functions. Initialization vectors can be used as input to encryption algorithms and are configured to influence data encryption in a way that multiple encryptions might produce different encrypted values. The buffer address lookup structure 300 can store any amount of associated data, such as multiple sets of associated data for more than one NVMe command.

[0099] Security context structure 302 can be a data structure configured to store various data in association with each other, such as a table, array, linked table, graph, etc. For example, security context structure 302 can store NVMe security ID data and security context used for NVMe commands in association with each other. The NVMe security ID in buffer address lookup structure 300 and security context structure 302 used for the same NVMe command can be the same. The security context can include a combination of security-related information, such as encryption algorithms, 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 can be provided by an application executed by processor 14, from which the NVMe command originates. Security context structure 302 can store any amount of associated data, such as more than one set of associated data for more than one NVMe command.

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

[0101] In some implementations, the inline cryptographic module 38 may configure the buffer address lookup structure 300 and the security context structure 302 in response to receiving an NVMe command from the NVMe drive. The inline cryptographic module 38 may process the NVMe command, extract 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. By configuring the buffer address lookup structure 300 and the security context structure 302 inline rather than on the NVMe drive, the address redundancy problem described previously is eliminated and data integrity is maintained. Furthermore, the software overhead for configuring the buffer address lookup structure 300 in the inline cryptographic module 38 is reduced.

[0102] Inline password module 38 can be configured to forward a doorbell signal, which is configured to send a signal to an NVMe device (e.g., Figure 1 The storage memory 24 in Figure 2 The NVMe device 214 in the middle indicates the pending NVMe command. For example, the inline cryptographic module 38 can update the tail point of the NVMe command submission queue to the "doorbell" register of the NVMe device. Forwarding the doorbell signal can bypass or abandon software configured to write to two doorbells and can ensure that the operation of the cryptographic module 38 and the NVMe device is synchronized.

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

[0104] Using retrieved information, such as sector offset and / or security context, encryption module 304 and / or decryption module 306 can implement cryptographic functions for data used in NVMe transactions. For example, the retrieved information may include a security context from 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. Encryption module 304 can use the retrieved security context information to encrypt data to be transmitted to the NVMe device for NVMe transactions. Decryption module 306 can use the retrieved security context information to decrypt data received from the NVMe device for NVMe transactions.

[0105] In some implementations, the retrieved information may include sector offsets from the buffer address lookup structure 300. Encryption module 304 can use the retrieved sector offsets to generate an initialization vector and use the initialization vector along with information from the retrieved security context to encrypt data to be transmitted to the NVMe device for NVMe transactions. Decryption module 306 can use the retrieved sector offsets to generate the initialization vector and use the initialization vector along with information from the retrieved security context to decrypt data received from the NVMe device for NVMe transactions. Encryption module 304 can input unencrypted data for NVMe commands, one or more encryption keys, and / or the initialization vector into an encryption algorithm to generate encrypted data for NVMe commands. Decryption module 306 can input encrypted data for NVMe commands, one or more encryption keys, and / or the initialization vector into an encryption algorithm to generate decrypted data for NVMe commands.

[0106] Figure 4 and Figure 5 An example of an implementation suitable for NVMe transactions is provided. Figure 4 NVMe inline encryption and not implemented Figure 5 A system with inline NVMe encryption can include a new encryption layer placed inline into the NVMe transaction flow. NVMe inline encryption provides data confidentiality while maintaining end-to-end performance and low latency. The encryption layer can be deployed on the device side and configured to leverage its proximity to the device controller to manage NVMe command processing and completion.

[0107] refer to Figures 1 to 4 , Figure 4 An example is given in which the command submission includes the following: (1) Host 400 (e.g., Figure 1 The processing system 12 in the middle Figure 1 and Figure 2 Processor 14 in Figure 2The NVMe device driver (e.g., in the processing system 202) at the processing system 202) Figure 2 The NVMe drive 208 in the memory writes commands to the host memory 402 (e.g., Figure 1 (1) Submission queue (SQ) 404 at memory locations 16 and 36; and (2) NVMe device driver at host 400 (e.g., Figure 2 The NVMe drive 208 in the middle will update the SQ tail pointer (ptr) ( Figure 4 The "tail" of the text is written to the doorbell 408 at position 214 of the NVMe device. Figure 4 The “SQ tail doorbell” (e.g., the “doorbell” register). Command processing may include: (3) the NVMe device retrieves a command from the SQ 404, and the NVMe device updates the SQ header ptr with the next command. Figure 4 (4) The NVMe device processes the acquired command. Command completion may include: (5) NVMe device 214 update complete (or command or command completion) queue (CQ) tail ptr ( Figure 4 (6) The NVMe device 214 generates a CQ platform-specific interrupt, such as an MSI-X interrupt, to notify the host driver of the completion status; (7) The NVMe device driver at host 400 processes the completion of the command; and (8) The NVMe device driver at host 400 writes the updated CQ tail ptr to the doorbell; Figure 4 The "header" of the file is written to the doorbell 410 at NVMe device controller 214. Figure 4 The “CQ Header Doorbell” (e.g., the “Doorbell” register).

[0108] refer to Figures 1 to 5 ,exist Figure 5 In the illustrated example, host memory 402 (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 The memory 36) includes an NVMe-ICE module 500 (e.g., Figures 1 to 3 The inline cryptographic module 38 in the NVMe-ICE module can be an encryption / decryption layer between the host driver and the NVMe device controller 214. Command submission operations can include: (1) host 400 (e.g., Figure 1 The processing system 12 in the middle Figure 1 and Figure 2 Processor 14 in Figure 2 The NVMe device driver (e.g., in the processing system 202) at the processing system 202) Figure 2(1) The NVMe driver 208 in the host 402 writes the command to the commit queue (SQ) 404 at the host memory 402; (2) The NVMe device driver at the host 400 configures the NVMe-ICE module 500 for inline encryption of NVMe transactions; and (3) The NVMe device driver at the host 400 updates the SQ tail ptr ( Figure 5 The "tail" of the text is written to the doorbell 408 at NVMe device controller 214. Figure 5 The “SQ tail doorbell” (e.g., the “doorbell” register). Command processing operations may include: (4) the NVMe device controller 214 retrieves a command from the SQ 404 and updates the SQ header ptr with the next command. Figure 5 (5) The NVMe device controller 214 processes the command and / or the updated SQ header ptr; and (6) The NVMe-ICE module 500 encrypts / decrypts the data used for the command. For example, the NVMe-ICE module 500 can encrypt write data for a write command to be transmitted to the NVMe device controller 214 and / or decrypt read data for a read command received from the NVMe device controller 214. Command completion operations may include: (7) The NVMe device controller 214 writes the completion of the command to the completion queue (CQ) 406 at the host memory 402 and sets the CQ tail ptr ( Figure 5 (8) The NVMe device controller 214 generates a CQ platform-specific interrupt, such as an MSI-X interrupt, to notify the host driver of the completion status; (9) The host 400 processes the completion of the command; and (10) The host 400 updates the CQ header ptr ( Figure 5 The "header" of the file is written to the doorbell 410 at NVMe device controller 214. Figure 5 The “CQ Header Doorbell” (e.g., the “Doorbell” register).

[0109] SQ 404 and CQ 406 are used to manage communication between host 400 and NVMe device 214. SQ 404 can be used by host 400 to queue commands to be sent to NVMe device 214. These commands can include any commands from the NVMe standard, such as read commands, write commands, management commands, etc. CQ 406 can be used by NVMe device 214 to notify host 400 of the completion status of commands processed from SQ 404, such as successful completion or failure. When a command is executed, NVMe device controller 214 can place a completion entry in CQ 406 to notify host 400 of the completion of the operation. SQ 404 and CQ 406 can be circular buffers, arrays, etc., for which positions can be statically or dynamically indicated as a start position (head) and an end position (tail). Entries at the head of SQ 404 can be used for the next command to be implemented, and entries at the tail of SQ 404 can be used for the last command to be implemented. The entry at the beginning of CQ 404 can be used for the oldest completed command, and the entry at the end of CQ 404 can be used for the most recently completed command. The size of SQ 404 and CQ 406 can be set to store at least two entries, including thousands of entries, such as 64,000 entries.

[0110] The NVMe-ICE module 500 provides data security and privacy at the storage level by encrypting data transmitted from the host 400 to the NVMe device 214. This is achieved by inserting an encryption layer between the host 400 and the NVMe device 214, allowing each issued command to be processed as an encrypted command before being passed to the NVMe device controller 214 for further processing. When a command is written by the host drive and queued in the commit queue (SQ) 404, it can first be picked up by the NVMe-ICE module 500 for encryption / decryption before being passed to the NVMe device controller 214 for further processing. The NVMe device controller 214 can then process the command and update the SQ header pointer before passing it back to the NVMe-ICE module 500 for decryption or encryption as appropriate. The NVMe device controller 214 can then write the information to the completion queue (CQ) and generate an MSI-X interrupt for the host drive.

[0111] The process described above ensures that all data transmitted between the host CPU and the NVMe device controller 214 is encrypted and secure, while providing a high-performance solution with low latency regardless of workload or data size. This is because the data location aligns with other required steps in the process of sending commands from the host CPU and receiving results from the NVMe device controller 214. Furthermore, in some implementations, hardware-based encryption mechanisms can be used to protect all data, eliminating the need for additional software implementations on the host CPU or NVMe device side. This allows users seeking improved security solutions for their workloads without sacrificing performance or latency to implement solutions without making any significant changes to their existing architecture and systems.

[0112] refer to Figures 1 to 6 , Figure 6 An example is a processing system 600 that can be implemented as a SoC (e.g., Figure 1 The processing system 12 in the middle Figure 2 The processing system 202 in Figure 5 The host 400 in the system, the processing system includes system memory space 602 (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The system memory space includes host memory 402, network on-chip (NOC) 604, PCIe root complex 606, and PCIe link 608 to NVMe device 214. The NVMe device includes a completion queue (CQ) head pointer (ptr) 610, a CQ tail pointer (ptr) 612, a commit queue (SQ) tail pointer (ptr) 614, and an SQ head pointer (ptr) 616. The system memory space may include a completion queue (CQ) 618, a commit queue (SQ) 620, and a page-level read / write pointer list (PRPL) 622.

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

[0114] Figure 7 This section illustrates some of the technical challenges associated with determining which accesses (e.g., SQ, CQ, PRPL, I / O accesses, etc.) need to be encrypted in order to securely transfer data from NVMe devices. References Figures 1 to 7 NVMe devices (e.g., Figure 1 The storage memory 24 in the middle, Figure 2 , Figure 5 and 6 The NVMe device 214 in the figure uses SQ, CQ, PRPL, and I / O access to perform various data transfer activities. Figure 7 The four main types of access in the NVMe processing system illustrated are write address, read address, write data, and read data. As a non-limiting example, various types of access using the Advanced Extensible Interface (AXI) protocol can include AXI write address (AWADDR), AXI read address (ARADDR), AXI write data (WDATA), and AXI read data (RDATA). Figure 7 It also illustrates that SQ access used for command retrieval should not be encrypted, CQ access used for completion entries should not be encrypted, and PRPL access used for descriptor retrieval should not be encrypted, but I / O access with user data transfer should be encrypted.

[0115] refer to Figures 1 to 8 To determine which accesses (such as SQ, CQ, PRPL, and I / O accesses) should be encrypted, some implementations may use the incoming address of the NVMe device to correlate with the internal SRAM (e.g., ...). Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The host memory 402 in Figure 6 The address database in the system memory space 602 (e.g., Figure 8 The content is matched using a search engine (e.g., 806). The address database may include information on each SQ (e.g., Figure 6 Submission queue 620 (SQ table), CQ (e.g., Figure 6 The completion queue 620 (CQ table), PRP list (e.g., Figure 6 PRPL622 in Figure 8 PRPL Table 800) and PRP (e.g., Figure 6 PRP 626 in Figure 8The entry for the start and end addresses in the PRP table (802) is used. For example, when an incoming address matches an entry in the SQ table, it can be inferred that the NVMe device is attempting a read command. Similarly, when an incoming address matches an entry in the CQ table, it can be inferred that the device is attempting a write completion entry. By matching the incoming address against this database, the system (e.g., Figure 1 The processing system 12 in the middle Figure 2 The processing system 202 in Figure 5 The host 400, Figure 6 The processing system 600 can determine what type of access is being attempted and whether it should be encrypted. For example, the system can determine all I / O accesses involving user data transmissions that should be encrypted for security purposes.

[0116] Therefore, after matching, the system can determine which accesses require encryption. The system can be configured such that any access with a matching address in the SQ, CQ, and PRPL tables is control or status-related data that does not require encryption. On the other hand, the system can determine that any access with a matching address in PRP table 802 may require encryption, as this may involve user data transmission.

[0117] The theoretical maximum size of the database storing each SQ, CQ, PRP list and the start and end addresses of the PRPs is 384KB, 384KB, 3TB, and 1536TB, respectively. These sizes may be too large for consumer laptops or desktop computers. For these computers, the following requirements may be applicable: NVMe devices support 32 SQs and 32 CQs; SQ tables store 32 entries (192B storage); CQ tables store 32 entries (192B storage); 8K commands (2MB per transaction) may be sufficient to keep the PCIe link busy; PRPL table 800 stores 8K entries (8K*1), and therefore stores 48KB of storage; each PRPL can include up to 512 PRP entries, and PRP table 802 can include 4 million entries (8K*512), or 24MB of storage.

[0118] Another technical challenge is how to keep the PRP table 802 in internal SRAM so that it can be accessed quickly and efficiently. To achieve this, the size of the PRP table 802 may have to be significantly reduced. One approach is to predict or identify which user data buffers the NVMe device will access.

[0119] refer to Figure 1As shown in Figure 9, to overcome these and other technical challenges, some implementations can capture device access and interpret it according to the NVMe specification. The system can examine each access request to determine its legitimacy before allowing it to proceed further. To achieve this, the system can extract the PRP from each request on an ad-hoc basis. In some implementations, registers can be configured with the start and end addresses of the commit queue to identify when a read address falls within one of these ranges. This allows the system to determine the PRP cached in the NVMe device. Additionally, Figure 9A Part of the NVMe command 900 (such as part of the address field, including reserved fields) Figure 9A The RSVD in the command (and / or other fields in the NVMe command 900) can be retained. Figure 9B Command entry 902 in (e.g., Figure 6 The command (624) in the document provides an index of the Page-Level Read / Write Pointer List (PRPL). This can provide an accurate representation of all PRPs within the dynamic cache of the NVMe device.

[0120] Some implementations can utilize a reserved field in the NVMe command structure that maintains a PRPL index for command entries, in order to create a cached shadow of all PRPs within the NVMe device. The system can initiate this process by configuring its commit queue (SQ) with its base address and queue size (Qsize) value, and then performing the same operation on the completion queue (CQ). This allows the system to enqueue commands without requiring PRPLs.

[0121] Depending on the amount of user data to be transferred, different processes may be required to achieve a successful transfer. For example, if the user data fits into one or two system storage pages, security context information can be written to one or two PRP lookup table (PRPLT) locations (“N”). The system can then continue creating commands before pushing them into the SQ, while maintaining its mapping {SQ identifier (SQID), command identifier (CID)}->N or {SQID, CID, namespace identifier (NSID)}->N. However, if the user data requires more than two system storage pages, reaching a system storage page threshold, a PRP can be created for the first system storage page, and PRPLs will need to be created for all other system storage pages, such that for all PRP entries in the PRPL, the logical block (LB) offset is placed in the lower 12 bits and bits [1:0] = 2'b00. If the user data requires more than the system storage page threshold, multiple chained PRPLs can be created by inserting a pointer to the next PRPL entry in another PRPL in the last entry of the PRPL. The system storage page threshold can be configured based on the system storage page size. In some implementations, the system storage page threshold can be the system storage page size divided by 8. For example, for a system storage page size of 4KB, the system storage page threshold could be 512 system storage pages. The system storage page threshold can be configured similarly based on any system storage page size (e.g., 8KB, 16KB, etc.).

[0122] That is, when enqueuing a command, if the user data fits into one or two system storage pages, a Page-Level Read / Write Pointer List (PRPL) may not be necessary. However, if more than two pages are needed, up to a threshold of system storage pages, a PRPL can be used. If more than the threshold of system storage pages are needed, multiple PRPLs may be required to link together (PRPL creation process). For more than two pages, the LB offset in the lower 12 bits can be inserted into each PRP entry after the first PRP entry, including each entry in each PRPL. For system storage pages exceeding the threshold, a pointer to the next PRPL can be located in the last PRP entry of each previous PRPL. Security context information can also be written to PRPLT position N when processing a command. In the example using at least one PRPL, if more than one PRPL is needed, such as when more than two pages are needed when pushing in an SQ and maintaining the mapping {SQID, CID}->N or {SQID, CID, NSID}->N, the pointer to the first PRPL can be inserted into the PRP2 field. These implementations can reduce the total SRAM requirement for caching all PRP entries to just 8KB, even with a large number of commands, making it possible to use internal SRAM without sacrificing performance efficiency.

[0123] Figures 10A to 12B Examples of commands and PRPL structures are shown for commands that require different numbers of page buffers. References Figures 1 to 12B Command structures 1000, 1002, 1102, 1202 (for example, Figure 6 Command 624 in the figure, for example, command 902 in Figure 9, can be used by the NVMe inline cryptographic module (e.g., Figures 1 to 3 Inline cryptographic module 38 Figure 5 The NVMe-ICE module 500 in the memory (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The host memory 402 in Figure 6 Commands received from the system memory space 602, such as the commands described above, such as those from SQ (e.g., Figure 5 SQ 404 in Figure 6 The command received in the submission queue 620. Each of the command structures 1000, 1002, 1102, and 1202 may include a PRPLT pointer (or index) pointing to the position (“N”) at the PRPLT. PRPL structures 1100 and 1200 (e.g., Figure 6PRPL 622 in the above-described PRPL can be commanded by the PRPL pointers of 1102 and 1202 (e.g., Figure 6 The PRPL pointer (628) in the file is referenced.

[0124] Figure 10A The illustrated example shows a command structure 1000 that requires a page buffer for data. In addition to the PRPLT pointer, the command structure 1000 may also include a location in memory (e.g., ...). Figure 6 The PRP (“PRP1”) associated with position 630 in the middle (such as the page buffer) (e.g., Figure 6 (PRP 626 in the original text). Since the data requires a page buffer, another PRP (“PRP2”) can have default data (e.g., zero, null, etc.) configured to indicate a location unrelated to the location in memory.

[0125] Figure 10B The illustrated example shows a command structure 1002 with data requiring two page buffers. In addition to the PRPLT pointer, the command structure 1002 may also include a location in memory (e.g., Figure 6 The PRP (“PRP1”) associated with position 630 in the middle (such as the page buffer) (e.g., Figure 6 (PRP 626 in the original text). Additionally, command structure 1002 may include another PRP (“PRP2”) associated with another location in memory (such as another page buffer). In some embodiments, the other PRP may include an LB offset (“Loffset”). The LB offset is optional and can be used and varied in size based on the page size and logical block address (LBA) size to match the page size.

[0126] Figure 11A and Figure 11B The illustrated example shows a PRPL structure 1100 and an associated command structure 1102, which has data requiring more than two page buffers (up to a threshold of the system's stored page buffers). The PRPL structure 1100 may include at least two PRPs ("PRP2", "PRP3", "PRP4") (e.g., Figure 6 PRP 626), up to 510 PRPs, each PRP associated with a location in memory (e.g., Figure 6The command structure 1102 may include a location 630 in memory (such as a page buffer). The PRPL structure 1100 may include LB offsets (“Loffset1”, “Loffset2”, “Loffset3”) for each PRP. In addition to the PRPLT pointer, the command structure 1102 may also include a PRP (“PRP1”) associated with a location in memory (such as a page buffer). Furthermore, the command structure 1102 may include a PRPL (“PRPL pointer”) associated with the PRPL structure 1100.

[0127] Figure 12A and Figure 12B The illustrated example shows a PRPL structure 1200 (which may represent multiple PRPL structures 1200), and an associated command structure 1202 having data that requires more than a threshold of the system storage page buffer. The PRPL structure 1200 may include at least two PRPs (“PRP2”, “PRP3”) (e.g., Figure 6 PRP 626), up to 510 PRPs, each PRP associated with a location in memory (e.g., Figure 6 The location 630 in memory (such as the page buffer) is associated with the PRP. For a PRPL structure 1200 that is insufficient to hold all PRPs, an entry in the PRPL structure 1200 may be a pointer to the next PRPL structure 1200 (“ptr pointing to the next PRPL”). The last PRPL structure 1200 having the last PRP for the command structure 1202 may exclude pointers to the next PRPL structure 1200 (such as PRPL structure 1100). The PRPL structure 1200 may include LB offsets (“Loffset1”, “Loffset2”) for each PRP. In addition to the PRPLT pointer, the command structure 1202 may also include a PRP (“PRP1”) associated with a location in memory (such as the page buffer). Additionally, the command structure 1202 may include a PRPL (“PRPL pointer”) associated with the PRPL structure 1200.

[0128] Figures 13 to 17 Example information structures and operations are illustrated in computing systems configured to implement various implementation schemes. References Figures 1 to 17 Information structures and operations can be implemented in computing systems (e.g., Figure 1 The computing device 10 in Figure 2 Inline cryptographic NVMe system 200) and / or NVMe device (e.g., Figure 1 The storage memory 24 in the middle, Figure 2 , Figure 5 and Figure 6Implemented in the NVMe device 214). For example, information structures and operations can be implemented in any combination of components of a computing system, including: host memory (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The host memory 402 in Figure 6 The system memory space 602 in the system; the host processing system (e.g., Figure 1 The processing system 12 in the middle Figure 2 The processing system 202 in Figure 5 The host 400, Figure 6 The host processing system 600 is configured to operate via one or more processors (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, and PCIe driver 210 are included, and an NVMe inline cryptographic module (e.g., Figures 1 to 3 NVMe inline cryptographic module 38 Figure 5 NVMe-ICE module 500) and PCIe root complex (e.g., Figure 2 PCIe controller 212 in Figure 6 (PCIe root complex 606 in the example). In some examples, the host software can be an operating system (e.g., Android, Windows, iOS, etc.).

[0129] The information structure may include PRPLT SRAM 1300 (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The host memory 402 in Figure 6 The system memory space 602 in Figure 8 PRPL table 800) and lookup table (LUT) SRAM 1302 (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 Memory 36 in Figure 5 The host memory 402 in Figure 6 The system memory space 602 in Figure 8 PRP table 802 in the document). The information structure may also include commands 1000, 1002 (e.g., ...). Figure 6 Command 624), Command 1502 (for example, Figure 6Command 624 in the middle Figure 11B Command 1102 in Figure 12B Command 1202), modified commands 1304, 1400, 1500, PRPL 1100, 1200 (for example, Figure 6 PRPL 622) and the modified PRPL 1600 and 1700.

[0130] Operations can include those illustrated in boxes 1310, 1312, 1314, 1316, 1318, 1410, 1412, 1510, 1610, 1612, 1614, 1710, and 1712. (The last part, "can be omitted," is a repetition of the previous sentence and can be omitted.) Figures 13 to 17 The example shown in the document implements boxes with the same number in a similar manner.

[0131] Another technical challenge is how to obtain from DDR (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 The memory 36 in the NVMe device reads data and parses it into the device's shadow for later access. The implementation can be broken down into several stages, such as reading data from DDR and parsing command structures.

[0132] The first stage may include reading data from DDR memory for the access. That is, the first stage may include identifying the data to be accessed, including the physical address of the data and a command structure defining how the access should be processed. The second stage may include parsing command structures 1000, 1002, and 1502 and extracting PRP details so that they can be placed in the NVMe device's "shadow". The "shadow" can be an area within host memory (such as PRPLT SRAM 1300 and / or LUT SRAM 1302) where data sharing is maintained, allowing data to be easily accessed when needed without having to go through any other processes, such as booting or accessing another type of file storage system. A project "shadow" or "project shadow" refers to the data of a project within a "shadow" specifically for that project. "Shading" a project means placing the project's data into the project's "shadow". Furthermore, if a pointer to the PRPL exists within command 1502 (e.g., ...), Figure 6 If the PRPL pointer (628) is used, then the pointer should be cached in a temporary small storage device, such as PRPLT SRAM 1300 and / or LUT SRAM 1302, before it is sent to the final destination (NVMe device).

[0133] As an example, such as Figure 13 As illustrated, if the system receives a PRP with only one PRP (e.g., Figure 6If the PRP1 command (CMD) 1000 is valid (PRP626), then in box 1310, the system can use the Physical Area Page List Table (PRPLT) index field of command 1000 to read PRPLT[N], i.e., the location in PRPLT SRAM 1300, which may contain the starting logical block address (SLBA) and / or namespace identifier (NSID) of command 1000. In box 1312, the system can look for a free location in a lookup table (LUT) (e.g., in LUT SRAM 1302) to enter the relevant PRP1 details (which may include the NSID), and in box 1314 calculate the logical block address (LBA), where the LBA and / or NSID are mapped to a buffer. The system can delete the pointer associated with PRPLT from command 1000 in box 1316 and retain it (“RSVD”), overwrite a portion of PRP1 with the pointer associated with PRPLT in box 1317, and send the modified command 1304 to its destination, the NVMe device, in box 1318. These operations ensure that the information existing in the shadow corresponds to the information stored in the NVMe device (e.g., the shadow includes the same PRP as the NVMe device).

[0134] As an example, such as Figure 14 As illustrated, if the system receives two valid PRPs (e.g., Figure 6 If the command (CMD) 1002 for “PRP1” and “PRP2” in PRP626 is executed, then in box 1310, the system can use the PRPLT index field of command 1002 to read PRPLT[N] (i.e., the location of PRPLT in SRAM 1300), which may contain the starting logical block address (SLBA) and / or namespace identifier (NSID) of command 1002.

[0135] In box 1410, the system can search for a free location in the LUT (e.g., in LUT SRAM 1302) to input the associated PRP1 details with the recalculated LBA and / or NSID mapped to the buffer. The system can remove the pointer associated with the PRPLT from command 1002 in box 1316 and retain it (“RSVD”), and in box 1318, transmit the modified command 1400 to its destination, the NVMe device. These operations ensure that the information present in the shadow corresponds to the information stored in the NVMe device (e.g., the shadow includes the same PRP as the NVMe device).

[0136] As an example, such as Figure 15 As illustrated, if the system receives a PRP with a valid PRP (e.g., Figure 6In PRP626) "PRP1" and a pointer to PRPL (e.g., Figure 6 In box 1310, the system can use the PRPLT index field of command 1502 to read PRPLT[N], i.e., the location in PRPLT SRAM 1300, which may contain the starting logical block address (SLBA) and / or namespace identifier (NSID) of command 1502. In box 1410, the system can look for a free location in the LUT (e.g., in LUT SRAM 1302) to input the relevant PRP1 details with the recalculated LBA and / or NSID mapped to the buffer. In box 1510, the system can transfer the PRPL pointer from command 1502 to the PRPLT[N] location in PRPLT SRAM 1300. The system can remove the pointer associated with PRPLT from command 1502 in box 1316 and retain it (“RSVD”), and send the modified command 1500 to its destination, the NVMe device, in box 1318. These operations ensure that the information present in the shadow corresponds to the information stored in the NVMe device (e.g., the shadow includes the same PRP and PRPL pointers as the NVMe device).

[0137] from Figure 15 The example continues, in Figure 16 In the illustrated example, PRPL 1100 can be associated with the PRPL pointer of command 1502 written to PRPLTSRAM 1300 (e.g., Figure 6 The PRPL pointer 628 in the command 1502 is associated with each entry of the incoming data. Each entry of the incoming data in command 1502 can be a PRP of PRPL 1100 (e.g., Figure 6 In box 1610, the system can find a free location in the LUT (e.g., in LUT SRAM 1302) for each PRP of PRPL 1100 and input that PRP into that LUT location, with a recalculated LBA and / or namespace identifier (NSID) mapped to the buffer. The system can remove the logical block offset (“Loffset1”, “Loffset2”, “Loffset3”) of each PRP from PRPL 1100 in box 1612, such as by overwriting Loffset with zeros, and in box 1614 transfer the modified PRPL 1600 to its destination, the NVMe device. These operations ensure that the information present in the shadow corresponds to the information stored in the NVMe device (e.g., the shadow includes the same PRP as the NVMe device).

[0138] from Figure 15The example continues, in Figure 17 In the illustrated example, PRPL 1200 can be associated with the PRPL pointer of command 1502 written to PRPLTSRAM 1300 (e.g., Figure 6 The PRPL pointer 628 in the command 1502 is associated with and contains a pointer to the next PRPL. Each entry of the incoming data in command 1502 (except the last entry) can be a PRP of PRPL 1200 (e.g., Figure 6 (PRP 626 in the example). The last entry may be a pointer to the next PRPL. In box 1710, the system may find a free location in the LUT (e.g., in LUT SRAM 1302) for each PRP of PRPL 1200 and input the PRP into that LUT location with a recalculated LBA and / or namespace identifier (NSID) mapped to the buffer.

[0139] In box 1712, the system can transfer a pointer to the next PRPL 1100, 1200 from PRPL 1200 to the PRPLT[N] location in PRPLT SRAM 1300. The system can remove the logical block offset (“Loffset1”, “Loffset2”) of each PRP from PRPL 1200 in box 1612, such as by overwriting Loffset with zeros, and transfer the modified PRPL 1700 to its destination, the NVMe device, in box 1614.

[0140] In some implementations, a pointer to the next PRPL in PRPL 1200 and written to the PRPLT[N] location in PRPLT SRAM 1300 can point to another PRPL 1200, and Figure 17 The illustrated example can be repeated in specific implementations. Such repetition can occur for each subsequent PRPL 1200. In some implementations, a pointer to the next PRPL in PRPL 1200 and written to the PRPLT[N] location in PRPLT SRAM 1300 can point to PRPL 1100, and... Figure 16 The illustrated example can be implemented. This specific implementation can be found in... Figure 17 This occurs after one or more specific implementations of the illustrated example. These operations ensure that the information present in the shadow corresponds to the information stored in the NVMe device (e.g., the shadow includes the same PRP as the NVMe device).

[0141] Therefore, some implementations can capture device access, interpret the device access according to the NVMe specification, and extract the PRP from it on an on-the-fly basis. Some implementations can maintain 32 address ranges in registers used for 32 commit queues. In some implementations, the NVMe device driver (e.g., Figure 2 The NVMe driver 208 in the system can be configured with SQ start and end addresses. When the NVMe device issues a read address within any of these ranges, the system can determine that the read address is used to read from that SQ (e.g., Figure 5 The SQ 404 read command.

[0142] Some implementations can reuse a reserved field in the NVMe CMD that maintains a PRPLT index for command entries. This allows the system to now have a 100% true copy of all PRPs dynamically cached within the NVMe device.

[0143] In some implementations, the NVMe driver can configure the SQ table using the base address and Qsize. In some implementations, the NVMe driver can configure the CQ table using the base address and Qsize.

[0144] In some implementations, the NVMe driver can queue commands, eliminating the need for a PRPLT. The computing system can obtain a free PRPLT slot from the NVMe ICE HW(N) or the NVMe inline cryptographic module (N). The computing system can obtain the cryptographic key slot index from a secure process.

[0145] As an example, regarding Figure 13 In the illustrated example, if the user data fits into the first system storage page, the system can write security context information at PRPLT location N in PRPLT SRAM 1300, write PRPLT_Index = N in command 1000, continue with other steps for command creation and push command 1000 into SQ, and maintain the mapping of {SQID, CID}->N or {SQID, CID, NSID}->N.

[0146] As another example, regarding Figure 14In the illustrated example, in box 1412, if the user data fits into both system storage pages, the computing system can write security context information at PRPLT location N in PRPLT SRAM 1300, write PRPLT_Index = N in command 1002 and insert the LB offset into the lower 12 bits of PRP2 (page boundary alignment), continue with other steps for command creation and push command 1002 into SQ, and maintain the mapping of {SQID, CID}->N or {SQID, CID, NSID}->N.

[0147] As another example, regarding Figure 15 and Figure 16 In the illustrated example, if user data requires more than two system storage pages and reaches a maximum system storage page threshold, the system can determine that only one PRPL is needed. The PRPL creation process may include inserting the LB offset into the lower 12 bits of PRPL 1100 (bits [1:0] = 2'b00) for each PRP entry (PRRPs are page boundary aligned). Command processing may include writing security context information at PRPLT location N in PRPLT SRAM 1300, writing PRPLT_Index = N in command 1502 and inserting the PRPL pointer into the PRP2 field, continuing with other steps for command creation and pushing command 1502 into SQ, and maintaining the mapping of {SQID, CID}->N or {SQID, CID, NSID}->N.

[0148] As another example, regarding Figures 15 to 17 In the illustrated example, user data needs to exceed a threshold of system storage pages. Multiple PRPLs 1100 and 1200 (chained PRPLs) are required. The PRPL creation process may include inserting the LB offset into the lower 12 bits of PRPLs 1100 and 1200 (bits [1:0] = 2'b00) for all entries in PRPL 1200 except the last one (PRPs are page boundary aligned), and placing a pointer to the next PRPL 1200 into the last PRP entry in PRPL 1100. Command processing may include writing security context information at PRPLT location N in PRPLT SRAM 1300, writing PRPLT_Index = N in command 1502 and inserting the first PRPL pointer into the PRP2 field, continuing with other steps for command creation and pushing command 1502 into SQ, and maintaining the mapping {SQID, CID}->N or {SQID, CID, NSID}->N.

[0149] In some implementations, when read data for this access arrives from DDR, the system can parse command structures 1000, 1002, and 1502 and extract PRP details and store them in shadows, such as PRPLT SRAM 1300 and / or LUT SRAM 1302. If command 1502 includes a pointer to the PRPL, the system can cache it in a temporary small storage device, such as PRPLT SRAM 1300 and / or LUT SRAM 1302.

[0150] As an example, if commands (CMD) 1000, 1002, and 1502 have a valid PRP1, the system can use the command's PRPLT index field to read PRPLT[N] (which has an SLBA and / or namespace identifier (NSID)). The system can find a free location in the LUT SRAM 1302 and input PRP1 into that LUT location. The system can (re)compute the LBA, where the LBA and / or NSID are mapped to the buffer; remove the PRPLT pointer from commands 1000, 1002, and 1502 and make it RSVD; and send the modified commands 1304, 1400, and 1500 to the NVMe device. The end result may be that the system includes the same PRP that the NVMe device has in its shadow.

[0151] When an NVMe device issues a read address (N) for reading PRPL 1100, 1200, the system can perform a content search on the PRPLT in PRPLT SRAM 1300. It may hit address N. This read access can be used to read the PRP from PRPL 1100, 1200. The system can insert "N" into the read track FIFO (not shown) and forward the read access to system memory. When the read data for this access arrives from system memory, the system can pop the read track FIFO, such as by using the "N" fetch operation. The system can parse PRPL structures 1100, 1200 and extract PRP details and store them in shadows, such as PRPLT SRAM 1300 and / or LUT SRAM 1302.

[0152] When an NVMe device issues an access to one of the shadowed PRPs in the LUT SRAM 1302, it can be used for user data access. The system can perform encryption operations on the data associated with the PRPs within the shadowed PRP range. When the access to the data associated with the PRP (e.g., 4KB, 16KB, 64KB, etc.) is complete, the system can remove the PRP from the shadow. The system now has a 100% true shadow of all PRPs dynamically maintained internally by the NVMe device using only 8KB.

[0153] Some implementations can use LUTs (e.g., Figure 8 PRP Table 802, Figures 13 to 17 This is implemented using LUT SRAM1302, instead of PRPLT (e.g., Figure 8 In Figure 8 PRPL table 800, Figures 13 to 17 The advantages of using a LUT instead of a PRPLT implementation can include less software overhead than that incurred by implementing and managing both a PRPLT and a LUT, including the overhead incurred by implementing and managing the PRPLT itself and the data relationships between the PRPLT and the LUT. Compared to an implementation that implements both the PRPLT and the LUT together, the advantages can also include de-straining the NVMe device 214 (e.g., ...). Figure 1 The number of command submissions in the memory (24) is limited. Other advantages may include support for PCIe Address Translation Service (ATS) for virtual address to physical address mapping, and reduced silicon area due to not implementing and managing PRPLT.

[0154] Figure 18 An example of an NVMe inline cryptographic module is provided. (See reference.) Figures 1 to 18 NVMe inline cryptographic module 38 (e.g., Figures 1 to 3 Inline cryptographic module 38 Figure 5 The NVMe-ICE module 500 in the system can be configured to parse management commands and LUT1800 (e.g., Figure 8 PRP Table 802, Figures 13 to 17 LUT SRAM 1302 in the LUT is used in computing systems (e.g., Figure 1 The computing device 10 in Figure 2 Inline cryptography in NVMe systems (e.g., using PRP) Figure 6 The NVMe inline cipher module 38 may also include other components for implementing the NVMe inline cipher process using the PRP (Programmable Logic Module 626). These include an exclusive address range register 1804, which can be used for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. The NVMe inline cipher module 38 may include SQ and CQ address range registers 1806, which can be configured to store one or more submission queues (e.g., ...). Figure 5 SQ 404) and / or SQ entries and command queues (e.g., Figure 5 The start address, end address, and / or size of the completion queue (406) and / or CQ entries.

[0155] Other components of the NVMe inline cryptographic module 38 may include a cryptographic data path 1802, which includes a cryptographic engine 1810 (e.g., Figure 3 The NVMe inline cryptographic module 38 includes an encryption module 304 and a decryption module 306, and at least one cryptographic key table 1812 configured to store keys used to implement the cryptographic process. The NVMe inline cryptographic module 38 may include an add-on component 1808, which may include any combination of configuration registers that can be used during the initialization of the NVMe inline cryptographic module 38, the FIFO module, the clock module, the reset module, the debug module, etc.

[0156] Figure 19 An example of the structure of a command processed by the NVMe inline cryptographic module 38 is shown. (See reference) Figures 1 to 19 Command 1900 (for example, Figures 9B to 15 The structures of commands 902, 1000, 1002, 1102, 1202, and 1502 in the command set can be used for I / O access involving user data transfers that should be encrypted for security purposes, including read and / or write commands. The structure of command 1900 can be a modified version of a generic commit command format used in a specific NVMe implementation. For example, the structure of command 1900 can include aspects typically included in the commit command format, such as the command identifier (CID), PRP or SGL for the data transfer indicator (PSDT), merge indicator and opcode, namespace identifier (NSID), metadata pointer (MPTR), and PRP pointers (e.g., PRP1, PRP2). Figure 6 PRP 626) and / or PRPL pointers (e.g., at PRP2) (e.g., Figure 6 The modification to the structure of command 1900 may include a cryptographic function enable indicator (CE), which may include bits located in the common reserved space, such as 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 modification may also include a key slot locator, which may be any combination of bits located in the common reserved space, such as 8 bits, such as CWD3, bits 23:16. The key slot locator is configured to enable the NVMe inline cryptographic module 38 to locate the appropriate cryptographic key from key table 1812 to implement the cryptographic functions.

[0157] NVMe devices (e.g., Figure 1 The storage memory 24 in the middle, Figure 2 , Figure 5 and Figure 6 The NVMe device 214 in the middle can read command 1900 and PRP and / or PRP list (e.g., Figure 6 , Figure 11A , Figure 12A , Figure 16 , Figure 17 The PRPL (622, 1100, 1200) in the command prompt prompts the NVMe inline cryptographic module 38 to parse command entries and PRPs and / or PRP lists. The NVMe inline cryptographic module 38 can read the cryptographic feature enable indicator and key slot data from command 1900. In some examples, the NVMe inline cryptographic module 38 can overwrite the cryptographic feature enable indicator and key slot data in the command 1900 data, such as by writing zeros at appropriate positions in the command 1900 data structure.

[0158] The NVMe inline cryptographic module 38 can update the LUT 1800 using PRP entries from command 1900 and / or a list of PRPs and security context that can be parsed and read from command 1900. Figure 20 An example of the structure of a LUT 1800 is shown. (Reference) Figures 1 to 20 The structure of LUT 1800 may include an index for each entry of LUT 1800, as well as PRP entries and / or PRP list (PRPL) pointer (ptr) entries and the security context associated with each index. PRP entries and / or PRPL pointer entries may include the corresponding PRP base address. The security context may include a logical block address (LBA), namespace identifier (NSID), cryptographic enable indicator (CE), key slot data (KS), pointer types (including PRP or PRP list (PRPL) pointers (ptr)), data from metadata referenced by the metadata pointer in Command 1900, etc.

[0159] The NVMe inline cipher module 38 can perform on-the-fly PRP address modification at the data of command 1900, replacing PRP address bits (e.g., PRP1 and / or PRP2) with the corresponding LUT index. For example, the NVMe inline cipher module 38 can replace some address bits, such as those in the range of bits 63:12. Replacing some address bits allows the initial PRP address offset to be maintained within a page, such as a 4KB page. In some examples, the NVMe inline cipher module 38 can mark the PRP address as modified by setting one or more specific bits (such as bit 63) of the PRP address. In some implementations, the PRP address can be modified such that the modified address can be accessed by software (e.g., ...). Figure 2Within the scope defined by Application 204, Kernel 206, NVMe Driver 208, and PCIe Driver 210, the software is configured not to overlap with excluded scopes or other scopes used by the software that are not in LUT 1800. NVMe inline cryptographic module 38 can use the indexes of LUT 1800 to locate PRP entries and / or PRPL pointer entries, as well as the security context associated with commands, as further described herein.

[0160] Figure 21 This paper illustrates a system and method for implementing the initialization phase of an NVMe inline cryptographic process using a shadow of a PRP in a computing system configured to implement various implementation schemes. References Figures 1 to 21 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0161] Host software 2100 can enumerate one or more NVMe devices 214 by implementing process 2102, and detect the PCIe root complex 212 and NVMe device 214 by implementing process 2104. Host software 2100 can load the NVMe drive for NVMe device 214 by implementing process 2106 (e.g., Figure 2 The NVMe driver 208 in the process, and the PCIe controller that initializes the PCIe root complex 212 through the implementation process 2108.

[0162] The host software 2100 and the NVMe inline cryptographic module 38 can be initialized by implementing various procedures 2110. These procedures may include configuring various registers of the NVMe inline cryptographic module 38. These procedures may include configuring the exclusive address range register 1804 by implementing procedure 2112. The exclusive address range register 1804 can be configured for any number of exclusive address ranges, such as 8, 16, 32, 64, etc. These procedures may include configuring the SQ address range register 1806 by implementing procedure 2114, and configuring the CQ address range register 1806 by implementing procedure 2116. The SQ and CQ address range registers 1806 can be configured for any number of exclusive address ranges (such as 8, 16, 32, 64, etc.) for any number of commit queues (e.g., ...). Figure 5 SQ 404 in the context of command queues (e.g., SQ 404) and command queues (e.g., Figure 5 The completion queue 406 in the process (such as 8, 16, 32, 64, etc.). These processes may include configuring other configuration registers of the NVMe inline cryptographic module 38 by implementing process 2118 (e.g., Figure 18 Additional component 1808).

[0163] The host software 2100 and the NVMe inline cryptography module 38 can configure other aspects of the NVMe inline cryptography module 38, including management functions (Admin), input / output functions (IO), and SQ and CQ entries, through the implementation procedure 2120. These procedures may also include writing the start address and / or end address and / or address range size to the SQ and CQ address range registers 1806 through the implementation procedure 2122.

[0164] Figure 22 This paper illustrates a method for using PRP to implement the command creation phase of an NVMe inline encryption process in a computing system configured to implement various implementation schemes. References Figures 1 to 22 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0165] The host software 2100 can execute a command creation phase, in which it can create commands for reading from and / or writing to the host memory 36 (e.g., Figures 9B to 15 , Figure 19 Commands 902, 1000, 1002, 1102, 1202, 1502, and 1900 (as per the provided text). Such commands can be used for I / O access involving user data transfers that should be encrypted for security purposes. Host software 2100 can implement various procedures for creating commands that enable the cryptographic functionality of the NVMe inline cryptographic module 38 to execute the commands. Host software 2100 can obtain cryptographic key slot data for commands requiring cryptographic functionality by implementing procedure 2200. Host software 2100 can create commands, thereby programming the command data into a submission queue command entry, including enabling the key slot data and cryptographic functionality in procedure 2202. The key slot data can be configured to allow the NVMe inline cryptographic module 38 to retrieve data from a key table (e.g., ...). Figure 18 The appropriate cryptographic key is located in the key table 1812 in the NVMe database to enable cryptographic functionality. The cryptographic functionality enable indicator can be set to enable cryptographic functionality of the NVMe inline cryptographic module 38.

[0166] Host software 2100 can respond to a submission queue command entry by implementing process 2204, thereby submitting a command to host memory 36 for addition to the submission queue (e.g., Figure 5 (SQ 404 in the original text). Host software 2100 can update the commit queue doorbell at NVMe device 214 (e.g., by implementing procedure 2206) Figure 5 Doorbell 408 (in the middle).

[0167] Figure 23A and Figure 23B This paper illustrates a method for using a PRP to implement an NVMe inline encryption process in a computing system configured to implement various implementation schemes. References Figures 1 to 23B Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some implementations, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0168] Figure 23A The illustrated implementation involves having PRP entries (e.g., Figure 6 PRP 626 in the PRP (without PRPL entries) (e.g., Figure 6 Commands in PRPL pointer 628 (e.g., Figures 9B to 15 , Figure 19 Commands 902, 1000, 1002, 1102, 1202, 1502, and 1900 in the command list. Figure 23B The illustrated implementation involves having at least one PRP entry (e.g., Figure 6 PRP 626) and at least one PRPL entry (e.g., Figure 6 Commands in PRPL pointer 628 (e.g., Figures 9B to 15 , Figure 19 Commands 902, 1000, 1002, 1102, 1202, 1502, and 1900 in the relevant languages. Unless otherwise specified, Figure 23A and Figure 23B The process of the illustrated implementation scheme can be implemented in a similar manner.

[0169] NVMe device 214 can implement transactions with NVMe inline cryptographic module 38 through process 2300 for use from command commit queues (e.g., Figure 5 The NVMe inline cryptographic module 38 reads command entries (SQ 404 in the context of the command commit queue). In some implementations, the transaction can be an AXI transaction. The NVMe inline cryptographic module 38 can respond to the transaction by parsing and verifying the incoming transaction through the implementation process 2302. The verified transaction data can be used by the NVMe inline cryptographic module 38 to pass the data from the command commit queue (e.g., SQ 404 in the context of the command commit queue) through the implementation process 2304. Figure 5 The transaction that reads the command entry in SQ 404 is forwarded to the host memory 36. The host memory 36 can respond to the transaction by implementing procedure 2306 to return read data from the corresponding command commit entry.

[0170] exist Figure 23A In the illustrated implementation, where the read data from the corresponding command submission entry includes PRP entries but excludes PRPL entries, the NVMe inline cryptographic module 38 can update the LUT 1800 (e.g., Figure 8 PRP Table 802, Figures 13 to 17 The LUT SRAM 1302 in the example modifies the data from the command submission entry on the fly through the implementation process 2308. For example, refer to Figures 1 to 25 The NVMe inline cryptographic module 38 can add entries to PRP entries by adding an index, PRP address, and security context for each PRP entry submitted with a command, thereby updating the LUT 1800. An example of this is... Figure 25 The LUT 1800 is shown in the example. The NVMe inline cryptographic module 38 can modify the data of a command submission entry by replacing the PRP address data with the corresponding index of the LUT 1800, as illustrated in the example below. Figure 24 The data in command 1900 is shown.

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

[0172] The NVMe inline cryptographic module 38 can return modified data of the command submission entry to the NVMe device 214 through the implementation process 2310.

[0173] Figure 26 This paper illustrates a method for using a PRP to implement an NVMe inline encryption process in a computing system configured to implement various implementation schemes. References Figures 1 to 26 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some implementations, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0174] When submitting from the command queue (e.g., Figure 5 The entries read by SQ 404 in the code include the PRP list (e.g., Figure 6 , Figure 11A , Figure 12A , Figure 16 , Figure 17 When referring to PRPL 622, 1100, 1200, etc., such as the reference Figure 23B The described implementation scheme can also read entries from the PRP list. NVMe device 214 can implement transactions with NVMe inline cryptographic module 38 through process 2600 for reading each PRP entry from the PRP list (e.g., Figure 6 (PRP 626 in the document). In some implementations, the transaction can be an AXI transaction. (See reference...) Figure 23B In the described implementation, the transaction can specify the LUT index of the corresponding PRP list received in the modified data of the command commit entry. The NVMe inline cryptographic module 38 can be in the LUT 1800 (e.g., Figure 8 PRP Table 802, Figures 13 to 17 The LUT index is found in the LUT SRAM 1302, and the corresponding PRP list address and security context are retrieved through implementation procedure 2602. The NVMe inline cryptographic module 38 can forward the transaction for reading the PRP list entry from the command submission queue to the host memory 36 through implementation procedure 2604. The host memory 36 can respond to the transaction by returning the read data from the corresponding command submission entry through implementation procedure 2606.

[0175] The NVMe inline cryptographic module 38 can update the LUT 1800 on the fly and modify the data of the command commit entries for each PRP entry from the PRP list by implementing procedure 2608. For example, refer to Figures 1 to 28 The NVMe inline cryptographic module 38 can add entries for each PRP entry by adding an index, PRP address, and security context to each PRP entry in the PRP list, thereby updating the LUT 1800. An example of this is... Figure 28 The LUT 1800 is shown in the diagram. The NVMe inline cryptographic module 38 can modify the data of each PRP entry in the PRP list by replacing the PRP address data with the corresponding index of the LUT 1800, as illustrated in [example shown in the diagram]. Figure 27 As shown in the diagram, the NVMe inline cryptographic module 38 can return modified data of the command submission entry to the NVMe device 214 through the implementation process 2610.

[0176] Figure 29This paper illustrates a method for implementing a write command procedure using PRP to perform an NVMe inline encryption process in a computing system configured to implement various implementation schemes. References Figures 1 to 29 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some implementations, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0177] NVMe device 214 can send transactions to NVMe inline cryptographic module 38 via process 2900 for writing data from host memory 36. In some implementations, the transaction may be an AXI transaction. (See reference...) Figure 23A and Figure 26 In the described implementation, a transaction can specify the corresponding PRP received in the modified data of the command commit entry (e.g., Figure 6 The LUT index of PRP 626 in the PRP. The NVMe inline cryptographic module 38 can parse and verify transactions by implementing procedure 2902. The data parsed from the transaction may include the LUT index. The NVMe inline cryptographic module 38 can use the LUT index to retrieve PRP entries that have undergone write commands and security contexts from LUT 1800 by implementing procedure 2904. Figure 6 The corresponding address of PRP626 in the NVMe database. The NVMe inline cryptographic module 38 can use verified transaction data and data from LUT 1800 (e.g., ...). Figure 8 PRP Table 802, Figures 13 to 17 The data retrieved from the LUT SRAM 1302 in the PRP is forwarded to the host memory 36 via process 2906. The host memory 36 can respond to the transaction by reading the written data from the host memory 36 and returning the written data from the corresponding address of the PRP via process 2908. The NVMe inline cryptographic module 38 can encrypt the received written data via process 2910. For example, encryption can be achieved by retrieving a cryptographic key for encryption using the key slot of the security context. The NVMe inline cryptographic module 38 can send the encrypted written data to the NVMe device 214 via process 2912.

[0178] Figure 30 This paper illustrates a method for using PRP to implement a read command procedure for an NVMe inline encryption process in a computing system configured to implement various implementation schemes. References Figures 1 to 30 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some implementations, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0179] NVMe device 214 can send a transaction to NVMe inline cryptographic module 38 through implementation process 3000 for reading data from the NVMe device logical block address to write to host memory 36. In some implementations, the transaction may be an AXI transaction. (See reference...) Figure 23A and Figure 26 In the described implementation, a transaction can specify the corresponding PRP received in the modified data of the command commit entry (e.g., Figure 6 The LUT index (PRP 626) in the PRP. NVMe device 214 can send encrypted data from the NVMe device logical block address by implementing process 3002. NVMe inline cryptographic module 38 can parse and verify transactions by implementing process 3004. The data parsed from the transaction may include the LUT index. NVMe inline cryptographic module 38 can use the LUT index to retrieve data from LUT 1800 (e.g., PRP 626) by implementing process 3006. Figure 8 PRP Table 802, Figures 13 to 17 LUTSRAM 1302 in the database retrieves PRP entries that have undergone read commands and security contexts (e.g., Figure 6 The address corresponding to PRP 626 in the PRP is specified. The NVMe inline cryptographic module 38 can decrypt the received encrypted data by implementing process 3008. For example, decryption can be achieved by retrieving the cryptographic key used for decryption using the key slot of the security context. The NVMe inline cryptographic module 38 can use the verified transaction data and the data retrieved from LUT 1800 to forward the transaction for writing to the PRP address to host memory 36 by implementing process 3010. The NVMe inline cryptographic module 38 can send the decrypted data for writing to the PRP address to host memory 36 by implementing process 3012.

[0180] Figure 31 This illustrates a method for command-line execution of an NVMe inline encryption process using PRP in a computing system configured to implement various implementation schemes. References Figures 1 to 31 Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5NVMe-ICE module 100) and PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6 PCIe root complex 606); and NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some implementations, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0181] NVMe device 214 can write command completion entries to the command queue through process 3100 (e.g., Figure 5 The NVMe device 214 can send a command completion interrupt to the host software 2100 by implementing process 3102. The host software 2100 can implement driver process command completion by implementing process 3104. The host software 2100 can write the command queue head pointer to the command queue head pointer doorbell (e.g., in CQ 406) at the NVMe device 214 by implementing process 3106. Figure 5 (Doorbell 410 in the middle).

[0182] Figure 32A and Figure 32B This paper illustrates a method for using a command procedure for employing a PRP in a computing system configured to implement various implementation schemes. This command procedure utilizes the Peripheral Component Interconnect High-Speed ​​(PCIe) address translation service for NVMe inline cryptographic processes. Reference Figures 1 to 32B Computing systems (e.g., Figure 1 The computing device 10 in Figure 2 The inline cryptographic NVMe system 200 may include: host memory 36 (e.g., Figure 5 The host memory 402 in the host system; the host processing system 202 (e.g., Figure 5 The host 400, Figure 6 The processing system 600 in the system can be implemented as a SoC and configured to, for example, via a processor (e.g., Figure 1 and Figure 2 Processor 14 in Figure 5 The host 400 executes host software 2100 (e.g., Figure 2 The application 204, kernel 206, NVMe driver 208, PCIe driver 210 are included, and an NVMe inline cryptographic module 38 is also included (e.g., Figure 5 NVMe-ICE module 100), PCIe root complex 212 (e.g., Figure 2 PCIe controller 212 in Figure 6The PCIe root complex 606 and the memory management unit (MMU) 3200 (e.g., Figure 1 The memory interface 34 in the memory; and the NVMe device 214 (e.g., Figure 1 (The storage memory 24 in the middle). In some examples, the host software 2100 may be an operating system (e.g., Android, Windows, iOS, etc.).

[0183] Figure 32A and Figure 32B The illustrated process can be implemented in the same manner as described herein. For example, the command creation phase can be implemented as described in the reference. Figure 22 The described implementation, command procedures 2300, 2302, 2304, 2306, 2308, 2310, and 2312 can be found in the reference. Figure 23A and Figure 23B As described above, the NVMe device initiating data transmission can be implemented as described in the reference. Figure 29 and Figure 30 The described implementation, and the command completion phase can be referenced as follows. Figure 31 The described implementation.

[0184] The NVMe inline cryptographic module 38 can obtain the necessary information for PRP (e.g., ...) from the MMU 3200 through the implementation of procedure 3202. Figure 6 PRP 626) and / or PRPL (e.g., Figure 6 , Figure 11A , Figure 12A , Figure 16 , Figure 17 The virtual address to physical address mapping of the addresses (PRPL 622, 1100, 1200) in the NVMe device. The addresses used by the NVMe device can be in virtual address format, and the addresses used by the host device 36 can be in physical address format. The NVMe device 214 can parse the received command entry data and request to read the PRP list (e.g., ...) by implementing process 3206. Figure 6 , Figure 11A , Figure 12A , Figure 16 , Figure 17 PRP entries (e.g., PRPL622, PRPL 1100, PRPL 1200) in PRPL622, PRPL 1100, and PRPL 1200. Figure 6 (PRP 626 in the PRP list). The NVMe inline cryptographic module 38 can obtain the virtual address to physical address mapping of the address of each PRP for the PRP list from the MMU 3200 by implementing process 3204.

[0185] Various implementation plans (including but not limited to the above references) Figures 1 to 32BThe described implementation scheme can be implemented in a wide variety of computing systems, including mobile computing devices. Examples of mobile computing devices suitable for use with the various implementation schemes are shown in [the provided text]. Figure 33 The mobile computing device 3300 may include a processor 3302 coupled to a touchscreen controller 3304 and internal memory 3306. The processor 3302 may be one or more multi-core 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 insecure and / or unencrypted memory, or any combination thereof. Examples of memory types that can be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 3304 and processor 3302 may also be coupled to a touchscreen panel 3312, such as a resistive-sensing touchscreen, a capacitive-sensing touchscreen, an infrared-sensing touchscreen, etc. Additionally, the display of the mobile computing device 3300 does not need to have touchscreen capability.

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

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

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

[0189] Various implementation plans (including but not limited to the above references) Figures 1 to 32B The described implementation scheme can be implemented in a wide variety of computing systems, including a laptop computer 3400, of which an example is... Figure 34 The following is an example. Many laptop computers include a touchpad touch surface 3417, which serves as a pointing device for the computer and is therefore capable of receiving gestures similar to those implemented on computing devices equipped with touchscreen displays and as described above. The laptop computer 3400 will typically include a processor 3402 coupled to volatile memory 3412 and a disk drive 3413 containing mass non-volatile memory such as flash memory. Additionally, the computer 3400 may have one or more antennas 3408 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or to a cellular transceiver 3416 coupled to the processor 3402. The computer 3400 may also include a floppy disk drive 3414 and a compact disc (CD) drive 3415 coupled to the processor 3402. In a laptop configuration, the computer casing includes a touchpad 3417, a keyboard 3418, and a display 3419, all coupled to the processor 3402. Other configurations of the computing device may include a computer mouse or trackball, which are well known to be coupled to the processor (e.g., via USB input), and may also be used in combination with various implementation schemes.

[0190] Various implementation plans (including but not limited to the above references) Figures 1 to 32B The described implementation scheme can also be implemented in a fixed computing system, such as any of a variety of commercially available servers. Figure 35 Example server 3500 is illustrated. This server 3500 typically includes one or more multi-core processor assemblies 3501 coupled to volatile memory 3502 and mass non-volatile memory (such as disk drives 3504). Figure 35As illustrated, a multi-core processor assembly 3501 can be added to a server 3500 by inserting it into the rack of the assembly. The server 3500 may also include a floppy disk drive, compact disc (CD), or digital multi-disc (DVD) drive 3506 coupled to the processor 3501. The server 3500 may also include network access ports 3503 coupled to the multi-core processor assembly 3501 for establishing a network interface connection with a network 3505, such as a local area network, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, 5G, LTE, or any other type of cellular data network) coupled to other broadcast system computers and servers.

[0191] Computer program code or "program code" intended to be executed on a programmable processor to perform operations of various implementation schemes may be written in high-level programming languages ​​(such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic), structured query languages ​​(e.g., Transact-SQL), Perl, or in various other programming languages. Program code or program stored on a computer-readable storage medium as used herein may refer to machine language code (such as object code) whose format can be understood by a processor.

[0192] The following paragraphs describe specific implementation examples. While some of the specific implementation examples described below are based on example systems, devices, or methods, other example implementations may include: example systems or devices implemented as methods for performing operations of example systems or devices, as discussed in the following paragraphs; example systems, devices, or methods implemented by computing devices, as discussed in the following paragraphs, including NVMe inline cryptographic modules configured to perform operations of example systems, devices, or methods; example systems, devices, or methods implemented by computing devices, as discussed in the following paragraphs, including processing systems configured with processing device-executable instructions to perform operations of example systems, devices, or methods; computing devices including components for performing functions of example systems, devices, or methods; and example systems, devices, or methods implemented as non-transitory processor-readable storage media storing processor-executable instructions, as discussed in the following paragraphs, which are configured to cause a processor of a computing device to perform operations of example systems, devices, or methods.

[0193] Example 1. A method for providing data encryption in a non-volatile memory fast (NVMe) memory device, the method comprising selectively encrypting data for storage by using inline encryption circuitry in such a way as to distinguish data transmitted via a PCIe link from drive, read, page, and buffer address data transmitted via the PCIe link; and encrypting only the data.

[0194] Example 2. The method according to Example 1, the method further comprising: identifying a possible address range based on an operation performed in the NVMe memory device; and storing the possible address range in memory, wherein distinguishing data transmitted via a PCIe link from driver, read, page, and buffer address data transmitted via the PCIe link includes identifying data having addresses not stored in the possible address range as data for encryption.

[0195] Example 3. According to the method of Example 2, the possible address range is identified based on the operations performed in the NVMe memory device, which includes only maintaining shadows of those pages that the NVMe memory device has already read from system memory.

[0196] Example 4. A method implemented in an inline cryptographic module of a system-on-chip (SoC) for a non-volatile memory fast (NVMe) device, the method comprising: automatically masking all active PRPs within the NVMe device.

[0197] Example 5. The method according to Example 4, the method further comprising: maintaining 32 address ranges in a register associated with the submission queue and programmed by the device driver during initialization; determining whether the NVMe device requests a read command from the submission queue (SQ) based on an access made from the NVMe device in one of the 32 address ranges; and determining whether to encrypt the accessed data based on the extracted PRP.

[0198] Example 6. The method according to any one of Examples 4 to 5, the method further comprising: masking all PRPs inside the NVMe device within a 32-register address range of the submission queue to simplify the search logic for identifying incoming user data buffer accesses.

[0199] Example 7. The method according to any one of Examples 4 to 6, the method further comprising: comparing an incoming address from the NVMe device with an address database stored in memory, the address database including a Submission Queue (SQ) table, a Completion Queue (CQ) table, a PRP list table, and start and end addresses of the PRP table; and determining whether to encrypt data based on whether the incoming address matches an entry in the address database stored in memory.

[0200] Example 8. The method according to any one of Examples 4 to 7, the method further comprising: capturing device access for interpretation according to the NVMe specification; and extracting the PRP from each request on an ad hoc basis and evaluating each access request to determine whether it is legitimate.

[0201] Example 9. The method according to any one of Examples 4 to 8, the method further comprising: configuring a register with a start address and an end address of a commit queue to identify whether a read address falls within one of 32 address ranges; determining the PRP cached in the NVMe device; and storing a PRP list (PRPL) index of command entries in a reserved field of an NVMe command, the PRPL index providing an accurate shadow of all PRPs dynamically cached within the NVMe device.

[0202] Example 10. The method according to any one of Examples 4 to 9, the method further comprising: configuring a commit queue (SQ) with a base address and a Qsize value; configuring a completion queue (CQ) with a base address and a Qsize value; and using fields in the NVMe command structure to store PRPL indexes of command entries in order to create a cached shadow of all PRPs within the NVMe device.

[0203] Example 11. The method according to any one of Examples 4 to 10, wherein in response to determining that user data is suitable for a system storage page: security context information is written at position N of the Physical Region Page List Table (PRPLT); PRPLT_Index = N is written in the command; the command is created and pushed into the SQ; and the mapping of ({SQID, CommandID}->N) is maintained.

[0204] Example 12. The method according to any one of Examples 4 to 11, wherein in response to determining that user data fits into two system storage pages: security context information is written at position N in the Physical Region Page List Table (PRPLT); the LB offset is inserted into the lower 12 bits of PRP2 (page boundary alignment); the command is created and pushed into SQ; and the mapping of ({SQID, CID}->N) is maintained.

[0205] Example 13. The method according to any one of Examples 4 to 12, wherein in response to determining that user data is suitable for more than 2 but less than 512 system storage pages: for each page boundary aligned PRP entry, the LB offset is inserted into the lower 12 bits and bit [1:0] = 2'b00 is set; security context information is written at position N in the Physical Region Page List Table (PRPLT), and the PRPL pointer is inserted into the PRP2 field; the command is created and pushed into SQ; and the mapping of ({SQID, CID}->N) is maintained.

[0206] Example 14. The method according to any one of Examples 4 to 13, wherein in response to determining that user data fits more than 512 system storage pages: for all PRP entries except the last page boundary aligned PRP entry, the LB offset is inserted into the lower 12 bits, bit [1:0] = 2'b00 is set, and a pointer to the next PRPL is placed into the last PRP entry; security context information is written at position N in the Physical Region Page List Table (PRPLT), and the first PRPL pointer is inserted into the PRP2 field; the command is created and pushed into the SQ; and the mapping of ({SQID, CID}->N) is maintained.

[0207] Example 15. The method according to any one of Examples 4 to 14, the method further comprising: reading PRPLT[N](SLBA) using the PRPLT index field of the command; finding a free position in the LUT and inputting PRP1 into the LUT position; calculating the LBA to which the buffer is mapped; deleting the PRPLT pointer from the command and making it RSVD; and transmitting the modified command to the NVMe device.

[0208] Example 16. The method according to any one of Examples 4 to 15, the method further comprising: receiving a command; parsing the command structure of the command, extracting PRP details, and adding the extracted PRP details to the shadow in response to receiving read data for access from the memory; and storing a pointer to the PRPL included in the command.

[0209] Example 17. The method according to any one of Examples 4 to 16, the method further comprising: performing a content search on the PRPLT in response to determining that the device issues a request for reading a read address (N) to read the PRPL to hit the location N; inserting "N" into the read tracking FIFO; forwarding the read access to system memory; popping the read tracking FIFO to obtain "N" in response to determining that read data for the access has arrived from system memory; parsing the PRPL structure to extract the PRP details; and adding the PRP details to the shadow.

[0210] Example 18. The method according to Example 17, the method further comprising: in response to receiving a request for user data access to one of the PRPs that is hit by the shadow, retrieving details of the PRP from the shadow.

[0211] Example 19. A method for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol via an inline cryptographic module of a processing system, the method comprising: identifying a first transaction from an NVMe device for reading a command entry from 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 using 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.

[0212] Example 20. The method according to Example 19, wherein generating the shadow of the at least one PRP using the first data structure for the command entry data includes generating an entry for the at least one PRP using the first data structure, the entry for the at least one PRP using the first data structure including the address of the at least one PRP and a security context from the command entry data for the at least one PRP.

[0213] Example 21. The method according to any one of Examples 19 or 20, wherein modifying the command entry data to enable reading the shadow of the at least one PRP includes modifying the address of the at least one PRP in the command entry data to point to the shadow of the at least one PRP.

[0214] Example 22. According to the method of Example 19, wherein the shadow of the at least one PRP using the first data structure for generating the command entry data includes generating an entry for the at least one PRP using the first data structure, the entry for the at least one PRP using the first data structure including the address of the at least one PRP and a security context from a second data structure for the at least one PRP.

[0215] Example 23. The method according to Example 22, wherein the command entry data includes references to entries for employing the at least one PRP of the second data structure, the method further includes reading the entries for employing the at least one PRP of the second data structure, the entries for employing the at least one PRP of the second data structure including the address of the at least one PRP and the security context of the at least one PRP from the command entry data.

[0216] Example 24. The method according to any one of Examples 19, 22 or 23, wherein modifying the command entry data to enable reading the shadow of the at least one PRP includes removing references to entries for employing the at least one PRP using a second data structure.

[0217] Example 25. The method according to any one of Examples 19 to 24, the method further comprising: transmitting modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for performing an operation on the shadow of the at least one PRP; and performing an encryption operation on the data associated with the shadow of the at least one PRP based on the security context associated with the shadow of the at least one PRP.

[0218] Example 26. The method according to any one of Examples 19 to 25, the method further comprising: generating a shadow of the command entry data using the first data structure, a PRP list (PRPL); and modifying the command entry data to enable reading the shadow of the PRPL, thereby generating modified command entry data.

[0219] Example 27. The method according to any one of Examples 19 to 21, 25 or 26, wherein generating the shadow of the PRPL using the first data structure for the command entry data includes generating an entry for the PRPL using the first data structure, the entry for the PRPL using the first data structure including the address of the PRPL and the security context of the PRPL from the command entry data.

[0220] Example 28. The method according to any one of Examples 19 to 21 or 25 to 27, the method further comprising: transmitting 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 using the first data structure; and modifying each PRP of the PRPL to point to the shadow of each PRP, thereby generating the modified PRPL.

[0221] Example 29. The method according to Example 28, wherein generating the shadow of each PRP of the PRPL using the first data structure includes generating an entry for each PRP of the PRPL using the first data structure, the entry for each PRP of the PRPL using the first data structure including an address of each PRP of the PRPL from the PRPL and a security context for each PRP of the PRPL using the first data structure.

[0222] Example 30. The method according to any one of Examples 28 or 29, the method further comprising: transmitting a modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for performing an operation on at least one of the shadows of each PRP; and performing an encryption operation on the data associated with the at least one shadow of each PRP based on the security context associated with the at least one shadow of each PRP.

[0223] Example 31. The method according to any one of Examples 28 to 30, wherein modifying the command entry data to enable reading the shadow of the PRPL includes modifying the address of the PRPL pointer of the PRPL used in the command entry data to point to the shadow of the PRPL.

[0224] Example 32. The method according to any one of Examples 19 or 22 to 26, wherein generating the shadow of the PRPL using the first data structure includes generating an entry for the shadow of each PRP of the PRPL using the first data structure, the entry for the shadow of each PRP using the first data structure including the address of each PRP of the PRPL from the PRPL and the security context of each PRP from the second data structure.

[0225] Example 33. The method according to Example 32, the method further comprising: transmitting modified command entry data to the NVMe device; identifying a second transaction from the NVMe device for reading the PRPL, wherein the shadow of the PRPL using the first data structure that generates the command entry data responds to the identification of the second transaction from the NVMe device; and modifying each PRP of the PRPL to point to the shadow of each PRP, thereby generating the modified PRPL.

[0226] Example 34. The method according to Example 33, the method further comprising: transmitting a modified PRPL to the NVMe device; identifying a third transaction from the NVMe device for performing an operation on at least one of the shadows of each PRP; and performing an encryption operation on data associated with at least one of the shadows of each PRP based on the security context associated with the at least one shadow of each PRP.

[0227] Example 35. The method according to any one of Examples 19, 22 to 26 or 33 to 34, wherein modifying the command entry data to enable reading the shadow of the PRPL includes removing references to entries used for employing the second data structure of the PRPL.

[0228] Example 36. The method according to any one of Examples 19, 22 to 26, or 33 to 35, wherein the command entry data includes a reference to an entry employing a second data structure, the entry employing 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 employing the second data structure.

[0229] Example 37. The method according to any one of Examples 19 to 36, wherein the modified command entry data includes a virtual address, the method further comprising obtaining a virtual address-to-physical address mapping for the virtual address in parallel with the shadow of the at least one PRP that generates the command entry data using the first data structure.

[0230] Example 38. The method according to any one of Examples 19 to 37, wherein the first transaction identifying the command entry from the NVMe device for reading the command submission queue includes an address identifying the transaction in at least one address range for at least one submission queue, the at least one address range being stored in the configuration register of the inline cryptographic module.

[0231] Example 39. A method for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol, executed by a processing system, the method comprising: obtaining a cryptographic key slot for a command from a security process, the cryptographic key slot including a cryptographic key slot reference; writing cryptographic enable to a command entry for a submission queue of the command; writing the cryptographic key slot reference to the command entry for the submission queue of the command; and submitting the command entry of the command having the cryptographic enable and the cryptographic key slot reference to the submission queue.

[0232] Example 40. The method according to Example 39, the method further comprising: obtaining 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 into the command entry for the command in the submission queue, wherein submitting the command entry of the command having the cipher enable and the cipher key slot reference to the submission queue includes submitting the command entry of the command including the cipher enable, the cipher key slot reference, and the PRPLT slot reference to the submission queue.

[0233] Example 41. The method according to any one of Examples 39 or 40, wherein: the command has more than one page-level read / write pointer (PRP); the method further includes writing a portion of at least one PRP of the command entry for the submission queue to the logical block address offset; and submitting the command entry of the command having the cipher enable and the cipher key slot reference to the submission queue includes submitting the command entry of the command having the cipher enable, the cipher key slot reference and the at least one PRP having the logical block offset.

[0234] Example 42. The method according to any one of Examples 39 or 40, wherein the data of the command is greater than two system storage pages, and the method further includes writing a logical block address offset into at least one portion of a PRP in a PRP list (PRPL).

[0235] Example 43. The method according to any one of Examples 39, 40 or 42, wherein: the data of the command is greater than two system storage pages; the method further includes writing a PRPL pointer to the command entry for the submission queue at a location for PRP; and submitting the command entry of the command having the cipher enable and the cipher key slot reference to the submission queue includes submitting the command entry of the command having the cipher enable, the cipher key slot reference and the PRPL pointer.

[0236] Example 44. The method according to any one of Examples 39, 40, 42 or 43, wherein the data of the command is greater than the number of system storage pages that can be referenced by the PRP and PRPL, the method further comprising writing the PRPL pointer to the PRP of the PRPL.

[0237] Example 45. The method according to any one of Examples 39 to 44, the method further comprising: configuring a first group of one or more registers of the inline cryptographic module corresponding to a plurality of command submission queues; and setting each register in the first group of one or more registers with address ranges of different command submission queues in the command submission queues.

[0238] Example 46. The method according to Example 45, wherein setting each register in the first group of one or more registers using the address range of different command submission queues in the command submission queue includes setting each register in the first group of one or more registers using the start address and size of the different command submission queues in the command submission queue.

[0239] Example 47. The method according to Example 45, wherein setting each register in the first group of one or more registers using the address range of different command submission queues in the command submission queue includes setting each register in the first group of one or more registers using the start address and end address of different command submission queues in the command submission queue.

[0240] Example 48. The method according to any one of Examples 45 to 47, the method further comprising: configuring a second group of one or more registers of the inline cryptographic module corresponding to a plurality of command completion queues; and setting each register in the second group of one or more registers with the starting address and size of different command submission queues in the command submission queues.

[0241] Example 47. The method according to Examples 45 to 47, the method further includes: configuring one or more registers of the inline cryptographic module corresponding to a plurality of exclusive address ranges; and setting each register in the one or more registers of the second group using the starting address and size of different exclusive address ranges in the exclusive address ranges.

[0242] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the presented order. As those skilled in the art will appreciate, the operations of the foregoing embodiments can be performed in any order. Words such as “afterward,” “then,” “next,” etc., are not intended to limit the order of operations; these words are only used to guide the reader through the description of the method. Furthermore, any reference to singular claim elements (e.g., references using the articles “a,” “an,” or “described”) should not be construed as limiting that element to the singular.

[0243] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with various implementation schemes can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. While those skilled in the art may implement the described functionality in different ways for each specific application, such implementation decisions should not be construed as departing from the scope of the claims.

[0244] Hardware used to implement the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic unit, discrete hardware component, or any combination thereof designed to perform the functions described herein. While the general-purpose processor may be a microprocessor, in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0245] In one or more embodiments, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operation of the methods or algorithms disclosed herein can be implemented in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium can be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable media can include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically magnetically reproduce data, while optical discs optically reproduce data using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as a single line of code and / or instruction, or any combination or set of code and / or instructions, on a non-transitory processor-readable medium and / or computer-readable medium that may be incorporated into a computer program product.

[0246] The above description of the disclosed embodiments is provided to enable any person skilled in the art to implement or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and implementations without departing from the scope of the claims. Therefore, this disclosure is not intended to be limited to the embodiments and implementations described herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol via an inline cryptographic module of a processing system, the method comprising: The first transaction that identifies the command entry from the NVMe device used to read the command submission queue; Read the command entry data of the command entry; The shadow of at least one page-level read / write pointer (PRP) using a first data structure is used to generate the command entry data; as well as The command entry data is modified to enable the 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 using the first data structure for the command entry data includes generating an entry for the at least one PRP using the first data structure, the entry for the at least one PRP using the first data structure including the address of the at least one PRP and a security context from the command entry data for the at least one PRP.

3. The method of claim 1, wherein modifying the command entry data to enable reading the shadow of the at least one PRP includes modifying the address of the at least one PRP in 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 using the first data structure comprises generating an entry for the at least one PRP using the first data structure, the entry for the at least one PRP using the first data structure comprising the address of the at least one PRP and a security context from a second data structure for the at least one PRP.

5. The method of claim 4, wherein the command entry data includes references to entries for employing the at least one PRP of the second data structure, the method further comprising reading the entries for employing the at least one PRP of the second data structure, the entries for employing the at least one PRP of the second data structure including the address of the at least one PRP and the security context of 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 the shadow of the at least one PRP comprises removing references to entries for employing the at least one PRP using a second data structure.

7. The method according to claim 1, further comprising: The modified command entry data is transmitted to the NVMe device; A second transaction from the NVMe device for performing an operation on the shadow of the at least one PRP; as well as Encryption is performed on the data associated with the shadow of the at least one PRP based on the security context associated with the shadow of the at least one PRP.

8. The method according to claim 1, further comprising: The command entry data is generated using a PRP list (PRPL) based on the first data structure; as well as The command entry data is modified to enable the reading of the shadow of the PRPL, thereby generating modified command entry data.

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

10. The method according to claim 8, further comprising: The modified command entry data is transmitted to the NVMe device; A second transaction identifying the shadow from the NVMe device for reading the PRPL; Generate a shadow of each PRP of the PRPL using the first data structure; and Each PRP of the PRPL is modified to point to the shadow of each PRP, thereby generating the modified PRPL.

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

12. The method according to claim 10, further comprising: The modified PRPL is transmitted to the NVMe device; A third transaction from the NVMe device for performing an operation on at least one of the shadows of each PRP; as well as Encryption is performed on the data associated with at least one shadow of each PRP based on the security context associated with at least one shadow of each PRP.

13. The method of claim 8, wherein modifying the command entry data to enable reading the shadow of the PRPL comprises modifying the address of the PRPL pointer of the PRPL used in 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 using the first data structure comprises generating an entry for the shadow of each PRP of the PRPL using the first data structure, the entry for the shadow of each PRP using the first data structure comprising an address of each PRP of the PRPL from the PRPL and a security context of each PRP from the second data structure.

15. The method according to claim 14, further comprising: The modified command entry data is transmitted to the NVMe device; A second transaction identifying the PRPL from the NVMe device for reading the PRPL, wherein the shadow of the PRPL using the first data structure that generates the command entry data responds to the occurrence of the second transaction identifying the PRPL from the NVMe device; and Each PRP of the PRPL is modified to point to the shadow of each PRP, thereby generating the modified PRPL.

16. The method according to claim 15, further comprising: The modified PRPL is transmitted to the NVMe device; A third transaction from the NVMe device for performing an operation on at least one of the shadows of each PRP; as well as Encryption is performed on the data associated with at least one shadow of each PRP based on the security context associated with at least one shadow of each PRP.

17. The method of claim 8, wherein modifying the command entry data to enable reading the shadow of the PRPL comprises removing references to entries used for employing the second data structure of the PRPL.

18. The method of claim 8, wherein the command entry data includes a reference to an entry employing a second data structure, the entry employing 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 employing the second data structure.

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

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 includes an address identifying the transaction within at least one address range for at least one submission queue, the at least one address range being stored in the configuration register of the inline cryptographic module.

21. A method, executed by a processing system, for providing cryptographic functionality for data in a Non-Volatile Memory Fast (NVMe) protocol, the method comprising: The cryptographic key slot for the command is obtained from the secure process, the cryptographic key slot including a cryptographic key slot reference; Enable the password by writing it into the command entry used for submitting to the queue; Write the password key slot reference into the command entry for the submission queue of the command; as well as Submit the command entry containing the password enable and the password key slot reference to the submission queue.

22. The method according to claim 21, further comprising: Obtain the page-level read / write pointer lookup table (PRPLT) slot for the command from the inline cryptographic module, the PRPLT slot including a PRPLT slot reference; as well as Write the PRPLT slot reference into the command entry for the submission queue of the command. Submitting the command entry containing the password enable and the password key slot reference to the submission queue includes submitting the command entry containing the password enable, the password key slot reference, and the PRPLT slot reference to the submission queue.

23. The method according to claim 21, wherein: The command has more than one page-level read / write pointer (PRP); The method further includes writing a logical block address offset into at least one portion of the command entry for the submission queue of the command; and Submitting the command entry containing the password enable and the password key slot reference to the submission queue includes submitting the command entry containing the password enable, the password key slot reference, and the at least one PRP with the logical block offset.

24. The method of claim 21, wherein the data of the command is greater than two system storage pages, and the method further comprises writing a logical block address offset into a portion of at least one PRP in a PRP list (PRPL).

25. The method according to claim 21, wherein: The command contains data larger than two system storage pages; The method further includes writing a PRPL pointer to the command entry for the submission queue at the location designated for the PRP; and Submitting the command entry containing the password enable and the password key slot reference to the submission queue includes submitting the command entry containing the password enable, the password key slot reference, and the PRPL pointer.

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

27. The method according to claim 21, further comprising: Configure the first set of one or more registers of the inline cryptographic module corresponding to multiple command submission queues; as well as Each register in the first group of one or more registers is set using the address range of different command submission queues in the command submission queue.

28. The method of claim 27, wherein setting each register in the first group of one or more registers using the address range of different command submission queues in the command submission queue includes setting each register in the first group of one or more registers using the start address and size of the different command submission queues in the command submission queue.

29. The method of claim 27, wherein setting each register in the first group of one or more registers using the address range of different command submission queues in the command submission queue comprises setting each register in the first group of one or more registers using the start address and end address of different command submission queues in the command submission queue.

30. The method of claim 27, further comprising: Configure one or more registers in the second group corresponding to the multiple command completion queues of the inline cryptographic module; as well as Each register in the second group of one or more registers is set using the starting address and size of different command submission queues in the command submission queue.

31. The method according to claim 27, further comprising: Configure one or more registers in the second group corresponding to multiple exclusive address ranges of the inline cryptographic module; as well as Each register in the second group of one or more registers is set using the starting address and size of different exclusive address ranges within the exclusive address range.

32. A computing device, the computing device comprising: Processing system; and A non-volatile memory-fast (NVMe) inline cryptographic module coupled to the processing system, the NVMe inline cryptographic module being configured to: The first transaction that identifies the command entry from the NVMe device used to read the command submission queue; Read the command entry data of the command entry; The shadow of at least one page-level read / write pointer (PRP) using a first data structure is used to generate the command entry data; as well as The command entry data is modified to enable the 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 employing the first data structure, the entry for the at least one PRP employing the first data structure including the address of the at least one PRP and a security context from the command entry data for the at least one PRP, to generate the shadow of the at least one PRP employing the first data structure in the command entry data.

34. The computing device of claim 32, wherein the NVMe inline cryptographic module is further configured to modify the address of the at least one PRP in the command entry data to point to the shadow of the at least one PRP, thereby modifying the command entry data to enable reading 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 employing the first data structure, the entry for the at least one PRP employing the first data structure including the address of the at least one PRP and a security context from a second data structure for the at least one PRP, to generate the shadow of the at least one PRP employing the first data structure in the command entry data.

36. The computing device according to claim 35, wherein: The command entry data includes references to entries used for employing the second data structure in at least one PRP; and The NVMe inline cryptographic module is also configured to read the entry for employing the at least one PRP using the second data structure, the entry for employing the at least one PRP including the address of the at least one PRP and the security context of 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 references to entries for employing the at least one PRP using a second data structure, thereby modifying the command entry data to enable reading 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: The modified command entry data is transmitted to the NVMe device; A second transaction identifying the shadow from the NVMe device for performing operations on the at least one PRP; and Encryption is performed on the data associated with the shadow of the at least one PRP based on the 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: The shadow of the PRP list (PRPL) using the first data structure is used to generate the command entry data; and The command entry data is modified to enable the reading of the shadow of the PRPL, thereby generating 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 employing the first data structure, the entry for the PRPL employing the first data structure including the address of the PRPL and a security context from the command entry data for the PRPL, to generate the shadow of the PRPL employing the first data structure of the command entry data.

41. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to: The modified command entry data is transmitted to the NVMe device; A second transaction identifying the shadow from the NVMe device for reading the PRPL; Generate a shadow of each PRP of the PRPL using the first data structure; and Each PRP of the PRPL is modified to point to the shadow of each PRP, thereby generating the modified PRPL.

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

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

44. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to modify the address of the PRPL pointer of the PRPL used for the command entry data to point to the shadow of the PRPL, thereby 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 employing the first data structure, the entry for the shadow of each PRP employing the first data structure including an address of each PRP of the PRPL from the PRPL and a security context of each PRP from a second data structure to generate the shadow of the PRPL employing the first data structure for the command entry data.

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

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

48. The computing device of claim 39, wherein the NVMe inline cryptographic module is further configured to remove references to entries for employing the second data structure of the PRPL, thereby modifying the command entry data to enable reading of the shadow of the PRPL.

49. The computing device according to claim 39, wherein: The command entry data includes references to entries employing a second data structure, wherein the entries employing the second data structure have a security context for the PRPL; and The NVMe inline cryptographic module is also configured to write the PRPL pointer into the second data structure at a location associated with the reference to the entry employing the second data structure.

50. The computing device according to claim 32, wherein: The modified command entry data includes virtual addresses; and The NVMe inline cryptographic module is also configured to obtain the virtual address-to-physical address mapping for the virtual address in parallel with the shadow of the at least one PRP that generates the command entry data using the first data structure.

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

52. A computing device, the computing device comprising: Non-volatile memory fast (NVMe) inline cryptographic module; and A processing system coupled to the NVMe inline cryptographic module, the processing system being configured to: The cryptographic key slot for the command is obtained from the secure process, the cryptographic key slot including a cryptographic key slot reference; Enable the password by writing it into the command entry used for submitting to the queue; Write the password key slot reference into the command entry for the submission queue of the command; as well as Submit the command entry containing the password enable and the password key slot reference to the submission queue.

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

54. The computing device according to claim 52, wherein: The command has more than one page-level read / write pointer (PRP); and The processing system is also configured to: Write the logical block address offset into at least one portion of the PRP of the command entry for the submission queue; and The command entry comprising the cipher enable, the cipher key slot reference, and the at least one PRP having the logical block offset is submitted to the submission queue.

55. The computing device according to claim 52, wherein: The command contains data larger than two system storage pages; and The processing system is also configured to write logical block address offsets into at least one part of a PRP (PRP list).

56. The computing device according to claim 52, wherein: The command contains data larger than two system storage pages; and The processing system is also configured to: Write the PRPL pointer to the command entry for the submission queue at the location designated for the PRP; and Submit the command entry containing the password enable, the password key slot reference, and the PRPL pointer to submit the command entry containing the password enable and the password key slot reference to the submission queue.

57. The computing device according to claim 52, wherein: The data in the command is greater than the number of system storage pages that can be referenced by PRP and PRPL; and The processing system is also configured to write the PRPL pointer to the PRPL's PRP.

58. The computing device of claim 52, wherein the processing system is further configured to: Configure the first set of one or more registers corresponding to multiple command submission queues of the inline cryptographic module; and Each register in the first group of one or more registers is set using the address range of different command submission queues in the command submission queue.

59. The computing device of claim 58, wherein the processing system is further configured to set each register in the first group of one or more registers using the starting address and size of different command submission queues in the command submission queue, and to set each register in the first group of one or more registers using the address range of different command submission queues in the command submission queue.

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

61. The computing device of claim 58, wherein the processing system is further configured to: Configure the second set of one or more registers of the inline cryptographic module corresponding to multiple command completion queues; and Each register in the second group of one or more registers is set using the starting address and size of different command submission queues in the command submission queue.

62. The computing device of claim 58, wherein the processing system is further configured to: Configure the second set of one or more registers of the inline cryptographic module corresponding to multiple exclusive address ranges; and Each register in the second group of one or more registers is set using the starting address and size of different exclusive address ranges within the exclusive address range.

Images