SOMBREAMENTO AUTOMÁTICO PARA CRIPTOGRAFIA EM LINHA DE MEMÓRIA EXPRESSA NÃO VOLÁTIL (NVME)

BR112025018968A2Pending Publication Date: 2026-08-04QUALCOMM INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
BR112025018968
Authority / Receiving Office
BR · BR
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-05-10
Filing Date
2024-01-05
Publication Date
2026-08-04

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

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

Description

1 / 80 Automatic Shading for Non-Volatile Express Memory (NVMe) In-Line Cryptography RELATED DEPOSIT REQUESTS

[0001] This application claims the benefit of priority from patent application IN No. 202341018627 entitled AUTOMATIC SHADOWING FOR NONVOLATILE MEMORY EXPRESS (NVME) INLINE ENCRYPTION, filed on March 18, 2023, and from patent application IN No. 202341032985 entitled AUTOMATIC SHADOWING FOR NONVOLATILE MEMORY EXPRESS (NVME) INLINE ENCRYPTION, filed on May 10, 2023, the contents of which are incorporated herein by reference for all purposes. BACKGROUND

[0002] Nonvolatile memory express (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 express (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 leverage the low latency and high processing capacity of modern SSDs, which can read and write data much faster than traditional hard disk drives (HDDs).NVMe can also support attributes such as multiple input / output (I / O) queues and parallelism, which can enable it to offer much faster random read and write performance than traditional storage interfaces. As a result, NVMe drives are becoming increasingly popular in high-performance computing, data centers, and consumer devices that require fast access to data. Petition 870250079875, dated 05 / 09 / 2025, pages 533 / 684 2 / 80 storage, such as gaming PCs and laptops. SUMMARY

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

[0004] Several aspects include methods of providing cryptographic functions for data in non-volatile memory-expressed protocol (NVMe) by an inline cryptographic module of a processing system that may include identifying a first transaction of an NVMe device to read a command input from a command send queue, reading command input data from the command input, generating a shadow of at least one page-level read / write pointer (PRP) of the command input data in a first data structure, and modifying the command input data to enable reading the shadow of at least one PRP, thereby generating modified command input data. Petition 870250079875, dated 05 / 09 / 2025, pages 534 / 684 3 / 80

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

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

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

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

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

[0010] Some aspects may additionally include sending the modified command input data to the NVMe device, identifying a second Petition 870250079875, dated 05 / 09 / 2025, pp. 535 / 684 4 / 80 NVMe device transaction to perform an operation on the shadow of at least one PRP and implement a cryptographic operation on data associated with the shadow of at least one PRP based on a security context associated with the shadow of at least one PRP.

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

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

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

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

[0015] Some aspects may additionally include sending the modified PRPL to the NVMe device, identifying a third transaction on the NVMe device to perform an operation on at least one of the shadows of each PRP, and implementing a cryptographic operation on data associated with at least one Petition 870250079875, dated 05 / 09 / 2025, pages 536 / 684 5 / 80 of the shadows of each PRP based on the security context associated with at least one of the shadows of each PRP.

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

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

[0018] Some aspects may additionally include sending the modified command input data to the NVMe device, identifying a second NVMe device transaction to read the PRPL in which generating the shadow PRPL of the command input data in the first data structure occurs in response to the identification of the second NVMe device transaction, and modifying each PRP of the PRPL to point to the shadow of each PRP, thus generating a modified PRPL.

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

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

[0021] In some respects, command input data includes a Petition 870250079875, dated 05 / 09 / 2025, pages 537 / 684 6 / 80 reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL. Some aspects may additionally include writing the PRPL pointer in the second data structure in a location associated with the reference to the entry in the second data structure.

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

[0023] In some respects, identifying the first NVMe device transaction to read command input from the command send queue may involve identifying a transaction address that is within at least one range of addresses for at least one send queue, to at least one range of addresses stored in an inline cryptographic module configuration register.

[0024] Several aspects include methods of providing cryptographic functions for data in non-volatile express memory (NVMe) protocol executed by a processing system, may include acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference, writing a cryptographic enablement for a command input from the command to a send queue, writing the cryptographic key slot reference for the command input from the command to the send queue, and sending the command input from the command with the cryptographic enablement and the cryptographic key slot reference to the send queue.

[0025] Some aspects may additionally include acquiring a page-level read / write pointer lookup table (PRPLT) slot for an inline cryptographic module command, the PRPLT slot including a PRPLT slot reference. Petition 870250079875, dated 05 / 09 / 2025, pages 538 / 684 7 / 80 and the recording of the PRPLT slot reference for the command input to the send queue, in which sending the command input with cryptographic enablement and cryptographic key slot reference to the send queue may include submitting the command input including cryptographic enablement, cryptographic key slot reference, and PRPLT slot reference to the send queue.

[0026] In some respects, the command has more than one page-level read / write pointer (PRP). Some respects may additionally include writing a logical block address offset to part of at least one PRP of the command input to the send queue and sending the command input with the cryptographic enable and cryptographic key slot reference to the send queue may include sending the command input including the cryptographic enable, the cryptographic key slot reference and at least one PRP with the logical block offset.

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

[0028] In some respects, the command data is larger than two system memory pages. Some respects may additionally include writing a PRPL pointer to the command input to the send queue in a location for a PRP and sending the command input with the cryptographic enable and cryptographic key slot reference to the send queue may include sending the command input with the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

[0029] In some respects, the command data is larger than the number of system memory pages that can be referenced by a PRP and a PRPL. Some respects may additionally include writing a pointer. Petition 870250079875, dated 05 / 09 / 2025, pages 539 / 684 8 / 80 of PRPL for a PRP of a PRPL.

[0030] Some aspects may additionally include configuring a first set of one or more records of an inline cryptographic module corresponding to a number of command sending queues and defining each of the first set of one or more records with a range of addresses from a different command sending queue.

[0031] In some respects, the definition of each of the first set of one or more records with the address range of a different command sending queue may include the definition of each of the first set of one or more records with a starting address and a size of a command sending queue different from the command sending queues.

[0032] In some respects, the definition of each of the first set of one or more records with the address range of a different command sending queue may include the definition of each of the first set of one or more records with a starting address and an ending address of a different command sending queue.

[0033] Some aspects may additionally include configuring a second set of one or more records of the cryptographic module in line corresponding to a number of command completion queues and defining each record of the second set of one or more records with a different starting address and command sending queue size.

[0034] Some aspects may additionally include the configuration of a second set of one or more records of the cryptographic module in line corresponding to a number of unique address ranges, and the definition of each record of the second set of one or more records with a starting address and a size of a unique address range different from the unique address ranges.

[0035] Additional aspects include computing devices that include a non-volatile Express Memory (NVMe) inline cryptographic module configured Petition 870250079875, dated 05 / 09 / 2025, pages 540 / 684 9 / 80 to perform operations of any of the methods summarized above. Additional aspects include computing devices that include a processing system configured to perform the operations of any of the methods summarized above. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The attached drawings, which are incorporated in the present invention and form part of this descriptive report, illustrate examples of embodiments of various claims and, together with the general description given above and the detailed description given below, serve to explain the attributes of the claims.

[0037] Figure 1 is a component block diagram illustrating an example computing device suitable for use with various modalities.

[0038] Figure 2 is a component block diagram illustrating an example non-volatile in-line cryptographic express memory (NVMe) system suitable for implementing various modalities.

[0039] Figure 3 is a component block diagram illustrating an example online cryptographic module for implementing various modalities.

[0040] Figure 4 is a component block diagram illustrating a sample NVMe system that does not include cryptography support.

[0041] Figure 5 is a component block diagram illustrating a sample NVMe system that includes cryptographic support according to some modalities.

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

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

[0044] Figures 8 to 17 are component block diagrams that illustrate various information structures and operations in computer systems. Petition 870250079875, dated 05 / 09 / 2025, pp. 541 / 684 10 / 80 configured to implement various modes.

[0045] Figure 18 is a component block diagram illustrating an example online cryptographic module for implementing various modalities.

[0046] Figure 19 is an information structure diagram that illustrates a common example command format for sending commands in computing systems configured to implement multiple modalities.

[0047] Figure 20 is an information structure diagram that illustrates an example lookup table in computer systems configured to implement various modalities.

[0048] Figure 21 is a component block and process flow diagram that illustrates a method for implementing an initialization phase for NVMe online cryptographic processes using physical region page shading or page-level read / write pointers (PRPs) on computing systems configured to implement various modalities.

[0049] Figure 22 is a component block and process flow diagram that illustrates a method for implementing a command creation stage for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0050] Figures 23A and 23B are component block and process flow diagrams that illustrate methods for implementing command processes for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0051] Figure 24 is an information structure diagram that illustrates a common example command format for sending commands in computing systems configured to implement multiple modalities.

[0052] Figure 25 is an information structure diagram that illustrates an example lookup table in computer systems configured to implement various modalities.

[0053] Figure 26 is a component block and flow diagram of Petition 870250079875, dated 05 / 09 / 2025, pages 542 / 684 11 / 80 processes that illustrates a method for implementing command processes for online NVMe cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0054] Figure 27 is an information structure diagram that illustrates an example of modifying a list of PRPs in computing systems configured to implement multiple modalities.

[0055] Figure 28 is an information structure diagram that illustrates an example lookup table in computer systems configured to implement various modalities.

[0056] Figure 29 is a component block and process flow diagram that illustrates a method for implementing write command processes for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0057] Figure 30 is a component block and process flow diagram that illustrates a method for implementing read command processes for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0058] Figure 31 is a component block and process flow diagram that illustrates a method for command completion for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.

[0059] Figures 32A and 32B are component blocks and process flow diagrams that illustrate a method for command processes using the Peripheral Component Interconnect Express (PCIe) address translation service for NVMe inline cryptographic processes using PRPs on computing systems configured to implement multiple modalities.

[0060] Figure 33 is a component block diagram illustrating an example mobile computing device suitable for use with various Petition 870250079875, dated 05 / 09 / 2025, pages 543 / 684 12 / 80 modalities.

[0061] Figure 34 is a component block diagram illustrating an example mobile computing device suitable for use with various modalities.

[0062] Figure 35 is a component block diagram illustrating an example server suitable for use with various modes. DETAILED DESCRIPTION

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

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

[0065] The terms computing device and mobile device are used interchangeably in the present invention to refer to any or all mobile phones, smartphones, personal or mobile multimedia players, Petition 870250079875, dated 05 / 09 / 2025, pages 544 / 684 13 / 80 Personal data assistants (PDAs), laptop computers, tablet computers, convertible laptops / tablets (2-in-1 computers), smartbooks, ultrabooks, netbooks, palmtop computers, wireless email receivers, multimedia internet-enabled mobile phones, mobile game consoles, wireless game controllers, and similar personal electronic devices that include programmable memory and a processor. The term computing device may additionally refer to stationary computing devices, including personal computers, desktop computers, all-in-one computers, workstations, supercomputers, mainframe computers, embedded computers, servers, home theater computers, and game consoles.

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

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

[0068] The NVMe protocol for memory devices enables a Petition 870250079875, dated 05 / 09 / 2025, pages 545 / 684 14 / 80 fast, high-capacity communication between an NVMe memory device and a processing system. A Peripheral Component Express (PCIe) interface controller can be configured to implement NVMe protocol communications between an NVMe device and components of a processing system.

[0069] Currently, there is strong market demand for online cryptography. NVMe can provide hardware-based encryption of data stored on NVMe-based solid-state drives (SSDs). Inline encryption means that the encryption process happens automatically as data is written to the SSD, without any additional software or hardware intervention. This provides a high level of security without any significant impact on performance. 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 on the SSD controller and are not exposed to the host system. This can provide an additional layer of protection against data breaches. Additionally, NVMe inline encryption can provide end-to-end data encryption so that data is encrypted from the moment it leaves the host system until it is decrypted by the SSD controller.This can help protect data against unauthorized access or theft, both during transfer and during storage on the SSD.

[0070] There are many challenges with implementing online cryptography. NVMe. For example, there is currently no standard way to encrypt data being accessed and stored on an inline NVMe device, with the encryption process occurring simultaneously with data storage and access. Currently, one must lobby to change NVMe specifications, impose impractical restrictions on device drivers, or bear the heavy silicon cost of maintaining a large number of descriptors to use inline encryption with an NVMe device. Changing the Petition 870250079875, dated 05 / 09 / 2025, pages 546 / 684 The 15 / 80 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 lead to compatibility issues.

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

[0072] Modalities can eliminate the need for the expensive silicon cost associated with accessing descriptors. As mentioned above, some modalities can automatically shade all active PRPs within the NVMe device, maintain 32 address ranges in registers that are associated with send queues and programmed by device drivers during initialization, and the NVMe device accessing one of these 32 address ranges can indicate that it is attempting to read commands from the send queue (SQ). The returned data can be used to extract PRPs used to determine the data that should be encrypted.

[0073] By maintaining only 32 address ranges for sending queue records, all PRPs can be shaded within the NVMe device and simplify the lookup logic for identifying incoming user data buffer accesses. Petition 870250079875, dated 05 / 09 / 2025, pages 547 / 684 16 / 80 Another benefit or advantage of the modalities is that the complex search logic of finding PRPs from 4 million possibilities is reduced to just 32 ranges, which can be efficiently implemented in hardware. Yet another advantage of the modalities is that they can significantly reduce the SRAM volume to 8 KB (while conventional solutions may require 4 MB of SRAM with complex search logic beforehand). For these and other reasons, the various modalities can significantly reduce costs. The modalities can enable access to inline cryptography without sacrificing cost or system performance when using an NVMe device.

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

[0075] The term system-on-chip (SoC) is used in the present invention to refer to an assembly of interconnected electronic circuits typically, but not exclusively, including a processing device, a memory, and a communication interface. A processing system 12 may include a variety of different types of processors 14, some of which may include multiple processor cores. Non-limiting examples of processors that may be included in a computing device 10 and implemented in, or coupled to, a processing system 12 include: a Petition 870250079875, dated 05 / 09 / 2025, pages 548 / 684 17 / 80 general-purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a secure processing unit (SPU), a neural network processing unit (NPU), a subsystem processor for specific computing device components, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, a multi-core processor, a controller, and a microcontroller.A processing system 12 may additionally incorporate other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), another programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, surveillance hardware, and timing references. Integrated circuits may be configured so that the integrated circuit components reside on a single piece of semiconductor material, which may be called a system on a chip (SoC).

[0076] The processing system 12 may be implemented in a SoC and / or may include a set of circuits on multiple chips coupled to a SoC. The computing device 10 may include more than one processing system 12, thus increasing the number of processors 14, any one or more of which may include multiple processor cores. The computing device 10 may also include other processors (not shown) that are not associated with the processing system 12. The processors 14 may be configured for specific purposes that may be the same as or different from other processors 14 of the computing device 10. One or more of the processors 14 and processor cores of the same or different configurations. Petition 870250079875, dated 05 / 09 / 2025, pages 549 / 684 18 / 80 can be grouped together.

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

[0078] The computing device 10 may include any number and combination of memories, such as memory 16 integral to the processing system 12 and memory 36 separate from the processing system 12. Any of the memories 16, 36 may be volatile or non-volatile memory configured to store processor-executable data and code for access by the processor 14. The 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 memories, 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.

[0079] Memories 16, 36 can be configured to temporarily store a limited amount of data. For example, the data can be received from a sensor or data subsystem. As another example, the data can be processor-executable code data and / or instructions that are Petition 870250079875, dated 05 / 09 / 2025, pages 550 / 684 19 / 80 requested from non-volatile memory 16, 24, 36 loaded into memories 16, 36 from non-volatile memory 16, 24, 36 in anticipation of future access based on a variety of factors. As another example, the data may be intermediate processing data and / or executable code instructions produced by processor 14 and temporarily stored for future fast access without being stored in non-volatile memory 16, 24, 36.

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

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

[0082] The inline cryptographic module 38 can be configured to implement cryptographic functions, such as encryption and decryption, of data for transactions from the memory storage device 24. The data Petition 870250079875, dated 05 / 09 / 2025, pages 551 / 684 20 / 80 transmitted between memory 36 and storage memory 24 can be encrypted and decrypted by the inline cryptographic module 38 to protect the stored data and the memory storage device 24 by encrypting the data and making the encrypted data retrieved from the memory storage device 24 usable by the SoC by decrypting the data. The inline cryptographic module 38 can be configured to implement hash generation and validation for device hints related to the data transmitted between memory 36 and storage memory 24 to assess the integrity of the device hints for use in evaluating whether to use the data.

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

[0084] A clock controller 30 can be configured to control clock signals transmitted to the processing system components 12. For example, the clock controller 30 can block a processing system component 12 by disconnecting the processing system component 12 from a clock signal and can unblock the processing system component 12 by connecting the processing system component 12 to the clock signal.

[0085] Interconnection 32 can be a communication fabric, like a Petition 870250079875, dated 05 / 09 / 2025, pages 552 / 684 21 / 80 communication bus, configured to communicatively connect the components of the processing system 12. The interconnection 32 can transmit signals between the components of the processing system 12. In some embodiments, the interconnection 32 can be configured to control signals between the components of the processing system 12 by controlling the timing and / or transmission paths of the signals.

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

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

[0088] The 202 processing system, which can be implemented as a A SoC may include one or more processors 14, a Peripheral Component Express (PCIe) interface controller 212 (e.g., storage memory interface 20 in Figure 1), and an in-line cryptographic module 38 connected to each other by various communication buses. The one or more processors 14 may be configured to implement software, such as applications 204, including a high-level operating system, a core 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 may manage communication between the processing system components 202, including the cryptographic module. Petition 870250079875, dated 05 / 09 / 2025, pages 553 / 684 22 / 80 in line 38 and the NVMe device 214. Such communications may include communications for preparing and implementing NVMe commands from one or more processors 14 for data transactions, such as read and / or write transactions, on the NVMe device 214.

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

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

[0091] The inline cryptographic module 38 can also support secure key management. In some instances, the inline cryptographic module 38 can operate independently of PCIe frameworks and their different configurations. Petition 870250079875, dated 05 / 09 / 2025, pages 554 / 684 23 / 80 layers, enabling scalable storage processing capability and being compatible with NVMe device protocols. In other examples, the inline cryptographic module 38 may be part of the PCIe 212 controller. The inline cryptographic module 38 is described further in the present invention.

[0092] Figure 3 illustrates an example of the inline cryptographic module 38 for implementing various embodiments. With reference to Figures 1 to 3, the inline cryptographic module 38 can be configured with a buffer address lookup structure 300, a security context structure 302, an encryption module 304, and a decryption module 306. The encryption module 304 and the decryption module 306 are described in the present invention as separate components for ease of explanation and clarity consistent with a non-limiting embodiment. However, these separate descriptions are not intended to limit the scope of the claims and descriptive report, and in some implementations and embodiments, the encryption module 304 and the decryption module 306 can be implemented as a single combined module.

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

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

[0095] The NVMe security ID can be a combination of data, such as an NVMe command submission queue identifier and an NVMe command identifier for the NVMe command. The NVMe command submission queue identifier Petition 870250079875, dated 05 / 09 / 2025, pages 555 / 684 24 / 80 can identify an NVMe command submission queue in which the NVMe 208 driver can write the NVMe command.

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

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

[0098] The 302 security context structure can be a data structure, such as a table, array, linked list, graph, etc., configured to store various data in association with each other. For example, the 302 security context structure might store NVMe security ID data and a security context for the NVMe command in association with each other. The NVMe security ID in the 300 buffer address query structure and the 302 security context structure for the same NVMe command might be the same. The security context might include a combination of security-related information, such as an encryption algorithm, one or more encryption key slots to retrieve one or more encryption keys from an encryption key storage structure, etc. In some examples, the security context might be provided by an application running by Petition 870250079875, dated 05 / 09 / 2025, pages 556 / 684 25 / 80 processor 14 of the execution from which the NVMe command originates. The 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.

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

[0100] In some embodiments, the inline cryptographic module 38 may configure the buffer address query structure 300 and the security context structure 302 in the inline cryptographic module 38 in response to receiving an NVMe command from the NVMe driver. The inline cryptographic module 38 may process the NVMe command, extracting the data to populate the buffer address query structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data as the buffer address query structure 300 and the security context structure 302. The Petition 870250079875, dated 05 / 09 / 2025, pages 557 / 684 By configuring the 300 buffer address lookup structure and the 302 security context structure, instead of the NVMe driver, the 26 / 80 inline cryptographic module 38 eliminates the previously described address redundancy problem and maintains data integrity. Furthermore, the software overhead for configuring the 300 buffer address lookup structure in the inline cryptographic module 38 is reduced.

[0101] The inline cryptographic module 38 can be configured to forward a configured bell signal to indicate to an NVMe device (e.g., storage memory 24 in Figure 1, NVMe device 214 in Figure 2) a pending NVMe command. For example, the inline cryptographic module 38 can update an endpoint in the NVMe command sending queue to a bell record from the NVMe device. Forwarding the bell signal can enable bypassing or disabling the software configured to record two bells and can ensure that the operation of cryptographic module 38 and the NVMe device are synchronized.

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

[0103] Use the retrieved information, such as sector displacement and / or security context, the 304 encryption module and / or the module of Petition 870250079875, dated 05 / 09 / 2025, pages 558 / 684 27 / 80 decryption 306 can implement the cryptographic function for the NVMe transaction data. For example, the retrieved information may include the security context of the security context framework 302, which may include an encryption algorithm, one or more encryption key slots to retrieve one or more encryption keys from an encryption key storage framework, etc. The encryption module 304 can use the retrieved information from the security context to encrypt the data to be sent to the NVMe device for the NVMe transaction. The decryption module 306 can use the retrieved information from the security context to decrypt the data received from the NVMe device for the NVMe transaction.

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

[0105] Figures 4 and 5 illustrate systems suitable for NVMe transactions without implementing NVMe inline encryption in Figure 4 and implementing NVMe inline encryption in Figure 5, which may include a new encryption layer that is Petition 870250079875, dated 05 / 09 / 2025, pages 559 / 684 28 / 80 placed inline in the NVMe transaction flow. NVMe inline encryption can provide data confidentiality while maintaining end-to-end performance and low latency. The encryption layer can be deployed on the device side and configured to handle NVMe command processing and completion, leveraging its proximity to the device controller.

[0106] With reference to Figures 1 to 4, Figure 4 illustrates an example in which command sending includes: (1) an NVMe device driver (e.g., NVMe driver 208 in Figure 2) on a host 400 (e.g., processing system 12 in Figure 1, processor 14 in Figures 1 and 2, processing system 202 in Figure 2) that writes commands to a send queue (SQ) 404 in a host memory 402 (e.g., memory 16, 36 in Figure 1); and (2) the NVMe device driver (e.g., NVMe driver 208 in Figure 2) on host 400 that writes an updated SQ tail pointer (ptr) (tail in Figure 4) to a 408 buzzer (SQ tail buzzer in Figure 4) (e.g., a buzzer record) on NVMe device 214. Command processing may include: (3) the NVMe device fetch commands from SQ 404 and the NVMe device that update the SQ head ptr (head in Figure 4) with a next command; and (4) the NVMe device that processes the fetched commands.The completion of the command may include: (5) the NVMe device 214 updating the completion (or command or command completion) queue tail (CQ) ptr (tail in Figure 4) and writing the updated CQ tail ptr to the buzzer; (6) the NVMe device 214 generating a CQ platform-specific interrupt, such as an MSIX interrupt, to notify a host driver of the completion status; (7) the NVME device driver on host 400 processing the completion of the command; and (8) the NVME device driver on host 400 writing a CQ head ptr (head in Figure 4) to a buzzer 410 (CQ head buzzer in Figure 4) (e.g., a buzzer register) on the NVMe device controller 214.

[0107] With reference to Figures 1 to 5, in the example illustrated in Figure 5, the host memory 402 (e.g., memory 16 in Figure 1, memory 36 in Figures Petition 870250079875, dated 05 / 09 / 2025, pages 560 / 684 29 / 80 and 2) includes an NVMe-ICE 500 module (e.g., inline cryptographic module 38 in Figures 1 to 3), which can be an encryption / decryption layer between the host driver and the NVMe device controller 214. Command sending operations may include: (1) the NVMe device driver (e.g., NVMe driver 208 in Figure 2) on host 400 (e.g., processing system 12 in Figure 1, processor 14 in Figures 1 and 2, processing system 202 in Figure 2) writing commands to the send queue (SQ) 404 in host memory 402; (2) the NVMe device driver on host 400 configuring the NVMe-ICE 500 module for inline encryption of NVMe transactions; and (3) the NVMe device driver on host 400 that writes an SQ ptr tail (tail in Figure 5) to buzzer 408 (SQ tail buzzer in Figure 5) (e.g., a buzzer record) to NVMe device controller 214.Command processing operations may include: (4) the NVMe 214 device controller fetching a command from the SQ 404 and updating the SQ ptr head (head in Figure 5) with a next command; (5) the NVMe 214 device controller processing the command and / or the updated SQ ptr head; and (6) the NVMe-ICE 500 module encrypting / decrypting the data for the command. For example, the NVMe-ICE 500 module may encrypt write data sent to the NVMe 214 device controller for a write command and / or decrypt read data received from the NVMe 214 device controller for a read command.Command completion operations may include: (7) the NVMe device controller 214 writing command completion to completion queue (CQ) 406 in host memory 402 and updating the CQ tail ptr (tail in Figure 5) on the buzzer; (8) the NVMe device controller 214 generating a CQ platform-specific interrupt, such as an MSI-X interrupt, to notify the host driver of the completion status; (9) host 400 processing command completion; and (10) host 400 writing the CQ head ptr (head in Figure 5) to buzzer 410 (CQ head buzzer in Figure 5) (e.g., a buzzer register) on the NVMe device controller 214. Petition 870250079875, dated 05 / 09 / 2025, pages 561 / 684 30 / 80

[0108] SQ 404 and CQ 406 are used to manage communications 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 NVMe standard command, such as read, write, manage commands, etc. CQ 406 can be used by NVMe device 214 to notify host 400 of the completion status of the command processed from SQ 404, such as successful completion or completion failure. When a command is executed, the NVMe device controller 214 can place a completion entry in CQ 406 to inform host 400 about the completion of the operation. SQ 404 and CQ 406 can be buffers, circular arrays, etc. for which locations can be statically or dynamically indicated as an initial location (head) and an final location (tail).An entry in the head of the SQ 404 might be for an upcoming command to be implemented, and an entry in the tail of the SQ 404 might be for a final command to be implemented. An entry in the head of the CQ 404 might be for an older completed command, and an entry in the tail of the CQ 404 might be for a more recently completed command. The SQ 404 and CQ 406 can be scaled to store at least two entries, including thousands of entries, such as 64,000 entries.

[0109] The NVMe-ICE 500 module can provide data security and privacy at the storage level by enabling encryption of data sent from the 400 host to the NVMe 214 device. This can be achieved by inserting a layer of encryption between the 400 host and the NVMe 214 device, which allows each issued command to be processed as an encrypted command before being passed to the NVMe 214 device controller for further processing. When a command is written by the host driver and queued in the 404 send queue (SQ), it can first be captured by the NVMe-ICE 500 module for encryption / decryption before being passed to the NVMe 214 device controller for further processing. The controller Petition 870250079875, dated 05 / 09 / 2025, pages 562 / 684 NVMe 214 device controller 31 / 80 can then process the command and update the SQ head pointer before passing it back to the NVME-ICE 500 module for decryption or encryption, as appropriate. The NVMe 214 device controller can then write information to a completion queue (CQ) and generate an MSI-X interrupt for the host driver.

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

[0111] With reference to Figures 1 to 6, Figure 6 illustrates a processing system 600 (e.g., processing system 12 in Figure 1, processing system 202 in Figure 2, host 400 in Figure 5), which can be implemented as a SoC, including a system memory space 602 (e.g., memory 16 in Figure 1, memory 36 in Figures 1 and 2, host memory 402 in Figure 5), a network-on-chip (NOC) 604, a PCIe root complex 606, and a PCIe link 608 to an NVMe device 214 that includes a completion queue head (CQ) pointer (ptr) 610, a CQ tail ptr 612, a send queue tail (SQ) ptr 614, and an SQ head ptr 616. The system memory space may include a completion queue (CQ) of 618, a shipping queue Petition 870250079875, dated 05 / 09 / 2025, pages 563 / 684 32 / 80 (SQ) 620 and a page-level read / write pointer list (PRPL) 622.

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

[0113] Figure 7 illustrates some of the technical challenges associated with determining which accesses (e.g., SQ, CQ, PRPL, I / O access, etc.) need encryption to securely transfer data from an NVMe device. With reference to Figures 1 to 7, NVMe devices (e.g., storage memory 24 in Figure 1, NVMe device 214 in Figures 2, 5, and 6) use SQ, CQ, PRPL, and I / O access for various data transfer activities. The four main access types in the NVMe processing system illustrated in Figure 7 are write address, read address, write data, and read data. As a non-limiting example, various types of access using Advanced Extensible Interface (AXI) protocols may include AXI write address (AWADDR), AXI read address (ARADDR), AXI write data (WDATA), and AXI read data (RDATA).Figure 7 also illustrates that SQ access for command lookup should not be encrypted, CQ access for completion input should not be encrypted, PRPL access for descriptor lookup should not be encrypted, but I / O access with user data transfer should be encrypted. Petition 870250079875, dated 05 / 09 / 2025, pages 564 / 684 33 / 80

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

[0115] Thus, after matching, the system can decide which access needs encryption. The system can be configured so that any access with matching addresses in the SQ, CQ, and PRPL tables is a control or status-related data that does not need to be encrypted. On the other hand, the system can determine that any access with matching addresses in the PRP 802 table may need to be encrypted because this may include a transfer of user data. Petition 870250079875, dated 05 / 09 / 2025, pages 565 / 684 34 / 80

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

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

[0118] With reference to Figures 1 to 9, to overcome these and other technical challenges, some modes can trap device accesses and interpret them according to the NVMe specification. The system can analyze each access request to determine if it is legitimate before allowing it to proceed. To achieve this, the system can extract PRPs from each request on the fly. In some modes, registers can be configured with start and end addresses of the send queue in order to identify when a read address is within one of these ranges. This can allow the system to determine which PRPs are cached on the NVMe device.Furthermore, a portion of an NVMe 900 command in Figure 9A, as part of an address field, including a reserved field (RSVD in Figure 9A) and / or another field in the NVMe 900 command, may contain a page-level read / write pointer list (PRPL) index of a 902 command entry. Petition 870250079875, dated 05 / 09 / 2025, pages 566 / 684 35 / 80 Figure 9B (e.g., command 624 in Figure 6). This can provide an accurate shadow of all PRPs that are dynamically cached within the NVMe device.

[0119] Some modes can take advantage of reserved fields in an NVMe command structure to maintain a PRPL index of a command entry, so as to create a shadow of all cached PRPs within the NVMe device. The system can initiate this process by configuring its send queues (SQs) with their base addresses and queue size (Qsize) values, and then performing the same operations for the completion queues (CQs). As a result, the system can queue commands without requiring PRPLs.

[0120] Depending on the amount of user data that needs to be transferred, there may be different processes required to complete a proper transfer. For example, if the user data fits into one or two system memory pages, the security context information may be written to one or two PRP lookup table (PRPLT) locations (N). The system may then proceed with creating the command before pushing the command to an SQ, along with maintaining its mapping {SQ identifier (SQID - SQ identifier), command identifier (CID - command identifier)} -> N or {SQID, CID, namespace identifier (NSID - namespace identifier)} -> N.If the user data requires more than 2 system memory pages, up to a system memory page threshold, however, a PRP can be created for the first system memory page and a PRPL would need to be created for all other system memory pages, so that, for all PRP entries of the PRPL, a logical block offset (LB) is set as 12 bits lower (eb / t[1:0] = 2'b00). If the user data requires more than the system memory page threshold, then multiple chained PRPLs can be created by inserting into the last entry of one PRPL a pointer to the next PRPL entry of another PRPL. The system memory page threshold can be... Petition 870250079875, dated 05 / 09 / 2025, pages 567 / 684 36 / 80 configured based on the system memory page size. In some embodiments, the system memory page threshold may be the system memory page size divided by 8. For example, for a system memory page size of 4 KB, the system memory page threshold may be 512 system memory pages. The system memory page threshold can be similarly configured based on any system memory page size, such as 8 KB, 16 KB, etc.

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

[0122] Figures 10A to 12B illustrate some examples of command structures and PRPL for commands with data that require variable numbers of Petition 870250079875, dated 05 / 09 / 2025, pages 568 / 684 37 / 80 page buffers. With reference to Figures 1 to 12B, the command structures 1000, 1002, 1102, 1202 (e.g., command 624 in Figure 6, e.g., command 902 in Figure 9) can be for commands, such as the commands described above, received from a memory (e.g., memory 16 in Figure 1, memory 36 in Figures 1 and 2, host memory 402 in Figure 5, system memory space 602 in Figure 6), as well as from the SQ (e.g., SQ 404 in Figure 5, send queue 620 in Figure 6) by an NVMe inline cryptographic module (e.g., inline cryptographic module 38 in Figures 1 to 3, NVMe-ICE module 500 in Figure 5). Each of the command structures 1000, 1002, 1102, 1202 can include a PRPLT pointer (or index) to a location (N) in a PRPLT. The PRPL structures 1100, 1200 (e.g., PRPL 622 in Figure 6), like the PRPLs described above, can be referenced by PRPL pointers (e.g., PRPL 628 pointer in Figure 6) from the commands 1102, 1202.

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

[0124] The example illustrated in Figure 10B shows a command structure. 1002 having data that requires two page buffers. In addition to the PRPLT pointer, the 1002 command structure may include a PRP (PRP1) (e.g., PRP 626 in Figure 6) with an association to a location (e.g., location 630 in Figure 6) in memory, such as a page buffer. Furthermore, the 1002 command structure may include another PRP (PRP2) with an association to another location in memory, such as another page buffer. In some embodiments, the other PRP may include an LB offset (Loffsef'). The LB offset is optional and may be used and Petition 870250079875, dated 05 / 09 / 2025, pages 569 / 684 38 / 80 vary in size depending on the page size and the size of the logical block address (LBA) to match the page size.

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

[0126] The examples illustrated in Figures 12A and 12B show a PRPL 1200 structure, which may be representative of multiple PRPL 1200 structures and an associated command structure 1202 having data that requires more than the page buffer threshold of the system memory pages. The PRPL 1200 structure may include at least two PRPs (PRP2, PRP3) (e.g., PRP 626 in Figure 6), up to 510 PRPs, each with an association to a location (e.g., location 630 in Figure 6) in memory, such as a page buffer, respectively. For the PRPL 1200 structure to be insufficient to hold all PRPs, an entry in the PRPL 1200 structure may be a pointer to the next PRPL 1200 structure (ptr to the next PRPL). A final PRPL 1200 structure having a final PRP for the 1202 command structure may delete the pointer to a subsequent PRPL 1200 structure, such as the PRPL 1100 structure.The PRPL 1200 structure can include an LB offset (Loffset1, Loffset2) for each PRP. In addition to the PRPLT pointer, the command structure... Petition 870250079875, dated 05 / 09 / 2025, pages 570 / 684 39 / 80 1202 may include a PRP (PRP1) with an association to a memory location, such as a page buffer. In addition, the 1202 command structure may include a PRPL (PRPL Pointer) with an association to the 1200 PRPL structure.

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

[0128] The information structures may include a PRPLT 1300 SRAM (e.g., memory 16 in Figure 1, memory 36 in Figures 1 and 2, host memory 402 in Figure 5, system memory space 602 in Figure 6, PRPL table 800 in Figure 8) and a look-up table (LUT) 1302 SRAM (e.g. Petition 870250079875, dated 05 / 09 / 2025, pages 571 / 684 40 / 80 example, memory 16 in Figure 1, memory 36 in Figures 1 and 2, host memory 402 in Figure 5, system memory space 602 in Figure 6, PRP table 802 in Figure 8). Information structures may also include command 1000, 1002 (e.g., command 624 in Figure 6), command 1502 (e.g., command 624 in Figure 6, command 1102 in Figure 11B, command 1202 in Figure 12B), modified commands 1304, 1400, 1500, PRPLs 1100, 1200 (e.g., PRPL 622 in Figure 6) and modified PRPLs 1600, 1700.

[0129] Operations may include the operations illustrated in blocks 1310, 1312, 1314, 1316, 1318, 1410, 1412, 1510, 1610, 1612, 1614, 1710, 1712. Blocks numbered similarly can be implemented in a similar way through the examples illustrated in Figures 13 to 17.

[0130] Another technical challenge is how to read and analyze data from a DDR (e.g., memory 16 in Figure 1, memory 36 in Figures 1 and 2) in the shadow of an NVMe device to access it later. The methods can be divided into multiple stages, such as reading the DDR data and analyzing the command structure.

[0131] The first stage may involve reading the data for this access from DDR memory. That is, the first step may include identifying the data requiring access, which includes the physical address of the data, as well as the command structure that defines how this access should be handled. The second stage may involve parsing the 1000, 1002, 1502 command structure and extracting PRP details so that they can be placed in the shadow of an NVMe device. The shadow can be an area within host memory, such as the PRPLT 1300 SRAM and / or the LUT SRAM 1302, where data shares are kept so that they can be easily accessed when needed without having to go through any other processes, such as initializing or accessing another type of file storage system. A shadow item, or shadow of an item, refers to the data of that item within the shadow specifically for that item.To shadow an item means to place the data for that item in the shadow for the item. Additionally, if there is a pointer to PRPL (for example, pointer to PRPL)... Petition 870250079875, dated 05 / 09 / 2025, pages 572 / 684 41 / 80 628 in Figure 6) within command 1502, so it must be cached in a small temporary storage, such as the PRPLT 1300 SRAM and / or the LUT SRAM 1302, before being sent to the final destination (the NVMe device).

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

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

[0134] In block 1410, the system can search for a free location in a LUT (for example, in LUT SRAM 1302) to insert relevant PRP1 details with a recalculated LBA and / or the NSID to which the buffer is mapped. The system can delete the Petition 870250079875, dated 05 / 09 / 2025, pp. 573 / 684 42 / 80 pointer related to the PRPLT of command 1002 and make it reserved (RSVD) in block 1316 and send the modified command 1400 towards its destination, the NVMe device, in block 1318. These operations can ensure that the information present within the shadow matches the information stored on the NVMe device (for example, the shadow includes the same PRPs as the NVMe device).

[0135] As an example, as illustrated in Figure 15, if the system receives a command (CMD) 1502 with a PRP (e.g., PRP 626 in Figure 6), PRP1, and a pointer to a PRPL (e.g., pointer to PRPL 628 in Figure 6), Pointer to PRPL, which are valid, then in block 1310, the system could use a PRPLT index field from a command 1502 to read PRPLT[N], a location in the SRAM of PRPLT 1300, which may contain a Logical Start Block Address (SLBA) and / or a namespace identifier (NSID) for the command 1502. In block 1410, the system can look for a free location in a LUT (e.g., in the LUT SRAM 1302) to insert relevant PRP1 details with a recalculated LBA and / or the NSID to which the buffer is mapped. In block 1510, the system can transfer the PRPL pointer from command 1502 to the PRPLT [N] location in the PRPLT 1300 SRAM.The system can delete the pointer related to PRPLT from command 1502 and reserve it (RSVD) in block 1316, and send the modified command 1500 towards its destination, the NVMe device, in block 1318. These operations can ensure that the information present within the shadow matches the information stored on the NVMe device (for example, the shadow includes the same PRP and PRPL pointer as the NVMe device).

[0136] Continuing from the example illustrated in Figure 15, in the example illustrated in Figure 16, a PRPL 1100 can be associated with the PRPL pointer (e.g., PRPL pointer 628 in Figure 6) of command 1502 that was written to the SRAM of PRPL 1300. Each input data entry for command 1502 can be a PRP (e.g., PRP 626 in Figure 6) of PRPL 1100. In block 1610, the system can find a free location in the LUT (e.g., in the LUT SRAM). Petition 870250079875, dated 05 / 09 / 2025, pages 574 / 684 43 / 80 1302) for each PRP of PRPL 1100 and insert that PRP into that LUT location, with a recalculated LBA and / or a namespace identifier (NSID) to which the buffer is mapped. The system can delete a logical block offset (Loffset1, Loffset2, Loffset3) for each PRP of PRPL 1100 in block 1612, such as overwriting the Loffset with zeros, and send the modified PRPL 1600 towards its destination, the NVMe device, in block 1614. These operations can ensure that the information present within the shadow matches the information stored on the NVMe device (e.g., the shadow includes the same PRPs as the NVMe device).

[0137] Continuing from the examples illustrated in Figure 15, in the example illustrated in Figure 17, a PRPL 1200 can be associated with the PRPL pointer (e.g., PRPL pointer 628 in Figure 6) of command 1502 that was written to the SRAM of PRPL 1300 and contain a pointer to a subsequent PRPL. Each input data entry, except the last entry, for command 1502 can be a PRP (e.g., PRP 626 in Figure 6) of PRPL 1200. The last entry can be the pointer to a subsequent PRPL. In block 1710, the system can find a free location in the LUT (e.g., in the LUT SRAM 1302) for each PRP of PRPL 1200 and insert that PRP into that LUT location, with a recalculated LBA and / or a namespace identifier (NSID) to which the buffer is mapped.

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

[0139] In some modalities, the pointer to the next PRPL in the PRPL 1200 and recorded in the PRPLT [N] location in the SRAM of PRPLT 1300 can point to another PRPL 1200 and the example illustrated in Figure 17 can repeat the implementation. Such repetitions can occur for each subsequent PRPL 1200. In some Petition 870250079875, dated 05 / 09 / 2025, pages 575 / 684 In modes 44 / 80, the pointer to a next PRPL in PRPL 1200 and stored in the PRPLT [N] location in the SRAM of PRPLT 1300 can point to a PRPL 1100, and the example illustrated in Figure 16 can be implemented. This implementation can occur after one or more implementations of the example illustrated in Figure 17. These operations can ensure that the information present within the shadow matches the information stored in the NVMe device (for example, the shadow includes the same PRPs as the NVMe device).

[0140] Thus, some modes can trap device accesses, interpret them according to the NVMe specification, and extract PRPs from them in real time. Some modes can maintain 32 address ranges in registers for 32 send queues. In some modes, the NVMe device driver (e.g., NVMe driver 208 in Figure 2) can configure these registers with the starting and ending SQ addresses. When the NVMe device sends a read address in any of these ranges, the system can determine that it is to read commands from that SQ (e.g., SQ 404 in Figure 5).

[0141] Some models may reuse a reserved field in NVMe. CMD, which contains the PRPLT index of the command entry. As such, the system can now have 100% true shadow of all PRPs, which are dynamically cached within the NVMe device.

[0142] In some modes, the NVMe driver can configure the SQ table with Base address and Qsize. In some modes, the NVMe driver can configure the CQ table with Base address and Qsize.

[0143] In some embodiments, the NVMe driver can queue a command so that no PRPL is required. The computing system can acquire a free NVMe ICE HW (N) PRPLT slot or NVMe (N) inline cryptographic module. The computing system can acquire a Crypto Key slot index from a secure process.

[0144] As an example, with respect to the example illustrated in Figure 13, if the user data fits on the first page of system memory, the system can Petition 870250079875, dated 05 / 09 / 2025, pages 576 / 684 45 / 80 write security context information to the PRPLT N location in the PRPLT 1300 SRAM, write PRPLT_Index = N to command 1000, proceed with other steps to create the command and push command 1000 to an SQ and maintain a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0145] As another example, with respect to the example illustrated in Figure 14, in block 1412, if the user data fits into two system memory pages, the computing system can write the security context information to location N of PRPLT in PRPLT 1300's SRAM, write PRPLT_Index = N and insert the LB offset in the lower 12 bits in PRP2 (aligned to the page boundary) in command 1002, proceed with other steps to create the command and send command 1002 to an SQ, in addition to maintaining a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0146] As another example, in relation to the examples illustrated in Figures 16 and 17, if the user data requires more than 2 system memory pages and up to the limit of the system memory pages, the system may determine that only one PRPL is needed. The PRPL creation process may include, for each PRP entry (PRPs are all aligned to the page boundary), inserting an LB offset 12 bits lower (b / t[1:0] = 2'b00) in PRPL 1100. Command processing may include writing security context information to the PRPLT N location in the SRAM of PRPLT 1300, writing PRPLT_Index = N and inserting a PRPL pointer into a PRP2 field in command 1502, proceeding with other steps for command creation, and pushing command 1502 to an SQ and maintaining a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0147] As another example, in relation to the examples illustrated in Figures a 17, user data requires more than the threshold of system memory pages.Multiple PRPLs 1100, 1200 are required (chained PRPL), the PRPL creation process may include, for all but the last PRP entry in PRPL 1200 (PRPs are all aligned to the page contour), inserting the LB offset 12 bits lower (bit[1:0] = 2'b00) in PRPLs 1100, 1200 and 1200. Petition 870250079875, dated 05 / 09 / 2025, pages 577 / 684 46 / 80 place the pointer to the next PRPL 1200 until the last PRP entry in PRPL 1100. Command processing may include writing security context information to the PRPLT N location in the SRAM of PRPLT 1300, writing PRPLT_Index = N and inserting a first PRPL pointer into a PRP2 field in command 1502, proceeding with other steps for command creation and pushing command 1502 to an SQ and maintaining a mapping of {SQID, CID} -> N or {SQID, CID, NSID} -> N.

[0148] In some modes, when the read data for this access comes from DDR, the system can analyze the command structure 1000, 1002, 1502 and extract the PRP details and place them in shadow storage, such as PRPLT SRAM 1300 and / or LUT SRAM 1302. If command 1502 includes a pointer to PRPL, the system can cache it in a small temporary storage, such as PRPLT SRAM 1300 and / or LUT SRAM 1302.

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

[0150] When the NVMe device issues a read address (N) to read a PRPL 1100, 1200, the system can perform a content lookup in the PRPLT, in the SRAM of PRPLT 1300. It can reach location N. This read access can be to read PRPs from that PRPL 1100, 1200. The system can insert N into a Read Trace 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 trigger the read trace FIFO, by Petition 870250079875, dated 05 / 09 / 2025, pages 578 / 684 47 / 80 example using a get N operation. The system can analyze the structure of PRPL 1100, 1200 and extract the details of PRP and place them in the shadow, such as the SRAM of PRPLT 1300 and / or the LUT SRAM 1302.

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

[0152] Some modalities can be implemented using a LUT (e.g., PRP 802 table in Figure 8, SRAM 1302 LUT in Figures 13 to 17) and without using a PRPLT (e.g., PRPL 800 table in Figure 8, PRPLT 1300 SRAM in Figures 13 to 17).The advantages of implementations using a LUT without a PRPLT may include less software overhead than the software overhead created by implementing and managing both a PRPLT and a LUT, including overhead created by implementing and managing the PRPLT itself and the data relationship between the PRPLT and the LUT. Advantages may also include elevation constraints on a series of command submissions to the NVMe device (e.g., storage memory 24 in Figure 1) compared to implementations where the PRPLT and LUT are implemented together. Other advantages may include support for PCIe Address Translation Service (ATS) for virtual address to physical address mapping and reduced silicon footprint due to not implementing and managing a PRPLT.

[0153] Figure 18 illustrates an NVMe inline cryptographic module. With reference to Figures 1 to 18, the NVMe inline cryptographic module 38 (e.g., inline cryptographic module 38 in Figures 1 to 3, NVMe-ICE module 500 in Figure 5) can be configured to manage command parsing and a LUT 1800 (by Petition 870250079875, dated 05 / 09 / 2025, pages 579 / 684 48 / 80 example, PRP table 802 in Figure 8, LUT SRAM 1302 in Figures 13 to 17) to implement NVMe inline cryptographic processes using PRPs (e.g., PRP 626 in Figure 6) in computing systems (e.g., computing device 10 in Figure 1, NVMe inline cryptographic system 200 in Figure 2). The NVMe inline cryptographic module 38 may also include other components to implement NVMe inline cryptographic processes using PRPs, including unique address range registers 1804, which can be for any number of unique address ranges, such as 8, 16, 32, 64, etc. The NVMe 38 online cryptographic module can include SQ and CQ 1806 address range registers, which can be configured to store starting addresses, ending addresses, and / or sizes of one or more send queues (e.g., SQ 404 in Figure 5) and / or SQ entries and command queues (e.g., completion queue 406 in Figure 5) and / or CQ entries.

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

[0155] Figure 19 illustrates an example of a command structure processed by the NVMe 38 online cryptographic module. With reference to Figures 1 to 19, a 1900 command structure (e.g., commands 902, 1000, 1002, 1102, 1202, 1502 in Figures 9B to 15) can be for I / O accesses involving the transfer of user data that must be encrypted for security purposes, including read and / or write commands. The command structure Petition 870250079875, dated 05 / 09 / 2025, pages 580 / 684 49 / 80 1900 can be a modified version of a common submission command format for NVMe implementation. For example, the structure of a 1900 command might include aspects typically included in a submission command format, such as a command identifier (CID), a PRP or SGL for Data Transfer Indicator (PSDT), a merge indicator and opcode, a namespace identifier (NSID), a metadata pointer (MPTR), and PRP pointers (e.g., PRP1, PRP2) (e.g., PRP 626 in Figure 6) and / or PRPL pointers (e.g., in PRP2) (e.g., PRPL pointer 628 in Figure 6). Modifications to the structure of a 1900 command might include a cryptographic function enable (CE) indicator, which might include a bit located in a commonly reserved space, e.g., command word (CWD) 0, bit 10.The cryptographic function enablement indicator can be configured to enable and / or disable the cryptographic functions of the NVMe 38 online cryptographic module. Modifications can also include a key slot locator, which can be any combination of bits, such as 8 bits located in a commonly reserved space, for example, CWD3, bits 23:16. The key slot locator must be configured to enable the NVMe 38 online cryptographic module to locate a suitable cryptographic key from an 1812 key table to implement the cryptographic functions.

[0156] The NVMe device (e.g., 24-bit storage memory) Figure 1, NVMe 214 device (in Figures 2, 5, and 6) can read command 1900 and a list of PRP and / or PRP (e.g., PRPL 622, 1100, 1200 in Figures 6, 11A, 12A, 16, 17), which can instruct the NVMe 38 online cryptographic module to parse the command input and the PRP and / or PRP list. The NVMe 38 online cryptographic module can read the cryptographic function enable indicator and key slot data from command 1900. In some instances, the NVMe 38 online cryptographic module can overwrite the cryptographic function enable indicator and key slot data in the command 1900 data, such as Petition 870250079875, dated 05 / 09 / 2025, pages 581 / 684 50 / 80 writing zeros in the appropriate locations in the 1900 command data structure.

[0157] The NVMe 38 online cryptographic module can update the 1800 LUT with PRP entries from the 1900 command and / or the PRP list and security context that can be parsed and read from the 1900 command. Figure 20 illustrates an example of an 1800 LUT structure. With reference to Figures 1 to 20, an 1800 LUT structure can include an index for each 1800 LUT entry and a PRP entry pointer (ptr) and / or PRP list (PRPL) entry and a security context associated with each index. The PRP entry and / or PRPL pointer entry can include a corresponding PRP base address.The security context may include a Logical Block Address (LBA), a Namespace Identifier (NSID), a Cryptographic Function Enable (CE) indicator, and key slot (KS) data, a pointer type including PRP list pointer or PRP (PRPL) (ptr) pointer, metadata data of the 1900 command referenced by the metadata pointer, etc.

[0158] The NVMe 38 online cryptographic module can perform real-time PRP address modification on the 1900 command data by replacing PRP address bits (e.g., PRP1 and / or PRP2) with the corresponding LUT index. For example, the NVMe 38 online cryptographic module can replace some of the address bits, such as in the bit range 63:12. Replacing some of the address bits can enable the maintenance of an original PRP address offset within a page, such as a 4 KB page. In some instances, the NVMe 38 online cryptographic module can label the PRP address as modified by setting one or more specific bits of the PRP address, such as bit 63.In some embodiments, the PRP address can be modified so that the modified address can be within a range defined by software (e.g., application 204, core 206, NVMe driver 208, PCIe driver 210 in Figure 2) configured not to overlap an exclusion range or other range used by the software and that is not in LUT 1800. The NVMe 38 inline cryptographic module can use the LUT 1800 index to locate the PRP entry and / or... Petition 870250079875, dated 05 / 09 / 2025, pages 582 / 684 51 / 80 PRPL pointer input and the safety context associated with a command as described further in the present invention.

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

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

[0161] The 2100 host software and the NVMe 38 online cryptographic module can initialize the NVMe 38 online cryptographic module by implementing various 2110 processes. These processes may include the configuration of various module registers. Petition 870250079875, dated 05 / 09 / 2025, pages 583 / 684 NVMe 38 online cryptographic 52 / 80. These processes may include configuring 1804 unique address range registers by implementing a 2112 process. 1804 unique address range registers can be configured for any number of unique address ranges, such as 8, 16, 32, 64, etc. These processes may include configuring 1806 SQ address range registers by implementing a 2114 process and configuring 1806 CQ address range registers by implementing a 2116 process. 1806 SQ and CQ address range registers can be configured for any number of unique address ranges, such as 8, 16, 32, 64, etc. for any number of dispatch queues (e.g., SQ 404 in Figure 5) and command queues (e.g., completion queue 406 in Figure 5), such as 8, 16, 32, 64, etc.These processes may include configuring other configuration registers of the NVMe 38 online cryptographic module (for example, additional components 1808 in Figure 18) implementing a process 2118.

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

[0163] Figure 22 illustrates a method for implementing a command creation stage for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various modalities. With reference to Figures 1 to 22, the computing system (e.g., computing device 10 in Figure 1, NVMe inline cryptographic system 200 in Figure 2) may include a host memory 36 (e.g., host memory 402 in Figure 5), a host processing system 202 (e.g., host400 in Figure 5, processing system 600 in Figure 6), which may be implemented as a SoC, Petition 870250079875, dated 05 / 09 / 2025, pages 584 / 684 53 / 80 configured to run a 2100 host software (e.g., application 204, core 206, NVMe driver 208, PCIe driver 210 in Figure 2), such as through a processor (e.g., processor 14 in Figures 1 and 2, host 400 in Figure 5) and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in Figure 5) and a PCIe root complex 212 (e.g., PCIe controller 212 in Figure 2, PCIe root complex 606 in Figure 6) and an NVMe device 214 (e.g., storage memory 24, in Figure 1). In some examples, the host software may be a 2100 operating system (e.g., Android, Windows, iOS, etc.).

[0164] The 2100 host software can execute a command creation stage in which the 2100 host software can create a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in Figures 9B to 15, 19) to read and / or write to host memory 36. Such commands may be for I / O accesses involving the transfer of user data that must be encrypted for security purposes. The 2100 host software can implement several processes to create the command that enable cryptographic functions of the NVMe inline cryptographic module 38 to implement the command. Host software 2100 can acquire cryptographic key slot data for a command that requires cryptographic functions by implementing a 2200 process. Host software 2100 can create the command by programming the command data into a send queue command entry, including key slot data and a cryptographic function enablement, in a 2202 process.The key slot data can be configured to enable the NVMe 38 online cryptographic module to locate a suitable cryptographic key from a key table (e.g., key table 1812 in Figure 18) to implement cryptographic functions. The cryptographic function enable indicator can be set to enable and / or disable the cryptographic functions of the NVMe 38 online cryptographic module.

[0165] Host software 2100 can send the command to host memory 36 for addition to the send queue (e.g., SQ 404 in Figure 5) in response to the input Petition 870250079875, dated 05 / 09 / 2025, pages 585 / 684 54 / 80 of the send queue command implementing a 2204 process. The host software 2100 can update the send queue buzzer (e.g., buzzer 408 in Figure 5) on the NVMe device 214 implementing a 2206 process.

[0166] Figures 23A and 23B illustrate methods for implementing command processes for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modalities.With reference to Figures 1 to 23B, the computing system (e.g., computing device 10 in Figure 1, NVMe inline cryptographic system 200 in Figure 2) may include a host memory 36 (e.g., host memory 402 in Figure 5), a host processing system 202 (e.g., host 400 in Figure 5, processing system 600 in Figure 6), which may be implemented as a SoC, configured to run a host software 2100 (e.g., application 204, core 206, NVMe driver 208, PCIe driver 210 in Figure 2), as through a processor (e.g., processor 14 in Figures 1 and 2, host 400 in Figure 5) and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in Figure 5) and a PCIe root complex 212 (e.g., PCIe controller). 212 in Figure 2, PCIe root complex 606 in Figure 6) and an NVMe device 214 (e.g., storage memory 24, in Figure 1).In some configurations, the host software may be an operating system (e.g., Android, Windows, iOS, etc.).

[0167] The embodiment illustrated in Figure 23A refers to a command (for example, command 902, 1000, 1002, 1102, 1202, 1502, 1900 in Figures 9B to 15, 19) having PRP inputs (for example, PRP 626 in Figure 6) and non-PRPL inputs (for example, PRPL pointer 628 in Figure 6). The modality illustrated in Figure 23B refers to a command (e.g., command 902, 1000, 1002, 1102, 1202, 1502, 1900 in Figures 9B to 15, 19) having at least one PRP entry (e.g., PRP 626 in Figure 6) and at least one non-PRPL entry (e.g., PRPL pointer 628 in Figure 6). The processes of the modalities illustrated in Figures 23A and 23B can be implemented similarly. Petition 870250079875, dated 05 / 09 / 2025, pages 586 / 684 55 / 80 except where otherwise specified.

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

[0169] In the embodiment illustrated in Figure 23A, for which the data read from the corresponding command send input includes PRP entries and non-PRPL entries, the NVMe 38 online cryptographic module can update LUT 1800 (e.g., PRP table 802 in Figure 8, SRAM LUT 1302 in Figures 13 to 17) and modify the command send input data in real time by implementing a 2308 process. For example, with reference to Figures 1 to 25, the NVMe 38 online cryptographic module can update LUT 1800 by adding entries to the PRP entries of the command send by adding an index, the PRP addresses, and the security context for each PRP entry, an example of which is shown in LUT 1800 in Figure 25. The NVMe 38 online cryptographic module can modify the command send input data by replacing the PRP address data with the corresponding index of the LUT 1800, an example of which is shown in the 1900 command data in Figure 24.

[0170] In the mode illustrated in Figure 23B, for which the data read from the corresponding command sending input includes at least one PRP entry (for example, PRP 626 in Figure 6) and at least one PRPL entry (for Petition 870250079875, dated 05 / 09 / 2025, pages 587 / 684 (e.g., PRP table 802 in Figure 8, SRAM LUT 1302 in Figures 13 to 17) and modify the command send entry data in real time by implementing a 2312 process. For example, the NVMe 38 inline cryptographic module can update LUT 1800 by adding entries for at least one PRP entry and at least one PRPL entry of the send command, adding an index, the PRP address, and the PRPL address and security context for each PRP and PRPL entry, an example of which is shown in LUT 1800 in Figure 25. The NVMe 38 inline cryptographic module can modify the command send entry data by replacing the PRP address data and the PRPL address data with the corresponding LUT index. 1800, an example of which is shown in the 1900 command data in Figure 24.

[0171] The NVMe in-line cryptographic module 38 may return the modified data from the command send input to the NVMe device 214 by implementing a process 2310.

[0172] Figure 26 illustrates a method for implementing command processes for NVMe online cryptographic processes using PRPs on computing systems configured to implement various modes.With reference to Figures 1 to 26, the computing system (e.g., computing device 10 in Figure 1, NVMe inline cryptographic system 200 in Figure 2) may include a host memory 36 (e.g., host memory 402 in Figure 5), a host processing system 202 (e.g., host 400 in Figure 5, processing system 600 in Figure 6), which may be implemented as a SoC, configured to run a host software 2100 (e.g., application 204, core 206, NVMe driver 208, PCIe driver 210 in Figure 2), as through a processor (e.g., processor 14 in Figures 1 and 2, host 400 in Figure 5) and having the NVMe inline cryptographic module 38 (e.g., NVMe-ICE module 100 in Figure 5) and a PCIe root complex 212 (e.g., controller). PCIe. Petition 870250079875, dated 05 / 09 / 2025, pages 588 / 684 57 / 80 212 in Figure 2, PCIe root complex 606 in Figure 6) and an NVMe device 214 (e.g., storage memory 24, in Figure 1). In some embodiments, the host software may be an operating system 2100 (e.g., Android, Windows, iOS, etc.).

[0173] When input is read from the command sending queue (e.g., SQ) 404 in Figure 5) includes a list of PRPs (e.g., PRP 622, 1100, 1200 in Figures 6, 11A, 12A, 16, 17), as in the mode described with reference to Figure 23B, the entries in the PRP list can also be read. The NVMe 214 device can implement a transaction with the NVMe 38 inline cryptographic module to read each PRP entry (e.g., PRP 626 in Figure 6) from the PRP list by implementing a 2600 process. In some modes, the transaction can be an AXI transaction. The transaction can specify the LUT index for the corresponding PRP list received in the modified data of the command submission entry in the mode described with reference to Figure 23B. The NVMe 38 online cryptographic module can find the LUT index in LUT 1800 (e.g., PRP table 802 in Figure 8, SRAM LUT 1302 in Figures 13 to 17) and retrieve the corresponding PRP list address and security context by implementing a 2602 process.The NVMe inline cryptographic module 38 can forward the transaction to read the entries from the PRP list of the command-submit queue to host memory 36 by implementing a process 2604. Host memory 36 can respond to the transaction by returning read data from the corresponding command-submit entry by implementing a process 2606.

[0174] The NVMe 38 online cryptographic module can update LUT 1800 and modify the command-send entry data for each PRP entry in the PRP list in real time by implementing a 2608 process. For example, with reference to Figures 1 to 28, the NVMe 38 online cryptographic module can update LUT 1800 by adding entries for each PRP entry in the PRP list, adding an index, the PRP address, and the security context for each PRP entry, an example of which is shown in LUT 1800 in Figure 28. The Petition 870250079875, dated 05 / 09 / 2025, pages 589 / 684 The NVMe 38 online cryptographic module 58 / 80 can modify the data of each PRP entry in the PRP list by replacing the PRP address data with the corresponding LUT 1800 index, an example of which is shown in Figure 27. The NVMe 38 online cryptographic module can return the modified data from the command send entry to the NVMe 214 device by implementing a 2610 process.

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

[0176] The NVMe 214 device can transmit a transaction to the NVMe 38 inline cryptographic module to write data from host memory 36 implementing a 2900 process. In some embodiments, the transaction can be an AXI transaction. The transaction can specify the LUT index for the corresponding PRP (e.g., PRP 626 in Figure 6) received in the modified data from the command send input in the embodiments described with Petition 870250079875, dated 05 / 09 / 2025, pages 590 / 684 59 / 80 refers to Figures 23A and 26. The NVMe 38 online cryptographic module can analyze and validate the transaction by implementing a 2902 process. The analyzed transaction data may include the LUT index. The NVMe 38 inline cryptographic module can use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in Figure 6) subject to the write command and security context of LUT 1800 implementing a 2904 process. The validated transaction data retrieved from LUT 1800 (e.g., PRP table 802 in Figure 8, SRAM LUT 1302 in Figures 13 to 17) can be used by the NVMe 38 inline cryptographic module to forward the transaction for reading the PRP address to host memory 36 implementing a 2906 process. Host memory 36 can respond to the transaction by reading write data from host memory 36 and returning write data for the corresponding PRP address implementing a 2908 process.The NVMe 38 inline cryptographic module can encrypt received write data by implementing a 2910 process. For example, encryption can be implemented using the security context key slot to retrieve the cryptographic key for encryption. The NVMe 38 inline cryptographic module can transmit the encrypted write data to the NVMe 214 device by implementing a 2912 process.

[0177] Figure 30 illustrates a method for implementing read command processes for NVMe inline cryptographic processes using PRPs in computing systems configured to implement various modalities. With reference to Figures 1 to 30, the computing system (e.g., computing device 10 in Figure 1, NVMe inline cryptographic system 200 in Figure 2) may include a host memory 36 (e.g., host memory 402 in Figure 5), a host processing system 202 (e.g., host 400 in Figure 5, processing system 600 in Figure 6), which may be implemented as a SoC, configured to run a host software 2100 (e.g., application 204, core 206, NVMe driver 208, PCIe driver 210 in Figure 2), as through a Petition 870250079875, dated 05 / 09 / 2025, pages 591 / 684 60 / 80 processor (e.g., processor 14 in Figures 1 and 2, host 400 in Figure 5) and having the NVMe 38 inline cryptographic module (e.g., NVMe-ICE module 100 in Figure 5) and a PCIe 212 root complex (e.g., PCIe 212 controller in Figure 2, PCIe 606 root complex in Figure 6) and an NVMe 214 device (e.g., storage memory 24, in Figure 1). In some embodiments, the host software may be an operating system (e.g., Android, Windows, iOS, etc.).

[0178] The NVMe device 214 can transmit a transaction to the NVMe inline cryptographic module 38 to read data from a logical block address of the NVMe device to write to host memory 36 by implementing a process 3000. In some embodiments, the transaction can be an AXI transaction. The transaction can specify the LUT index for the corresponding PRP (e.g., PRP 626 in Figure 6) received in the modified data of the command send input in the embodiments described with reference to Figures 23A and 26. The NVMe device 214 can transmit encrypted data from the logical block address of the NVMe device by implementing a process 3002. The NVMe inline cryptographic module 38 can parse and validate the transaction by implementing a process 3004. The parsed transaction data can include the LUT index.The NVMe 38 inline cryptographic module can use the LUT index to retrieve the corresponding address for the PRP entry (e.g., PRP 626 in Figure 6) subject to the read command and security context of LUT 1800 (e.g., PRP table 802 in Figure 8, LUT SRAM 1302 in Figures 13 to 17) by implementing a process 3006. The NVMe 38 inline cryptographic module can decrypt the received encrypted data by implementing a process 3008. For example, decryption can be implemented using the key slot of the security context to retrieve the cryptographic key to implement decryption. The validated transaction data retrieved from LUT 1800 can be used by the NVMe 38 inline cryptographic module to forward the transaction for writing to the PRP address in host memory 36 by implementing a process 3010. Petition 870250079875, dated 05 / 09 / 2025, pages 592 / 684 The 61 / 80 NVMe online cryptographic module 38 can transmit the decrypted data for writing to the PRP address in host memory 36 by implementing a process 3012.

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

[0180] The NVMe device 214 can write a command completion entry to the command queue (e.g., CQ 406 in Figure 5) and update the command queue tail buzzer pointer in host memory 36 by implementing process 3100. The NVMe device 214 can transmit a command completion interrupt to host software 2100 by implementing process 3102. Host software 2100 can implement a driver process command completion by implementing process 3104. Host software 2100 can write the command queue head pointer to the command queue head pointer buzzer (e.g., buzzer 410 in Figure 5) on the NVMe device 214 by implementing process 3106. Petition 870250079875, dated 05 / 09 / 2025, pages 593 / 684 62 / 80

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

[0182] The processes of the examples illustrated in Figures 32A and 32B can be implemented in the same manner as described in the present invention. For example, the command creation stage can be implemented as described with reference to Figure 22, the command process 2300, 2302, 2304, 2306, 2308, 2310, 2312 can be implemented as described with reference to Figures 23A and 23B, the NVMe device that initiates data transfer can be implemented as described with reference to Figures 29 and 30, and the command completion posture can be implemented as described with reference to Figure 31.

[0183] The NVMe 38 online cryptographic module can look up a virtual address for mapping the physical address of the MMU 3200 to the addresses of Petition 870250079875, dated 05 / 09 / 2025, pages 594 / 684 63 / 80 PRPs (e.g., PRP 626 in Figure 6) and / or PRPLs (e.g., PRPL 622, 1100, 1200 in Figures 6, 11A, 12A, 16, 17) implementing a 3202 process. The addresses used by the NVMe device may be in virtual address format and the addresses used by the host device 36 may be in physical address format. The NVMe 214 device can parse received command input data and request the reading of PRP entries (e.g., PRP 626 in Figure 6) from a list of PRPs (e.g., PRPL 622, 1100, 1200 in Figures 6, 11A, 12A, 16, 17) by performing a 3206 process. The NVMe 38 online cryptographic module can fetch a virtual address for physical address mapping from the MMU 3200 to the addresses of each PRP in the PRP list by implementing a 3204 process.

[0184] Various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1 to 32B) can be implemented in a wide variety of computing systems, including automotive vehicles or other mobile computing devices, a suitable example of which for use with various embodiments is illustrated in Figure 33. The mobile computing device 3300 may include a processor 3302 coupled to a touchscreen controller 3304 and an internal memory 3306. The processor 3302 may be one or more multi-core integrated circuits designed 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 used include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, MRAM, STT-RAM, and embedded DRAM. The 3304 touchscreen controller and the 3302 processor can also be coupled to a 3312 touchscreen panel, such as a resistive touchscreen, a capacitive touchscreen, an infrared touchscreen, etc. Additionally, the mobile computing device display. Petition 870250079875, dated 05 / 09 / 2025, pp. 595 / 684 64 / 80 The 3300 doesn't need to have touchscreen capability.

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

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

[0187] The mobile computing device 3300 may also include speakers 3314 to provide audio output. The mobile computing device 3300 may also include a housing 3320, constructed of plastic, metal, or a combination of materials, to contain all or some of the components described in the present invention. The mobile computing device 3300 may include a power source 3322 coupled to the processor 3302, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the connection port of the peripheral device to receive a charging current from a source external to the mobile computing device 3300. The mobile computing device 3300 may also include a physical button 3324 to receive user input. The mobile computing device 3300 may also include a button Petition 870250079875, dated 05 / 09 / 2025, pages 596 / 684 65 / 80 on / off 3326 to turn the mobile computing device 3300 on and off.

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

[0189] The various embodiments (including, but not limited to, the embodiments described above with reference to Figures 1 to 32B) can also be implemented in fixed computing systems, such as any of a variety of commercially available servers. An example of a 3500 server is illustrated in Figure 35. Such a 3500 server typically includes one or more sets of multi-core processors 3501 coupled to volatile memory 3502 and a Petition 870250079875, dated 05 / 09 / 2025, pages 597 / 684 66 / 80 large-capacity non-volatile memory, such as a 3504 disk drive. As illustrated in Figure 35, the 3501 multi-core processor assemblies can be added to the 3500 server by inserting them into the assembly racks. The 3500 server may also include a floppy disk drive, compact disc (CD) drive, or digital versatile disc (DVD) drive 3506 coupled to the processor 3501. The 3500 server may also include network access ports 3503 coupled to the multi-core processor assemblies 3501 to establish network interface connections with a network 3505, such as a local area network coupled to other computers and broadcast system servers, the internet, the 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).

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

[0191] Implementation examples are described in the following paragraphs. Although some of the following implementation examples are described in terms of example systems, devices, or methods, additional example implementations may include: the example systems or devices discussed in the following paragraphs implemented as a method that performs operations of the example systems or devices; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising a configured NVMe online cryptographic module. Petition 870250079875, dated 05 / 09 / 2025, pages 598 / 684 67 / 80 to perform operations of the example systems, devices, or methods; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising a processing system configured with device-executable processing instructions to perform operations of the example systems, devices, or methods; a computing device including means for performing functions of the example systems, devices, or methods; and the example systems, devices, or methods discussed in the following paragraphs implemented as a processor-readable nontransient storage medium that has stored therein processor-executable instructions configured to cause a processor of a computing device to perform the operations of the example systems, devices, or methods.

[0192] Example 1. A method for providing data encryption on a non-volatile express memory (NVMe) device, including selectively encrypting data for storage using inline encryption circuitry, distinguishing data communicated over a PCIe link from driver, read, page, and buffer address data communicated over the PCIe link; and encrypting only the data.

[0193] Example 2. The method of example 1, including additionally: identifying probable address ranges based on operations being performed on the NVMe memory device; and storing the probable address ranges in memory, wherein the distinction of data communicated through a PCIe link from driver, read, page, and buffer address data communicated through the PCIe link may include recognizing as data for encryption any data with addresses that do not fall within the probable address ranges in memory stored in memory.

[0194] Example 3. The method from example 2, in which identifying likely address ranges based on operations being performed on the NVMe memory device includes maintaining a shadow only of those pages that Petition 870250079875, dated 05 / 09 / 2025, pp. 599 / 684 68 / 80 The NVMe memory device read from system memory.

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

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

[0197] Example 6. The method of any of examples 4 and 5, including additionally: shadowing all PRPs within the NVMe device into 32 address ranges of submission queue registers to simplify the search logic for identifying input user data buffer accesses.

[0198] Example 7. The method of any of examples 4 through 6, including additionally: comparing an input address from the NVMe device with a memory-stored address database that includes a start and end address from a send queue (SQ) table, completion queue (CQ) table, PRP list table, and a PRP table; and determining whether the data should be encrypted based on whether the input address matches an entry in the memory-stored address database.

[0199] Example 8. The method of any of examples 4 to 7, including additionally: trapping device accesses for interpretation according to the NVMe specification; and extracting PRPs from each request in real time and evaluating each access request to determine if it is legitimate.

[0200] Example 9. The method of any of examples 4 through 8, including additionally: setting up registers with the start and end addresses of the send queue to identify whether a read address falls within one of the 32 ranges of Petition 870250079875, dated 05 / 09 / 2025, pages 600 / 684 69 / 80 address; determine the PRPs that are cached on the NVMe device; store in a reserved field in an NVMe command a PRP list index (PRPL) of a command entry that provides an accurate shadow of all PRPs that are dynamically cached within the NVMe device.

[0201] Example 10. The method of any of examples 4 through 9, including additionally: setting up a send queue (SQ) with base addresses and Qsize values; setting up a completion queue (CQ) with base addresses and Qsize values; and using fields in an NVMe command structure to store a PRPL index of a command entry, so as to create a shadow of all cached PRPs within the NVMe device.

[0202] Example 11. The method, according to any of examples 4 to 10, where, in response to the determination that user data fits on a system memory page: write security context information to location N of the physical region page list table (PRPLT); write PRPLT_Index = N in the command; create the command and push it to the SQ; and maintain the mapping of ({SQID, CommandID} -> N).

[0203] Example 12. The method, according to any of examples 4 to 11, wherein, in response to the determination that user data fits into two system memory pages: write security context information to location N of the physical region page list table (PRPLT); insert LB offset in the lower 12 bits of PRP2 (aligned page boundary); create the command and push to SQ; and maintain the mapping of ({SQID, CID} -> N).

[0204] Example 13. The method, according to any of examples 4 to 12, wherein, in response to the determination that user data fits in more than 2, but less than 512 pages of system memory: for each PRP entry aligned to the page boundary, insert LB offset in 12 bits lower and configuration bit [1:0] = 2'b00; write security context information to Petition 870250079875, dated 05 / 09 / 2025, pages 601 / 684 70 / 80 local of the physical region page list table (PRPLT) N inserting the PRPL pointer into the PRP2 field; create the command and push it to SQ; and maintain the mapping of ({SQID, CID} -> N).

[0205] Example 14. The method of any of examples 4 to 13, wherein, in response to the determination that the user data fits in more than 512 system memory pages: for all but the last page-bound PRP entry, insert LB offset by 12 bits down, set bit[1:0] = 2'b00 and place a pointer to the next PRPL in the last PRP entry; write security context information to the physical region page list table (PRPLT) N location by inserting the first PRPL pointer into the PRP2 field; create the command and push to SQ; and maintain the mapping of ({SQID, CID} -> N).

[0206] Example 15. The method of any of examples 4 to 14, including additionally: using the PRPLT index field of the command, reading PRPLT [N] (SLBA); finding a free location in LUT and inserting PRP1 into that LUT location; calculating the LBA to which this buffer is mapped; deleting the PRPLT pointer from the command and making it RSVD; and sending the modified command to the NVMe device.

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

[0208] Example 17. The method of any of examples 4 through 16, including additionally: performing a content lookup in a PRPLT in response to the determination that the device issued a request to read address (N) to read the PRPL to obtain a hit for location N; inserting N into the read trace FIFO; forwarding the read access to system memory; triggering the read trace FIFO to obtain N in response to the determination that a read data for the access arrives from system memory. Petition 870250079875, dated 05 / 09 / 2025, pages 602 / 684 71 / 80 system; analyze the PRPL structure to extract the PRP details; and add the PRP details to the shadow.

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

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

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

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

[0213] Example 22. The method in Example 19, wherein generating the shadow of at least one PRP from the command input data in the first data structure includes generating an entry for at least one PRP in the first data structure, the entry for at least one PRP in the first data structure including an address of at least one PRP, and a security context for at least one PRP. Petition 870250079875, dated 05 / 09 / 2025, pages 603 / 684 72 / 80 a PRP from a second data structure.

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

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

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

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

[0218] Example 27. The method of any of examples 19 to 21, 25 or 26, wherein generating the shadow PRPL from the command input data in the first data structure includes generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including a PRPL address and a security context for the PRPL from the input data. Petition 870250079875, dated 05 / 09 / 2025, pages 604 / 684 73 / 80 control.

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

[0220] Example 29. The method from example 28, in which the generation of the shadow of each PRP of the PRPL in the first data structure includes generating an entry for each PRP of the PRPL in the first data structure, the entries for each PRP of the PRPL in 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 from an entry of the PRPL in the first data structure.

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

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

[0223] Example 32. The method of either of examples 19 or 22 to 26, in which generating the shadow of the PRPL from the command input data in the first data structure includes generating an entry for a shadow of each PRP from the PRPL in the first data structure, the entries for the shadows of each PRP in the first data structure including an address of each PRP from the PRPL and a security context for each PRP from the PRPL and a Petition 870250079875, dated 05 / 09 / 2025, pages 605 / 684 74 / 80 security context for each PRP from a second data structure.

[0224] Example 33. The method of example 32, including additionally: sending the modified command input data to the NVMe device; identifying a second transaction from the NVMe device to read the PRPL, in which the generation of the PRPL shadow from the command input data in the first data structure occurs in response to the identification of the second transaction from the NVMe device; and modifying each PRP from the PRPL to point to the shadow of each PRP, thus generating a modified PRPL.

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

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

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

[0228] Example 37. The method of any of examples 19 to 36, in which the modified command input data includes a virtual address, the method additionally including fetching a virtual address for mapping from physical address to virtual address in parallel with generating the shadow of at least one PRP of the command input data in the first structure of Petition 870250079875, dated 05 / 09 / 2025, pages 606 / 684 75 / 80 data.

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

[0230] Example 39. A method for providing cryptographic functions for data in non-volatile express memory (NVMe) protocol executed by a processing system, including: acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; writing a cryptographic enablement for a command input from the command to a send queue; writing the cryptographic key slot reference for the command input from the command to the send queue; and sending the command input from the command with the cryptographic enablement and the cryptographic key slot reference to the send queue.

[0231] Example 40. The method of example 39, including additionally: acquiring a page-level read / write pointer lookup table (PRPLT) slot for the command of an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to the command entry of the command to the send queue, wherein sending the command entry of the command with the cryptographic enablement and the cryptographic key slot reference to the send queue includes sending the command entry of the command including the cryptographic enablement, the cryptographic key slot reference and the PRPLT slot reference to the send queue.

[0232] Example 41. The method of either of examples 39 or 40, in which: The command has more than one page-level read / write pointer (PRP); the method additionally includes writing a logical block address offset to part of at least one PRP of the command input to the queue. Petition 870250079875, dated 05 / 09 / 2025, pages 607 / 684 76 / 80 of sending; and sending the command input with the cryptographic enablement and cryptographic key slot reference to the sending queue includes sending the command input including the cryptographic enablement, the cryptographic key slot reference, and at least one PRP having a logical block offset.

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

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

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

[0236] Example 45. The method of any of examples 39 to 44, including additionally: setting up a first set of one or more records of an inline cryptographic module corresponding to a number of command sending queues; and setting each of the first set of one or more records with a range of addresses from a different command sending queue.

[0237] Example 46. The method of example 45, in which the definition of each of the first set of one or more records with the range of addresses of a queue. Petition 870250079875, dated 05 / 09 / 2025, pages 608 / 684 77 / 80 command sending different includes defining each of the first set of one or more records with a starting address and a size of a command sending queue different from the command sending queues.

[0238] Example 47. The method of example 45, in which the definition of each of the first set of one or more records with the address range of a different command sending queue includes the definition of each of the first set of one or more records with a starting address and a ending address of a different command sending queue.

[0239] Example 48. The method of any of examples 45 to 47, including additionally: setting up a second set of one or more records of the cryptographic module inline corresponding to a number of command completion queues; and setting each record of the second set of one or more records with a start address and a size of a command sending queue different from the command sending queues.

[0240] Example 47. The method of examples 45 to 47, including additionally: Configure a second set of one or more records from the inline cryptographic module corresponding to a number of unique address ranges; and define each record in the second set of one or more records with a starting address and a size of a unique address range different from the unique address ranges.

[0241] The descriptions of the preceding methods and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order shown. As will be recognized by one skilled in the art, the order of operations in the preceding embodiments can be performed in any order. Words such as after this, then, afterward, etc., are not intended to limit the order of operations; these words are used simply to guide the reader through the description of the methods. Furthermore, any reference to claim elements in the singular, for example, using the articles a, an, or the, does not Petition 870250079875, dated 05 / 09 / 2025, pp. 609 / 684 78 / 80 should be interpreted as limiting the element to the singular.

[0242] The various illustrative logic blocks, modules, circuits, and algorithmic operations described in connection with the various embodiments can be implemented in the form of electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above in terms of their functionality. The possibility of such functionality being implemented as hardware or software depends on the particular application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0243] The hardware used to implement the various logics, logic blocks, modules, and illustrative circuits described in connection with the embodiments disclosed in the present invention may be implemented or realized with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in the present invention. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine.A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors together with a DSP core, or any other similar configuration. Alternatively, some operations or methods can be performed by a set of circuits that is... Petition 870250079875, dated 05 / 09 / 2025, pages 610 / 684 79 / 80 specific to a given function.

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

[0245] The previous description of the disclosed modalities is provided to enable Petition 870250079875, dated 05 / 09 / 2025, pages 611 / 684 80 / 80 any technician in the art making or using the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles set forth in the present invention can be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments described in the present invention, but should be consistent with the broader scope consistent with the following claims and the innovative principles and attributes disclosed in the present invention. Petition 870250079875, dated 05 / 09 / 2025, pp. 612 / 684

Claims

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

2. Method, according to claim 1, characterized by generating the shadow of at least one PRP from the command input data in the first data structure comprising generating an entry for at least one PRP in the first data structure, the entry for at least one PRP in the first data structure including an address of at least one PRP and a security context for at least one PRP from the command input data.

3. Method, according to claim 1, characterized by modifying the command input data to enable reading the shadow of at least one PRP comprising modifying an address of at least one PRP in the command input data to point to the shadow of at least one PRP.

4. Method, according to claim 1, characterized by the generation of the shadow of at least one PRP from the command input data in the first data structure comprising generating an entry for at least one PRP in the first data structure, the entry for at least one PRP in the first data structure including an address of at least one PRP and a security context for at least one PRP from a second data structure.

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

6. A method according to claim 1, characterized in that the modification of the command input data to enable reading the shadow of at least one PRP comprises the removal of a reference to an entry for at least one PRP in a second data structure.

7. A method according to claim 1, characterized by further comprising: sending the modified command input data to the NVMe device; identifying a second NVMe device transaction to perform an operation on the shadow of at least one PRP; and implementing a cryptographic operation on data associated with the shadow of at least one PRP based on a security context associated with the shadow of at least one PRP.

8. Method according to claim 1, characterized by further comprising: generating a shadow of a PRP list (PRPL) of the command input data in the first data structure; and modifying the command input data to enable reading the shadow of the PRPL, thereby generating the modified command input data.

9. Method, according to claim 8, characterized by the generation of the PRPL shadow from the command input data in the first data structure, comprising generating an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including a PRPL address and a security context for the PRPL from the command input data.

10. A method according to claim 8, characterized by further comprising: sending the modified command input data to the NVMe device; identifying a second transaction of the NVMe device to read the shadow of the PRPL; generating a shadow of each PRP of the PRPL in the first data structure; and modifying each PRP of the PRPL to point to the shadow of each PRP, generating a modified PRPL.

11. Method, according to claim 10, characterized by the generation of the shadow of each PRP of the PRPL in the first data structure comprising generating an entry for each PRP of the PRPL in the first data structure, the entries for each PRP of the PRPL in 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 from an entry of the PRPL in the first data structure.

12. Method according to claim 10, characterized by further comprising: sending the modified PRPL to the NVMe device; identifying a third transaction on the NVMe device to perform an operation on at least one of the shadows of each PRP; and implementing a cryptographic operation on data associated with at least one of the shadows of each PRP based on the security context associated with at least one of the shadows of each PRP. Petition 870250079875, dated 05 / 09 / 2025, pp. 670 / 684 4 / 17 13. Method, according to claim 8, characterized in that the modification of the command input data to enable reading the shadow of the PRPL comprises modifying an address of a PRPL pointer to the PRPL in the command input data to point to the shadow of the PRPL.

14. Method, according to claim 8, characterized by the generation of the shadow of the PRPL from the command input data in the first data structure comprising generating an entry for a shadow of each PRP of the PRPL in the first data structure, the entries for the shadows of each PRP in the first data structure including an address of each PRP of the PRPL from the PRPL and a security context for each PRP from a second data structure.

15. A method according to claim 14, characterized by further comprising: sending the modified command input data to the NVMe device; identifying a second NVMe device transaction to read the PRPL, wherein the generation of the PRPL shadow of the command input data in the first data structure occurs in response to the identification of the second NVMe device transaction; and modifying each PRP of the PRPL to point to the shadow of each PRP, thereby generating a modified PRPL.

16. Method according to claim 15, characterized by further comprising: sending the modified PRPL to the NVMe device; identifying a third transaction on the NVMe device to perform an operation on at least one of the shadows of each PRP; and implementing a cryptographic operation on data associated with at least one of the shadows of each PRP based on the security context associated with at least one of the shadows of each PRP. Petition 870250079875, dated 05 / 09 / 2025, pp. 671 / 684 5 / 17 17. Method, according to claim 8, characterized in that the modification of the command input data to enable reading the shadow of the PRPL comprises removing a reference to an entry for the PRPL in a second data structure.

18. A method according to claim 8, characterized in that the command input data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL, the method further comprising writing the PRPL pointer in the second data structure at a location associated with the reference to the entry in the second data structure.

19. A method according to claim 1, characterized in that the modified command input data includes a virtual address, the method further comprising searching for a virtual address for mapping from a physical address to the virtual address in parallel with generating the shadow of at least one PRP of the command input data in the first data structure.

20. Method, according to claim 1, characterized by identifying the first transaction of the NVMe device to read the command input from the command send queue, understanding and identifying a transaction address that is within at least one range of addresses for at least one send queue, to at least one range of addresses stored in an online cryptographic module configuration register.

21. A method for providing cryptographic functions for data in a non-volatile express memory (NVMe) protocol executed by a processing system, characterized by comprising: acquiring a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; writing a cryptographic enablement for a command input of the Petition 870250079875, dated 05 / 09 / 2025, page 672 / 684 6 / 17 command to a send queue; writing the cryptographic key slot reference for the command input to the send queue; and sending the command input with the cryptographic enablement and the cryptographic key slot reference to the send queue.

22. A method according to claim 21, characterized by further comprising: acquiring a page-level read / write pointer lookup table (PRPLT) slot for the command of an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; and writing the PRPLT slot reference to the command input of the command to the send queue, wherein sending the command input of the command with the cryptographic enablement and the cryptographic key slot reference to the send queue comprises sending the command input of the command including the cryptographic enablement, the cryptographic key slot reference and the PRPLT slot reference to the send queue.

23. A method according to claim 21, characterized in that: the command has more than one page-level read / write pointer (PRP); the method further comprises writing a logical block address offset to part of at least one PRP of the command input to the send queue; and sending the command input with the cryptographic enable and cryptographic key slot reference to the send queue comprising sending the command input including the cryptographic enable, the cryptographic key slot reference and at least one PRP with a logical block offset.

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

25. A method according to claim 21, characterized in that: the command data is larger than two system memory pages; the method further comprises writing a PRPL pointer in the command input to the send queue in a location for a PRP; and sending the command input with the cryptographic enable and cryptographic key slot reference to the send queue comprising sending the command input with the cryptographic enable, the cryptographic key slot reference, and the PRPL pointer.

26. A method according to claim 21, characterized in that the command data is larger than a number of system memory pages that can be referenced by a PRP and a PRPL, the method further comprising writing a pointer from PRPL to a PRP of a PRPL.

27. A method according to claim 21, characterized by further comprising: configuring a first set of one or more records of an online cryptographic module corresponding to a number of command sending queues; and defining each of the first set of one or more records with a range of addresses from a different command sending queue.

28. Method, according to claim 27, characterized by the definition of each record of the first set of one or more records with the address range of a command sending queue different from the command sending queues comprising the definition of each record of the first set of one or more records with a starting address and a size of a command sending queue different from the command sending queues.

29. Method, according to claim 27, characterized in that the definition of each record of the first set of one or more records with the address range of a command sending queue different from the command sending queues comprises the definition of each record of the first set of one or more records with a starting address and a ending address of a command sending queue different from the command sending queues.

30. A method according to claim 27, characterized by further comprising: configuring a second set of one or more records of the online cryptographic module corresponding to a number of command completion queues; and defining each record of the second set of one or more records with a start address and a size of a command sending queue different from the command sending queues.

31. A method according to claim 27, characterized by further comprising: configuring a second set of one or more records of the online cryptographic module corresponding to a number of unique address ranges; and defining each record of the second set of one or more records with a starting address and a size of a unique address range different from the unique address ranges.

32. Computing device characterized by comprising: a processing system; and a non-volatile Express Memory (NVMe) inline cryptographic module coupled to the processing system, the NVMe inline cryptographic module configured to: identify a first transaction of an NVMe device to read a command input from a command submission queue; read command input data from the command input; generate a shadow of at least one page-level read / write pointer (PRP) of the command input data in a first data structure; and modify the command input data to enable reading the shadow of at least one PRP, thereby generating modified command input data.

33. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to generate an entry for at least one PRP in the first data structure, the entry for at least one PRP in the first data structure including an address of at least one PRP and a security context for at least one PRP from the command input data, to generate the shadow of at least one PRP from the command input data in the first data structure.

34. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to modify an address of at least one PRP in the command input data to point to the shadow of at least one PRP, and to modify the command input data to enable reading the shadow of at least one PRP.

35. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to generate an entry for at least one PRP in the first data structure, the entry for at least one PRP in the first data structure including an address of at least one PRP and a security context for at least one PRP from a second data structure, to generate the shadow of at least one PRP from the command input data in the first data structure.

36. Computing device according to claim 35, characterized in that: the command input data includes a reference to an entry for at least one PRP in the second data structure; and the NVMe online cryptographic module is further configured to read the entry for at least one PRP in the second data structure, including the address of the at least one PRP and the security context for the at least one PRP, from the command input data.

37. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to remove a reference to an entry for at least one PRP in a second data structure to modify the command input data to enable shadow reading of at least one PRP.

38. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to: send the modified command input data to the NVMe device; identify a second NVMe device transaction to perform an operation on the shadow of at least one PRP; and implement a cryptographic operation on data associated with the shadow of at least one PRP based on a security context associated with the shadow of at least one PRP.

39. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is additionally configured to: generate a shadow of a PRP list (PRPL) of the command input data in the first data structure; and modify the command input data to enable reading the shadow of the PRPL, thereby generating the modified command input data.

40. Computing device, according to claim 39, characterized in that the NVMe online cryptographic module is further configured to generate an entry for the PRPL in the first data structure, the entry for the PRPL in the first data structure including an address of the PRPL and a security context for the PRPL from the command input data, to generate the shadow of the PRPL from the command input data in the first data structure.

41. Computing device, according to claim 39, characterized in that the NVMe online cryptographic module is further configured to: send the modified command input data to the NVMe device; identify a second transaction of the NVMe device to read the shadow of the PRPL; generate a shadow of each PRP of the PRPL in the first data structure; and modify each PRP of the PRPL to point to the shadow of each PRP, generating a modified PRPL.

42. Computing device according to claim 41, characterized in that the NVMe online cryptographic module is further configured to generate an entry for each PRP of the PRPL in the first data structure, the entries for each PRP of the PRPL in 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 from an entry of the PRPL in the first data structure, to generate the shadow of each PRP of the PRPL in the first data structure. Petition 870250079875, dated 05 / 09 / 2025, pp. 678 / 684 12 / 17 43. Computing device, according to claim 41, characterized in that the NVMe online cryptographic module is additionally configured to: send the modified PRPL to the NVMe device; identify a third transaction of the NVMe device to perform an operation for at least one of the shadows of each PRP; and implement a cryptographic operation for data associated with at least one of the shadows of each PRP based on the security context associated with at least one of the shadows of each PRP.

44. Computing device, according to claim 39, characterized in that the NVMe online cryptographic module is further configured to modify an address of a PRPL pointer to the PRPL of the command input data to point to the shadow of the PRPL to modify the command input data to enable reading the shadow of the PRPL.

45. Computing device, according to claim 39, characterized in that the NVMe online cryptographic module is further configured to generate an entry for a shadow of each PRP from the PRPL in the first data structure, the entries for the shadows of each PRP in the first data structure including an address of each PRP from the PRPL and a security context for each PRP from a second data structure, to generate the shadow of the PRPL from the command input data in the first data structure.

46. ​​Computing device according to claim 45, characterized in that the NVMe online cryptographic module is further configured to: send the modified command input data to the NVMe device; identify a second transaction of the NVMe device to read the PRPL Petition 870250079875, dated 05 / 09 / 2025, page 679 / 684 13 / 17 and, in response to the identification of the second transaction of the NVMe device, generate the shadow of the PRPL from the command input data in the first data structure; and modify each PRP of the PRPL to point to the shadow of each PRP, thereby generating a modified PRPL.

47. Computing device, according to claim 46, characterized in that the NVMe online cryptographic module is additionally configured to: send the modified PRPL to the NVMe device; identify a third transaction of the NVMe device to perform an operation for at least one of the shadows of each PRP; and implement a cryptographic operation for data associated with at least one of the shadows of each PRP based on the security context associated with at least one of the shadows of each PRP.

48. Computing device, according to claim 39, characterized in that the NVMe online cryptographic module is additionally configured to remove a reference to an entry for the PRPL in a second data structure to modify the command input data to enable reading the shadow of the PRPL.

49. Computing device according to claim 39, characterized in that: the command input data includes a reference to an entry in a second data structure, the entry in the second data structure having a security context for the PRPL; and the NVMe online cryptographic module is further configured to write the PRPL pointer in the second data structure at a location associated with the reference to the entry in the second data structure.

50. Computing device according to claim 32, characterized in that: Petition 870250079875, dated 05 / 09 / 2025, pp. 680 / 684 14 / 17 the modified command input data includes a virtual address; and the NVMe online cryptographic module is additionally configured to fetch a virtual address for mapping from physical address to virtual address in parallel with generating the shadow of at least one PRP of the command input data in the first data structure.

51. Computing device, according to claim 32, characterized in that the NVMe online cryptographic module is further configured to identify a transaction address that is within at least one range of addresses for at least one send queue, to at least one range of addresses stored in a configuration register of the online cryptographic module to identify the first transaction of the NVMe device to read the command input from the command send queue.

52. Computing device characterized by comprising: a non-volatile expressed memory (NVMe) in-line cryptographic module; and a processing system coupled to the NVMe in-line cryptographic module, wherein the processing system is configured to: acquire a cryptographic key slot for a command from a secure process, the cryptographic key slot including a cryptographic key slot reference; write a cryptographic enablement for a command input from the command to a send queue; write the cryptographic key slot reference for the command input from the command to the send queue; and send the command input from the command with the cryptographic enablement and the cryptographic key slot reference to the send queue.

53. Computing device according to claim 52, characterized in that the processing system is further configured to: Petition 870250079875, dated 05 / 09 / 2025, pp. 681 / 684 15 / 17 acquire a page-level read / write pointer lookup table (PRPLT) slot for the command of an inline cryptographic module, the PRPLT slot including a PRPLT slot reference; write the PRPLT slot reference to the command input of the command to the send queue; and send the command input of the command including the cryptographic enablement, the cryptographic key slot reference and the PRPLT slot reference to the send queue to send the command input of the command with the cryptographic enablement and the cryptographic key slot reference to the send queue.

54. Computing device according to claim 52, characterized in that: the command having more than one page-level read / write pointer (PRP); and the processing system being further configured to: write a logical block address offset to part of at least one PRP of the command input to the send queue; and send the command input including the cryptographic enable, the cryptographic key slot reference and at least one PRP having the logical block offset to send the command input having the cryptographic enable and the cryptographic key slot reference to the send queue.

55. Computing device according to claim 52, characterized in that: the command data being larger than two system memory pages; and the processing system being additionally configured to write a logical block address offset to part of at least one PRP from a PRP list (PRPL). Petition 870250079875, dated 05 / 09 / 2025, pp. 682 / 684 16 / 17 56. Computing device according to claim 52, characterized in that: the command data is larger than two system memory pages; and the processing system is further configured to: write a PRPL pointer in the command input to the send queue in a location for a PRP; and send the command input with the cryptographic enable, cryptographic key slot reference, and PRPL pointer to send the command input with the cryptographic enable and cryptographic key slot reference to the send queue.

57. Computing device according to claim 52, characterized in that: the command data is larger than a number of system memory pages that can be referenced by a PRP and a PRPL; and the processing system is further configured to write a PRPL pointer to a PRPL PRP.

58. Computing device, according to claim 52, characterized in that the processing system is further configured to: configure a first set of one or more registers of an inline cryptographic module corresponding to a number of command sending queues; and define each of the first set of one or more registers with a range of addresses from a different command sending queue.

59. Computing device, according to claim 58, characterized in that the processing system is further configured to define each of the first set of one or more records with a different starting address and command sending queue size to define each of the first set of one or more records with the address range of a different command sending queue.

60. Computing device, according to claim 58, characterized in that the processing system is further configured to define each of the first set of one or more records with a different starting address and ending address of a different command sending queue.

61. Computing device according to claim 58, characterized in that the processing system is further configured to: configure a second set of one or more records of the inline cryptographic module corresponding to a number of command completion queues; and define each record of the second set of one or more records with a start address and a size of a command sending queue different from the command sending queues.

62. Computing device, according to claim 58, characterized in that the processing system is further configured to: configure a second set of one or more online cryptographic module registers corresponding to a number of unique address ranges; and define each register of the second set of one or more registers with a starting address and a size of a unique address range different from the unique address ranges.

63. Product, process, system, kit, means or use, characterized by comprising one or more elements described in the descriptive report, claims, drawings, sequence listing, or summary of this application, when applicable. Petition 870250079875, dated 05 / 09 / 2025, pp. 684 / 684