Computing authentication tags for partial transfers scheduled across multiple dma engines

Abstract

This application relates to computing authentication tags for partial transfers scheduled across multiple DMA engines. Devices, systems, and techniques are described for computing an authentication tag for a data transfer when the data transfer is scheduled as a partial transfer across a specified number of direct memory access (DMA) engines. During one or more rounds, an orchestration circuit stores partial authentication tags computed by the DMA engines, and corresponding adjustment exponents, where the partial transfer is scheduled and processed by the specified number of DMA engines. During a final round, a combined authentication tag can be computed based on the partial authentication tags and the corresponding adjustment exponents stored by the orchestration circuit during the rounds.

Description

Technical Field

[0001] At least one embodiment relates to processing resources for performing and facilitating the transfer of confidential data. For example, at least one embodiment relates to hardware circuitry for transferring computed authentication tags for a portion of the data scheduled across a direct memory access (DMA) engine. Background Technology

[0002] Accelerator circuitry includes Direct Memory Access (DMA) circuitry to access system memory independently of the Central Processing Unit (CPU). DMA circuitry can also be used for memory-to-memory copying or moving of data within or between memory locations. When data protection is required, DMA circuitry can implement cryptographic circuitry to encrypt and decrypt data copied from and to secure memory. Multiple DMA engines can be used for high-speed interconnects (e.g., 2.4 TB / s bandwidth, 300 GB / s bidirectional bandwidth) to achieve extremely high data transfer rates. Large transfers can be broken into multiple segments and scheduled across multiple DMA engines to saturate memory or link bandwidth. However, generating authentication tags at such high speeds across multiple DMA engines remains a challenge when confidentiality of transferred data is required. In particular, authentication tag generation is essentially a sequential multiply-accumulate operation, and multiple DMA engines can be physically far apart. Some implementations authenticate each split independently by creating an authentication tag for each block (split) in the encrypted data stream and using a separate initialization vector (IV). However, this increases the memory footprint of using cryptographic hardware and requires additional work on the software driver stack to manage and authenticate each split. Other implementations use one or more additional cryptographic hardware engines for authentication computation, but this incurs additional area overhead. Attached Figure Description

[0003] Figure 1 This is a block diagram of a computing system with accelerator circuitry according to at least some embodiments, the accelerator circuitry including a replication engine that transmits computing authentication tags for portions scheduled across multiple DMA engines.

[0004] Figure 2 It is a block diagram of a replication engine with an accelerator circuit having an orchestration circuit according to at least some embodiments, the orchestration circuit being used to transfer computational authentication tags for portions scheduled across multiple DMA engines.

[0005] Figure 3AThis is a functional diagram illustrating the flow of a single data transfer to be scheduled by a DMA circuit according to at least some embodiments;

[0006] Figure 3B It is a functional diagram of a process in which one of a plurality of logical DMA engines, according to at least some embodiments, schedules a portion of a transfer to a plurality of physical DMA engines.

[0007] Figure 4 A DMA circuit is shown according to at least some embodiments, having a logical replication engine (CE), multiple physical replication engines (PCE), and an orchestration circuit for transmitting computed authentication tags for parts scheduled across multiple PCEs;

[0008] Figure 5 It is a block diagram of a DMA hardware engine that combines partial authentication tags from two cryptographic hardware engines according to at least some embodiments;

[0009] Figure 6 It is a flowchart of encrypted operations for multiple parts to be transmitted across multiple DMA engines, according to at least some embodiments;

[0010] Figure 7 It is a flowchart of a decryption operation for multiple parts of a DMA engine scheduled according to at least some embodiments;

[0011] Figure 8 This is a flowchart illustrating a method for transferring computed authentication tags from multiple parts scheduled across multiple DMA engines, according to at least some embodiments; and

[0012] Figure 9 This is a block diagram of a computing system with an accelerator according to at least some embodiments, the accelerator including a replication engine that transmits computing authentication tags for portions scheduled across multiple DMA engines. Detailed Implementation

[0013] As mentioned above, DMA circuits can be used for memory-to-memory copying or moving of data within memory and can include cryptographic hardware to protect the data. Sequential cryptographic algorithms using sequential operations present challenges when using multiple DMA engines to increase bandwidth. Specifically, the Advanced Encryption Standard Galois Counter Mode (AES-GCM) is an authenticated cryptographic algorithm that performs both encryption and authentication of the data stream. DMA engines supporting AES-GCM can provide secure data transfer for applications requiring confidentiality. AES-GCM is a high-speed authenticated encryption mode that simultaneously generates ciphertext and authentication tags using a counter (CTR) mode and a hash function defined over a binary finite field (e.g., a Galois field (GF) (2^128)). The hash function, which sequentially analyzes the data to compute the message authentication code (called GHASH), uses a general hash function defined over a binary finite field (e.g., GF) to guarantee the authenticity of the confidential data. The finite field is defined by its multiplication and addition operations. These operations follow basic algebraic properties such as commutativity, associativity, and distribution. Both operations map a pair of field elements to another field element. On a polynomial basis, multiplication of two elements involves multiplying the polynomials representing the two elements and then dividing the resulting 256-bit polynomial by the field polynomial; the result is a 128-bit remainder.

[0014] While ciphertext can be generated using parallel AES-GCM hardware engines, generating authentication tags remains a challenge given that the AES-GCM algorithm involves sequential multiply-accumulate operations. Running at high speeds on physically distant DMA engines is even more challenging. As mentioned above, some implementations authenticate each split independently by creating an authentication tag for each segment delivered (split) in the encrypted data stream and using a separate IV. However, this increases the memory footprint of the cryptographic hardware and requires additional work on the software driver stack to manage and authenticate each split. Other implementations use one or more additional cryptographic hardware engines for authentication computation, but this typically incurs additional area overhead.

[0015] Another approach uses data bytes to interleave across physically adjacent parallel AES cores, allowing authentication tags to be computed using a multiplexed structure. However, this approach is typically limited to parallel AES cores that are close to each other and may not work for applications that require software configuration to select the number of parallel DMA engines needed to meet the bandwidth requirements of a given system.

[0016] Multiple aspects and embodiments of this disclosure address these and other challenges by providing a two-pronged hardware solution, wherein a first hardware entity orchestrates encryption and authentication tag computation across multiple DMA engines, and a second hardware entity manages interleaved data across a parallel AES kernel within a single DMA engine. Therefore, multiple aspects of this disclosure can support a configurable number of DMA engines to be grouped for variable data transfer sizes (e.g., 1 byte (B) to 4 gigabytes (GB)). For example, a data transfer can be split into a set of partial transfers (or data transfer portions) of equal size chunks (e.g., 8KB) by scheduler circuitry, where the last chunk can have any size smaller than the others. In at least one embodiment, the DMA engines include a logical DMA engine and multiple physical DMA engines, at least some of which have cryptographic hardware. The logical DMA engine can simplify the software view and offload data transfers scheduled to multiple physical DMA engines. Large transfers can be split into partial transfers (e.g., 8KB) by scheduler circuitry, and the logical DMA engine can schedule partial transfers to all available physical DMA engines to saturate memory or link bandwidth. Logical DMA engines can load balance partial transfers among available DMA engines and use round-robin arbitration. In other embodiments, other scheduling algorithms may be used.

[0017] Encryption keys and IVs can be assigned to contexts. Before the physical DMA engines perform cryptographic operations, the logical DMA engine can exchange encryption keys and IVs with multiple physical DMA engines during the context binding process. In some embodiments, a context binding latency is used to pre-compute the multiplier exponent, which is a function of the split size and the number of configured physical DMA engines. A GF multiplier can be used with a low-latency binary exponentiation method to pre-compute the multiplier exponent. The split size and the number of physical DMA engines are known at context binding time, allowing the multiplier exponent to be pre-computed and securely stored for use in cryptographic operations. This allows GHASH to be computed during data transfer without pausing the data cycle. The time during context switching can be used to generate key rounds and GHASH multipliers, which are functions of the key. Each engine can compute multiple multipliers based on the split size and the number of DMA engines during the context binding latency. The multiplier exponents can be stored securely to prevent data leakage. Each engine receives an IV that increments for each replication split. This ensures that the correct counter value is used to encrypt plaintext or decrypt ciphertext using AES-GCM. Each engine can generate encrypted data for its respective split, and each engine can independently calculate the partial authentication tag for the split length. At the end of a round where all physical DMA engines, defined as all mappings, complete a split transfer, a multiplier exponent is determined for each DMA engine. This multiplier exponent is used to multiply the partial authentication tag to adjust for data bytes affected by other physical DMA engines. As the exponent is multiplied by the partial authentication tag from each engine, the engine can proceed to the next split. Rounds can continue until a lost replication split is issued. At the end of the data transfer, the partial authentication tags from all engines can be combined, and the entire message length can be contained in the combined authentication tag. The tag can be encrypted using a pre-incrementing IV to generate an eventually consistent authentication tag. DMA engines may be preempted; in this case, the adjusted authentication tag can be saved to secure storage (e.g., secure SRAM).

[0018] When the transfer is scheduled again later, the authentication tag can be recovered from secure storage, and GHASH computation can continue. In this way, the accelerator circuitry can use multiple DMA engines and transfer computational authentication tags for portions scheduled across multiple DMA engines. The accelerator circuitry can be a graphics processing unit (GPU), deep learning accelerator (DLA) circuitry, intelligent processing unit (IPU), neural processing unit (NPU), tensor processing unit (TPU), neural network processor (NNP), data processing unit (DPU), vision processing unit (VPU), application-specific integrated circuit (ASIC), or field-programmable gate array (FPGA). The accelerator circuitry can address the computational needs of the neural network inference phase by providing building blocks that accelerate core deep learning operations. For example, deep learning accelerators can be used to accelerate different neural networks, such as convolutional neural networks (CNNs), recurrent neural networks (RNNs), fully connected neural networks, and so on.

[0019] Accelerator circuits can be scheduled by a host central processing unit (CPU) coupled to the accelerator circuit. Alternatively, accelerator circuits can be scheduled locally by firmware to ensure minimal latency. Accelerator circuits can be used in different types of layers in these neural networks, such as fixed-function engines for convolution, activation functions, pooling, batch normalization, etc. It should be noted that from an algorithmic perspective, neural networks can be specified using a set of layers (referred to as “raw layers” in this paper), such as bias and batch normalization. These raw layers can be compiled or transformed into another set of layers (referred to as “hardware layers” in this paper), where each hardware layer is used as a basic element for scheduling to execute on the accelerator circuit. The mapping between raw layers and hardware layers can be m:n, where m is the number of raw layers and n is the number of hardware layers. For example, in a neural network, raw layer bias, batch normalization, and local response normalization (LRN), such as rectified linear units (ReLU), can be compiled into a single hardware layer. In this case, m:n is 3:1. Each hardware layer can be represented by basic hardware instructions from the accelerator circuitry for performing operations, and each layer can communicate with another layer via a memory interface. For example, a first fixed-function engine in the DLA circuitry can execute the first layer (which receives input tensors), perform operations on the input tensors to generate an output tensor, and store the output tensor in system memory, such as dynamic random-access memory (DRAM) coupled to the accelerator. A second fixed-function engine can execute the second layer, which receives the output tensor from the first layer as a second input tensor from memory, performs operations on the second input tensor to generate a second output tensor, and stores the second output tensor in DRAM. Each communication introduces tensor read and tensor write operations in the memory interface.

[0020] Therefore, multiple aspects of this disclosure allow the use of multiple cryptographic hardware engines while simultaneously transmitting computed authentication tags for portions scheduled across multiple DMA engines, although the transmission sizes may differ. Multiple aspects of this disclosure eliminate the need for transmissions to be software-split and pre-encrypted individually, which would generate multiple authentication tags for each split. Multiple aspects of this disclosure can generate a consistent authentication tag across physically distant DMA engines and allow software to program any number of DMA engines required by the system or application. Multiple aspects of this disclosure do not require an additional AES kernel to combine GHASH across multiple engines.

[0021] Figure 1 This is a block diagram of a computing system 100 with accelerator circuitry 102 according to at least some embodiments. Accelerator circuitry 102 includes a replication engine 120 that performs partial transfer of computational accuracy tags for scheduling across multiple DMA engines. The computing system 100 is considered a headless system, where cell-by-cell management of accelerator circuitry 102 occurs on a main system processor CPU 104. Accelerator circuitry 102 includes an interrupt interface 106, a configuration space bus (CSB) interface 108, a main data bus interface 110 (data backbone interface (DBBIF)), a secondary data bus interface 112, and replication engine (CE) 120, as described in more detail below. CPU 104 and accelerator circuitry 102 are coupled to system memory 114 (e.g., DRAM). Accelerator circuitry 102 is coupled to system memory 114 via main data bus interface 110. Accelerator circuitry 102 may be coupled to secondary memory 116, such as video memory (DRAM and / or SRAM), via secondary data bus interface 112. CSB interface 108 can be a control channel interface that implements register files (e.g., configuration registers) and interrupt interfaces. In at least one embodiment, CSB interface 108 is a synchronous, low-bandwidth, low-power, 32-bit control bus designed for CPU 104 to access configuration registers in accelerator circuitry 102. The interrupt interface can be a 1-bit level-driven interrupt. An interrupt line can be asserted when a task completes or an error occurs.

[0022] The accelerator circuit 102 may also include a memory interface block that interfaces with the memory using one or more bus interfaces. In at least one embodiment, the memory interface block uses a main data bus interface 110 connected to system memory 114. System memory 114 may include DRAM. The main data bus interface 110 may be shared with the CPU and input / output (I / O) peripherals. In at least one embodiment, the main data bus interface 110 is a data backbone (DBB) interface connecting the accelerator circuit 102 and other memory subsystems. The DBB interface is a configurable data bus that can specify different address sizes, different data sizes, and issue requests of different sizes. In at least one embodiment, the DBB interface uses an interface protocol, such as AXI (Advanced Extensible Interface) or other similar protocols. In at least one embodiment, the memory interface block uses an auxiliary data bus interface 112 connected to an auxiliary memory 116 dedicated to the accelerator circuit 102. The auxiliary memory 116 may include DRAM. The auxiliary memory 116 may be video memory. The accelerator circuit 102 may also include a memory interface connected to a higher bandwidth memory dedicated to the accelerator circuit 102. The memory can be an on-chip SRAM used to provide higher throughput and lower access latency.

[0023] For example, during inference, a typical process begins with a management processor (microcontroller or CPU) coupled to accelerator circuitry 102 sending hardware layer configuration and activation commands. If data dependencies do not preclude this, multiple hardware layers can be sent to different engines and activated simultaneously (e.g., if the input of another layer does not depend on the output of the previous layer). In at least one embodiment, each engine may have a double buffer for its configuration register, which allows the configuration of a second layer to begin processing when the active layer completes. Once a hardware engine has completed its active task, accelerator circuitry 102 can interrupt the management processor to report completion, and the management processor can restart the process. This command-execution-interrupt flow repeats until the inference of the entire network is complete. In at least one embodiment, an interrupt interface may signal that replication is complete. In another embodiment, semaphore release (typically a flag written to system memory that the CPU thread is polling) can be used to let the software know that the workload has been completed.

[0024] Figure 1The computing system 100 represents a more cost-sensitive system for the cell-by-cell management of the accelerator circuitry 102 than a computing system with a dedicated controller or coprocessor. The computing system 100 can be considered a small-scale system model. Small-scale system models can be used for cost-sensitive connected Internet of Things (IoT) devices, artificial intelligence (AI), and task-oriented automation systems where cost, area, and power are primary drivers. Cost, area, and power savings can be achieved through the configurable resources of the accelerator circuitry 102. Neural network models can be pre-compiled and their performance can be optimized, allowing for larger models to be reduced in terms of load complexity. In turn, the reduced load complexity allows DLA implementations to scale down, where models consume less storage space and require less time for system software to load and process. In at least one embodiment, the computing system 100 can execute one task at a time. Alternatively, the computing system 100 can execute multiple tasks simultaneously. For the computing system 100, context switching does not cause the CPU 104 to be overloaded by servicing numerous interrupts from the accelerator circuitry 102. This eliminates the need for an additional microcontroller, and CPU 104 performs memory allocation and other subsystem management operations. As described herein, accelerator circuitry 102 includes a replication engine 120 that calculates authentication tags for partial transfers scheduled across multiple DMA engines. Replication engine 120 includes orchestration circuitry 122 that can manage encryption and authentication tag calculations across multiple DMA engines. In at least one embodiment, orchestration circuitry 122 can store partial authentication tags for each partial transfer and adjustment indices for each partial transfer. Orchestration circuitry 122 can calculate authentication tags for data transfers based on partial authentication tags and corresponding adjustment indices. Further details of replication engine 120 will be referenced below. Figures 2-4 Describe it.

[0025] Figure 2 This is a block diagram of a replication engine 120 of an accelerator circuit according to at least some embodiments, the accelerator circuit having orchestration circuitry 122 for calculating authentication tags for partial transfers scheduled across multiple DMA engines. The replication engine 120 includes a hardware scheduler circuitry 202 (labeled ESCED for engine scheduler) and a direct memory access (DMA) circuitry 204. The hardware scheduler circuitry 202 is coupled to auxiliary memory 206 and the DMA circuitry 204. The DMA circuitry 204 is coupled to a memory management unit (MMU) 230, which is coupled to system memory (…). Figure 2(Not shown in the image). MMU 230 can provide routing functionality between system memory and accelerator circuitry. MMU 230 can provide paths for all engines on the accelerator (including replication engine 120) to access any location in memory (e.g., video memory, system memory, etc.). MMU 230 can perform access checks to allow only authorized access via the interface. MMU 230 can restrict and report unauthorized access. DMA circuitry 204 includes cryptographic circuitry that implements certified encryption algorithms to encrypt data retrieved from secure memory or decrypt received data to be stored in secure memory. In at least one embodiment, as... Figure 2 As shown, DMA circuitry 204 includes a logical replication engine (LCE) 208 coupled to LCE 208 and multiple physical replication engines (PCEs) 210. In other embodiments, DMA circuitry 204 includes multiple LCEs and multiple PCEs. LCE 208 may include secure memory 212 that may store encrypted IVs, block counters, and hash keys in each channel key slot. Each channel key slot, which may be assigned to an application, may store the application's context in a designated slot within secure memory 212. LCE 208 may also include a secure dedicated interface 214 for receiving configuration information, encryption and decryption keys, an IV random number generator, and secure SRAM programming from a secure hub or other secure circuitry managing private keys. In at least one embodiment, the encryption and decryption keys and IVs are generated by a random number generator from a secure processor on the GPU.

[0026] In at least one embodiment, such as Figure 2As shown, PCE 210 includes front-end circuitry 216, a read pipeline 218, a write pipeline 220, and cryptographic circuitry 222 providing secure data transfer for applications requiring confidentiality. In at least one embodiment, cryptographic circuitry 222 is an AES-GCM hardware engine implementing AES256-GCM cryptography. In at least one embodiment, cryptographic circuitry 222 is an AES-GCM circuit. Alternatively, cryptographic circuitry 222 may implement cryptographic algorithms in other sequences, where the underlying cryptographic hardware is shared among multiple users (e.g., multiple applications in a time-sliced ​​manner). For example, the cryptographic hardware may be shared by multiple users in a cloud infrastructure. For another example, the cryptographic hardware can be used in a virtualization environment where a hypervisor allows the underlying hardware to support multiple guest virtual machines (VMs) by virtually sharing its resources (including accelerator circuitry 120). In another embodiment, DMA circuitry 204 includes LCE 208, a first PCE 210, and a second PCE. The first PCE 210 is coupled to the LCE 208 and includes a cryptographic circuit 222, a first read pipeline 218, and a write pipeline 220. The second PCE is coupled to the LCE 208 and includes a second cryptographic circuit, a second read pipeline, a second write pipeline, and a second front-end circuit. In at least one embodiment, the second cryptographic circuit is a second AES-GCM circuit. Each additional PCE may include a front-end circuit, a read pipeline, a write pipeline, and a cryptographic circuit.

[0027] In at least one embodiment, the replication engine 120 can decrypt data related to the data transfer. To decrypt the data transfer, a context is loaded (CTX LOAD) onto LCE 208, the context having a valid SRAM index pointing to a slot in secure memory 212 allocated to the application. The key indicated in the slot of secure memory 212 is loaded onto cryptographic circuitry 222 (AES hardware engine). During encryption operations, the first PCE 210 reads from protected memory (e.g., video memory), internally decrypts the data using cryptographic circuitry 222, and writes the decrypted data to an unprotected area (e.g., system memory or video memory). In at least one embodiment, the replication engine 120 can decrypt data related to the data transfer. To decrypt the data transfer, a context is loaded (CTX LOAD) onto LCE 208, the context having a valid SRAM index pointing to a slot in secure memory 212 allocated to the application. The key indicated in the slot of secure memory 212 is loaded onto cryptographic circuitry 222 (AES hardware engine). During the decryption operation, the first PCE 210 reads from an unprotected memory (e.g., in system memory or video memory), decrypts the data internally using cryptographic circuitry 222, and writes the decrypted data to a protected area (e.g., video memory).

[0028] In at least one embodiment, the IV is 96 bits and contrasts with two components: a 64-bit channel counter with a unique identifier for each channel and a 32-bit message counter that starts at zero and is incremented with each encryption / decryption at the start of channel (SOC). The 96-bit RNG mask is a key mask stored in Secure PRI. The copy IV (COPY_IV) is RNGXOR[CHANNEL_CTR,++MSG_CTR]. The copy engine can detect that the maximum number of copies of the IV has been exceeded by detecting whether the MESSAG_CTR+1 value used in the COPY_IV construction is zero. The copy engine 120 keeps track of the encrypted IV used in each encrypted copy and performs pre-incrementing and save-and-restore operations based on SRAM. The encrypted IV is passed to the cryptographic circuit 222 after being XORed with the RNG in the decryption IV method of each copy. The IV stored in SRAM is reflected based on the completion of the copy. The replication engine 120 can have multiple encrypted copies visible to the PCE and maintain two counters, including the IVs that should be sent on network-encrypted copies and the last completed copy. In context saving (CTXT_SAVE), the IV from the last copy is saved to SRAM. The IV used for decryption is stored in the instance block and passed to the replication engine 120 via the decryption IV method during decryption copying. If MESSAGE_CTR = 0, the replication engine 120 can detect overflows and interrupts. The replication engine 120 can perform an XOR operation with the correct RNG before passing the decrypted IV from the LCE to the front-end circuitry 216.

[0029] In at least one embodiment, the replication engine 120 includes a security-dedicated interface 214. The security-dedicated interface 214 is accessible to security software to provide security configurations or keys and to query interrupt status for encryption and decryption. The replication engine 120 can connect as a client to the security hub 224, allowing the dedicated on-chip security processor (SEC2) 226 and the GPU system processor (GSP) 228 to access the security-dedicated interface 214, but not BAR0. The GSP 228 can be used to offload GPU initialization and management tasks. The SEC2 226 manages encryption keys and other security information used by the accelerator circuitry 100.

[0030] In at least one embodiment, the secure memory 212 is a secure SRAM with N entries (e.g., 512 entries), each entry having a valid bit. Each entry has lower and higher 128-bit components. The lower component may include a first encrypted IV counter, a second encrypted IV counter, an IV channel identifier, one or more key indices, preemption information, and a block counter. The higher component may include a first authentication tag, a second authentication tag, a third authentication tag, and a fourth authentication tag. The secure SRAM can be programmed via registers through the secure dedicated interface 214. The SRAM can support read, write, and invalidation functions. When the lower 128 bits of a 256-bit entry are programmed by the SEC2 226 / GSP 228, the SRAM index can be marked as valid. An attempt to read an invalid SRAM entry can return 0x0 in the data register. In the event of a fatal error, the state of the SRAM cannot be guaranteed to be valid. The replication engine 120 can automatically invalidate the SRAM index in the event of a fatal error, thus requiring software to reprogram the SRAM index.

[0031] During operation in at least one embodiment, hardware scheduler circuit 202 receives a first descriptor of a first data transfer of a first size associated with a first application. The first size may represent the full copy size of the first data transfer. The first descriptor specifies a first index in secure memory 212 corresponding to the first application. Hardware scheduler circuit 202 splits the first data transfer into a first set of portions. Each portion should be less than or equal to the first size and needs to be completed before context switching to another application. For example, each of the multiple portions may be 8KB. Alternatively, other sizes may be used. These portions may be chunks, partial transfers, or partial copies, which together constitute a full copy of the first data transfer. Once hardware scheduler circuit 202 has scheduled the set of partial transfers, LCE 208 schedules the first partial transfer to first PCE 210(1) and stores a first adjustment index in buffer 232, which is associated with first PCE 210(1) in orchestration circuit 122. First PCE 210(1) generates encrypted data for the first partial transfer, calculates a first partial authentication tag for the length of the first partial transfer, and stores the first partial authentication tag in buffer 232. LCE 208 schedules the second part of the transmission to the second PCE 210(2) and stores the second adjustment index in buffer 232. The second PCE 210(2) generates encrypted data for the second part of the transmission, calculates a second part authentication tag for the length of the second part of the transmission, and stores the second part authentication tag in buffer 232. The first part authentication tag and the first adjustment index can be stored in a first first-in-first-out (FIFO) buffer associated with the first PCE 210, and the second part authentication tag and the second adjustment index can be stored in a second FIFO buffer associated with the second PCE 210. There can be M PCEs, and LCE 208 can schedule M part transmissions similar to the above.

[0032] In at least one embodiment, the orchestration circuit 122 calculates a first authentication tag for the first data transmission based at least on a first adjustment index, a first partial authentication tag, a second adjustment index, and a second partial authentication tag. If there are M PCEs, the orchestration circuit 122 calculates the first authentication tag for the first data transmission based on the M adjustment indices and the M partial authentication tags.

[0033] In at least one embodiment, the following equation illustrates the computation of authentication tags for the entire message and split messages across M engine sets. As can be seen, this can be extended to any number of engines. Assuming a split size of B 16B blocks (AES-CTR uses 16B as the block size) and a message with N splits, where the last split can have any number of bytes, the sequence tag equation T is expressed as follows:

[0034]

[0035] Where H is the multiplier equal to the encrypted value of IV (e.g., 128'h0 using the session key). It is important to note that the multiplication "*" operation and the addition "+" operation are performed on the GF binary field.

[0036] In at least one embodiment, the equations for parallel tag computation across M DMA engines are expressed as follows:

[0037]

[0038] In at least one embodiment, multiple AES cores (data path width in bytes / 16B) can be used within each DMA engine, depending on the data path width. As described herein, each PCE 210 may include two AES cores, but no additional AES cores are required to compute the authentication tag. Figure 5 As described, the 16B in the replication split is interleaved across two AES cores. The required multiplier exponent is derived from the number of parallel AES cores in each DMA engine.

[0039] In at least one embodiment, DMA circuit 204 includes a GF multiplier 234. DMA circuit 204 can use the GF multiplier 234 to calculate (and in some cases pre-calculate) a multiplier exponent based on the split size of the partial transfer set. In at least one embodiment, orchestration circuit 122 can cause the GF multiplier 234 to calculate the multiplier exponent to calculate the authentication tag used for data transfer. In another embodiment, LCE 208 can cause the GF multiplier 234 to calculate the multiplier exponent.

[0040] In at least one embodiment, LCE 208 is assigned an encryption key and a first IV for a first data transfer in a given context. LCE 208 exchanges the encryption key and the first IV with multiple PCEs 210 during the context binding process. In some cases, the key does not change during the lifespan of the data transfer context. DMA circuitry 204 uses the encryption key and the first IV to calculate the multiplier exponent during the context binding delay period via PCE 210. In another embodiment, the multiplier exponent can be calculated as needed, such as when there is insufficient storage space to store a pre-calculated multiplier exponent. In at least one embodiment, LCE 208 schedules partial transfers across available PCEs 210. In at least one embodiment, LCE 208 can load balance partial transfers across available PCEs 210 using a round-robin scheduling scheme. In other embodiments, other scheduling schemes can be used. In at least one embodiment, each PCE includes a round key generator, two encryption engines, and two GF multipliers. In some cases, orchestration circuitry 122 may reuse one of the GF multipliers for calculating or pre-calculating the multiplier exponent described herein. In other embodiments, orchestration circuitry 122 uses a separate GF multiplier. It should be noted that the software may preferably use a unique key for each context. The unique key can be designated by the software as a session key. Multiple contexts (ses) are supported. The session key remains constant throughout the context. The key changes after a context is switched. Each context also has an assigned IV. This IV is incremented for each encrypted message during the context (block counter portion). It should be noted that the block counter increments once for the entire message. If the message is split (which is done in hardware), the block counter does not increment for each split, as described below.

[0041] In at least one embodiment, each of the PCEs 210 receives the value of a block counter from the LCE 208. The LCE 208 may increment the block counter for each of the partial deliveries scheduled to one of the PCEs 210. Each of the PCEs 210 uses at least an encryption key, a first IV for data delivery, and the value of the block counter to generate encrypted data for the corresponding partial delivery. Each PCE 210 calculates a partial authentication tag for the length of the corresponding partial delivery and stores the partial authentication tag in a buffer 232 of the orchestration circuit 122. As shown in the equations above, an adjustment exponent is applied to each of the DMA engines. The adjustment exponent is a multiplier exponent that is a function of the split size of the partial delivery and the number of configured PCEs 210. In at least one embodiment, the orchestration circuit 122 calculates a first product of a first adjustment exponent and a first partial authentication tag, and calculates a second product of a second adjustment exponent and a second partial authentication tag. The orchestration circuit 122 combines the first product and the second product to obtain a first result. The orchestration circuit 122 may combine other products corresponding to other PCEs 210 as needed. At the end of the transmission, the orchestration circuit 122 combines the length of the data transmission with at least the result to obtain a combined authentication tag. The orchestration circuit 122 encrypts the combined authentication tag using a first IV to generate an authentication tag for the first data transmission.

[0042] Figure 3A This is a functional diagram of a single data transfer process 300 scheduled by a DMA circuit according to at least some embodiments. A push buffer 302 allocated to the application is stored in auxiliary memory 206. Figure 3A (Not shown in the image). Push buffer 302 may include multiple data transfers 304, 306 (also known as single-copy DMA) and a semaphore acquisition mechanism 308. The push buffer includes specifications for the operations that the GPU context will perform for a particular client. The push buffer is stored in memory. Software can place the semaphore acquisition mechanism 308 at the end of the push buffer 302 and have the engine release the semaphore. Push buffer 302 may also store indices assigned to locations where the IV, KEY, and partial authentication tag are stored in secure memory 212 during encryption or decryption.

[0043] During the application's time slice, hardware scheduler circuitry 202 (ESCED) receives a first application descriptor from push buffer 302 for a first data transfer 304. Hardware scheduler circuitry 202 includes a copy splitter 310 that splits the first data transfer 304 (single copy DMA) into a set of partial transfers 312. Each partial transfer 312 has a fixed size (e.g., 8KB) that should be less than or equal to the size of the first data transfer (e.g., 1GB). Each partial transfer 312 is required to complete before a context switch to another application begins. Each partial transfer 312 (e.g., an 8KB copy) contains a binary descriptor represented by one or more methods. LCE 208 receives the partial transfers 312 from hardware scheduler circuitry 202, and LCE 208 schedules a subset of the partial transfers 312 to be executed on PCE 210 during the time slice. In some cases, hardware scheduler circuitry 202 sends only a subset of the partial transfers 312 to LCE 208 for execution during the time slice. In at least one embodiment, LCE 208 schedules a first partial transfer using a first PCE 210(1), schedules a second partial transfer using a second PCE 210(2), and so on, up to the m-th PCE 210(m), where m represents the number of PCEs used for data transfer allocation. Each PCE 210 performs its respective scheduled partial transfer to generate encrypted data and a partial authentication tag. The partial authentication tag is stored by orchestration circuitry 122. Orchestration circuitry 122 calculates an adjustment exponent using GF multiplier 234. Orchestration circuitry 122 calculates an authentication tag using the partial authentication tag and the adjustment exponent described herein. It should be noted that... Figure 3A Only data transfers for a single application are shown. Hardware scheduler circuitry 202 can receive data transfers from other push buffers corresponding to other applications. It should also be noted that LCE 208 is not necessarily shared between multiple users in different time slices. In some embodiments, PCE 210 is shared among multiple LCEs, for example, regarding... Figure 3B As shown and described.

[0044] Figure 3BThis is a functional diagram of process 350, which transmits a scheduling portion of one of a plurality of logical DMA engines to a plurality of physical DMA engines according to at least some embodiments. In this embodiment, the accelerator circuitry includes n LCEs 208 (e.g., 8) and m PCEs 210 (e.g., 8). Each LCE 208 can be mapped to one or more PCEs 210. During operation, a first LCE 208 (1) can be scheduled to perform a first data transfer using the m PCEs 210. The first LCE 208 (1) assigns an encryption key to each context and an IV to each data transfer. The encryption key and the first IV can be received from the SECHUB via a secure private interface. The first LCE 208 (1) can context-bind the first encryption key and the first IV to the cryptographic circuits 222 (1)-222 (m) of the plurality of PCEs 210 (1)-210 (m). This can be accomplished via a secure interface between the first LCE 208 (1) and each of the cryptographic circuits 222 (1)-222 (m). The first LCE 208(1) can communicate with each of the plurality of PCEs 210(1)-210(m) through a separate interface, different from the secure interface between the first LCE 208(1) and the cryptographic circuits 222(1)-222(m). Each of the cryptographic circuits 222(1)-222(m) has a secure interface to the orchestration circuit 122. Once the cryptographic circuit 222 has calculated a partial authentication tag, it stores the partial authentication tag in the orchestration circuit 122, for example, in a FIFO buffer associated with the respective cryptographic circuit 222. In at least one embodiment, the accelerator circuit can pre-calculate the multiplier exponent during the delay of the first encryption key and the first IV being context-bound to the plurality of PCEs 210(1)-210(m).

[0045] In at least one embodiment, the first LCE 208(1) uses a block counter to transmit an incrementing value of the first IV for each scheduled portion. For example, a first value of the first IV is provided to the first cryptographic circuit 222(1), and the incrementing value of the first IV is provided to the second cryptographic circuit 222(2), and so on, up to the m-th cryptographic circuit 222(m) in the first round. If more rounds are needed, the incrementing value is provided to the first cryptographic circuit 222(1), and so on, until no more rounds are needed. Each of the cryptographic circuits 222(1)-222(m) uses at least the first encryption key, the first IV, and the corresponding value of the block counter to generate encrypted data for the transmission of the corresponding portion. Each of the cryptographic circuits 222(1)-222(m) calculates a partial authentication tag 350(1)-350(m) for the length of the transmission of the corresponding portion. The orchestration circuit 122 calculates an authentication tag 352 using the partial authentication tags 350(1)-350(m). As described herein, orchestration circuit 122 calculates the first product of a first adjustment index and a first partial authentication tag 350(1), the second product of a second adjustment index and a second partial authentication tag 350(2), and so on, up to the m-th product of the m-th adjustment index and the m-th partial authentication tag 350(m). Orchestration circuit 122 combines the first product, the second product, and so on, up to the m-th product to obtain a first result. This process may continue for one or more rounds. Orchestration circuit 122 combines the length of the first data transmission with at least the first result to obtain a combined authentication tag. Orchestration circuit 122 encrypts the combined authentication tag using a first IV to generate an authentication tag 352 for the first data transmission. Authentication tag 352 may be provided to LCE 208(1).

[0046] Subsequently, a second LCE 208(2) can be scheduled to perform a second data transfer using m PCEs 210 (or fewer than m). The second LCE 208(2) can send a second encryption key and a second IV assigned to the allocated PCEs 210 for the second data transfer. The PCEs 210 and orchestration circuit 122 can operate in a similar manner to those described above to calculate a second authentication tag for the second data transfer, and the second authentication tag can be fed back to the second LCE 208(2). Similarly, other LCEs can be scheduled to perform the operation using one or more of the multiple PCEs 210.

[0047] In at least one embodiment, preemption is supported by accelerator circuitry. The context can be preempted before the encrypted replication operation is complete. In this case, the replication state and a partial authentication tag are stored in secure storage during preemption. This state is restored when the context is rescheduled.

[0048] Figure 4A DMA circuit 400 is shown according to at least some embodiments, having an LCE 208, multiple PCEs 210, and an orchestration circuit 122 for calculating authentication tags for partial transfers scheduled across multiple PCEs. The orchestration circuit 122 includes multiple FIFO buffers, including a first FIFO 402 associated with a first PCE 210(1), a second FIFO 404 associated with a second PCE 210(2), and an m-th FIFO buffer 406 associated with the m-th PCE 210(m). Each copy is split into B blocks, each block being 16 bytes. For example, if there are 512 blocks, the size of the copy split is approximately 8KB. As described herein, a copy operation (e.g., a data transfer) can be split into multiple copy splits (partial transfers). During the first round, LCE 208 can assign the first copy split 401 to the first PCE 210(1), the second copy split 403 to the second PCE 210(2), and the m-th copy split 405 to the m-th PCE 210(m). LCE 208 can store the first adjustment index 407 in the first buffer 402, the second adjustment index 409 in the second FIFO buffer 404, and the m-th adjustment index 411 in the m-th FIFO buffer 406. The first PCE 210(1) calculates the first tag 413 and stores the first tag 413 in the first FIFO buffer 402 through the first PCE tag interface 415 between the first PCE 210(1) and the orchestration circuit 122. The second PCE 210(2) calculates the second tag 417 and stores the second tag 417 in the second FIFO buffer 404 through the second PCE tag interface 419 between the second PCE 210(2) and the orchestration circuit 122. The m-th PCE 210(m) calculates the m-th tag 421 and stores the m-th tag 421 in the m-th FIFO buffer 406 through the m-th PCE tag interface 423 between the m-th PCE 210(m) and the orchestration circuit 122. The orchestration circuit 122 may request the GF multiplier 234 to calculate or pre-calculate the multiplier exponent 425 required for calculating the authentication tag. The orchestration circuit 122 may request the GF multiplier 234 to calculate or pre-calculate the multiple of B (e.g., 512) required for calculating the first round authentication tag 427. For example, H represents the multiplier exponent. The 128-bit value of h0 is the encrypted value of the IV. The GF multiplier 234 can calculate or pre-calculate powers of 2 of multipliers H^2, H^4, ..., H^B (e.g., 512). The GF multiplier 234 can calculate or pre-calculate multiples of B (e.g., H^512, H^1024, ...). After the first round, the orchestration circuit 122 can calculate the first-round authentication tag 427.

[0049] During the second round, LCE 208 can allocate the (m+1)th copy split to the first PCE 210(1), the (m+2)th copy split to the second PCE 210(2), and the 2mth copy split 405 to the mth PCE 210(m). LCE 208 can store the various adjustment exponents in FIFO buffers. The first PCE 210(1) calculates the (m+1)th tag and stores it in the first FIFO buffer 402. The second PCE 210(2) calculates the (m+2)th tag and stores it in the second FIFO buffer 404. The mth PCE 210(m) calculates the 2mth tag and stores it in the mth FIFO buffer 406. The orchestration circuit 122 can request the GF multiplier 234 to calculate or pre-calculate the multiplier exponent 425 required for the authentication tag. The orchestration circuit 122 can request the GF multiplier 234 to calculate or pre-calculate a multiple of B (e.g., 512) required to calculate the second-round authentication tag 429. After the second round, the orchestration circuit 122 can calculate the second-round authentication tag 429. This process can be repeated until all replication splits have been scheduled, and a tag is calculated for each replication split in one or more rounds as described above. In the final round, the orchestration circuit 122 can calculate the authentication tag used for replication operations.

[0050] As described above, each of the PCE 210 (or physical DMA engine) can include one or more cryptographic hardware engines (e.g., two AES-GCM cores). For example, each PCE may have a 32-byte data path per clock cycle and include two 16-byte AES-GCM cores. In addition to computing authentication tags for partial transfers scheduled across multiple PCEs, the PCE may also include hardware entities that manage interleaved data across parallel AES-GCM cores within a single PCE, such as... Figure 5 As shown in the image.

[0051] Figure 5This is a block diagram of a DMA hardware engine 500 according to at least some embodiments, which combines partial authentication tags from two cryptographic hardware engines 502, 504 (e.g., AES-GCM hardware engines). The DMA hardware engine 500 includes a first cryptographic hardware engine 502 adjacent to the second cryptographic hardware engine 504. The first cryptographic hardware engine 502 receives a first IV and a first value of a block counter (e.g., IV + (counter + 2n)). The second cryptographic hardware engine 504 receives a first IV and a second value of a block counter (e.g., IV + (counter + 2n + 1)). Using a round key 506, the first cryptographic hardware engine 502 generates encrypted data over multiple encryption rounds. The DMA hardware engine 500 includes a multiplexer 508 and other circuitry 510 for combining data from the two cryptographic hardware engines to compute a consistent partial authentication tag 512 for partial transfers scheduled to the DMA hardware engine 500. In this embodiment, the two cryptographic hardware engines jointly compute the partial authentication tag across the length of the partial transfer allocated to the DMA hardware engine 500.

[0052] Figure 6 This is a flowchart of an encryption operation 600 for scheduling multiple part transfers across multiple DMA engines, according to at least some embodiments. Encryption operation 600 is a simplified AES-GCM operation illustrating a single part transfer on different DMA engines. For AES-GCM, blocks are sequentially numbered using a block counter (32'1). The value of the block counter is combined with a first IV (96'IV) (block 602) and encrypted with an AES block cipher to obtain a first result (block 604). Specifically, the first IV and the first value of the first block counter are encrypted with a first block cipher using a first encryption key to obtain the first result. The block counter is incremented by the IV (96'IV) (32'2) (block 606) and encrypted with an AES block cipher to obtain a second result (block 608). Specifically, the first IV and the second value of the first block counter are encrypted with a second block cipher using a first encryption key to obtain the second result. The second result and the first plaintext 610 are combined (e.g., XOR'd) (block 612) to obtain the first ciphertext 614. This can be done on the first DMA engine 660. The first DMA engine 660 can calculate the first partial tag 618 and store the first partial tag 618 in the first FIFO buffer 662. The first adjustment 664 can also be stored in the first FIFO buffer 662.

[0053] The block counter increments by IV (96'IV) (32'3) (block 622) and is encrypted with an AES block cipher to obtain a third result (block 624). Specifically, the third value of the first IV and the first block counter is encrypted with a second block cipher using a first encryption key to obtain the third result. The third result and the second plaintext 626 are combined (e.g., XORed) (block 628) to obtain the second ciphertext 630. This can be done on a second DMA engine 666. The second DMA engine 666 can calculate a second partial tag 668 and store the second partial tag 668 in a second FIFO buffer 670. A second adjustment 672 can also be stored in the second FIFO buffer 670.

[0054] At the end of the data transfer, the block counter is incremented by the IV (96'IV) (32'N) (block 637) and encrypted with an AES block cipher to obtain a fourth result (block 638). Specifically, the first IV and the nth value of the first block counter are encrypted with an Nth block cipher using the first encryption key to obtain the fourth result. The fourth result and the Nth plaintext 640 are combined (e.g., XORed) (block 642) to obtain the Nth ciphertext 644. This can be done on the Nth DMA engine 674. The Nth DMA engine 674 can calculate the Nth partial tag 676 and store the Nth partial tag 676 in the Nth FIFO buffer 678. The Nth adjustment 680 can also be stored in the Nth FIFO buffer 678. The partial tags can be multiplied by their respective adjustments to obtain a combined tag 682. The combined tag 682 can be combined with the length of the ciphertext 684 to obtain an unencrypted tag 652. The unencrypted tag 652 can be combined with the first result from block 604 to generate an authentication tag 654 for data transmission.

[0055] Figure 7This is a flowchart of a decryption operation 700 for partial data transfer according to at least some embodiments. The decryption operation 700 is a simplified AES-GCM operation, illustrating a context switch before the completion of a full data transfer. For AES-GCM, blocks are sequentially numbered using a block counter (32'1). The value of the block counter is combined with a first IV (96'IV) (block 702) and encrypted with an AES block cipher to obtain a first result (block 704). Specifically, the first IV and the first value of the first block counter are encrypted with a first block cipher using a first encryption key to obtain the first result. The block counter increments with the IV (96'IV) (32'2) (block 706) and is encrypted with an AES block cipher to obtain a second result (block 708). Specifically, the first IV and the second value of the first block counter are encrypted with a second block cipher using a first encryption key to obtain the second result. The second result and the first ciphertext 710 are combined (e.g., XOR'd) (block 612) to obtain the first plaintext 714. This can be performed on a first DMA engine 760. The first DMA engine 760 can calculate a first partial tag 718 and store the first partial tag 718 in a first FIFO buffer 762. A first adjustment 764 can also be stored in the first FIFO buffer 762.

[0056] The block counter increments by IV (96'IV) (32'3) (block 722) and is encrypted with an AES block cipher to obtain a third result (block 724). Specifically, the third value of the first IV and the first block counter is encrypted with a second block cipher using a first encryption key to obtain a third result. The third result and the second ciphertext 726 are combined (e.g., XORed) (block 728) to obtain the second plaintext 730. This can be done on the second DMA engine 766. The second DMA engine 766 can calculate a second partial tag 768 and store the second partial tag 768 in the second FIFO buffer 770. The second adjustment 772 can also be stored in the second FIFO buffer 770.

[0057] At the end of the data transfer, the block counter is incremented by the IV (96'IV) (32'N) (block 737) and encrypted with an AES block cipher to obtain a fourth result (block 738). Specifically, the first IV and the nth value of the first block counter are encrypted with the Nth block cipher using the first encryption key to obtain the fourth result. The fourth result and the Nth ciphertext 740 are combined (e.g., XORed) (block 742) to obtain the Nth plaintext 744. This can be done on the Nth DMA engine 774. The Nth DMA engine 774 can calculate the Nth partial tag 776 and store the Nth partial tag 776 in the Nth FIFO buffer 778. The Nth adjustment 780 can also be stored in the Nth FIFO buffer 778. The partial tags can be multiplied by their respective adjustments to obtain the combined tag 782. The combined tag 782 can be combined with the length of the ciphertext 784 to obtain the unencrypted tag 752. The unencrypted tag 752 can be combined with the first result from block 704 to generate an authentication tag 754 for data transmission.

[0058] Figure 8 This is a flowchart of a method 800 for transferring scheduled computation authentication tags from multiple parts across multiple DMA engines, according to at least some embodiments. Method 800 can be performed by processing logic including hardware, software, firmware, or any combination thereof. In at least one embodiment, method 800 is performed by… Figure 1 The accelerator circuit 102 performs the operation. In at least one embodiment, method 800 is performed by... Figure 1 The replication engine 120 executes the method. In at least one embodiment, the method 800 is performed by... Figure 2 The hardware scheduler circuit 202 executes the method. In at least one embodiment, the method 800 is performed by... Figure 2 The hardware scheduler circuit 202 and DMA circuit 204 are executed.

[0059] refer to Figure 8Method 800 begins with processing logic receiving a first data transfer of a first size (box 802). The processing logic splits the first data transfer into a first set of portions, each portion being smaller than the first size (box 804). During a first round, the processing logic schedules a subset of the first set of portions to multiple DMA engines, each DMA engine including a cryptographic hardware engine (box 806). The processing logic stores a first subset of partial authentication tags calculated by the DMA engines, and a first subset of corresponding adjustment indices (box 808). The processing logic determines the partial authentication tags for the first round (box 810). In at least one embodiment, the processing logic determines the partial authentication tags by multiplying each partial authentication tag by its corresponding adjustment index, obtaining a result, and combining each result to obtain the partial authentication tags for the first round. This process may handle zero or more additional rounds. During the final round, the processing logic determines the authentication tags for the first data transfer (box 812), and method 800 ends. In at least one embodiment, the processing logic determines the authentication tags for the first data transfer by combining the partial authentication tags from each round to obtain a combined authentication tag and combining the length of the first data transfer with the combined authentication tag. In at least one embodiment, the processing logic uses a first encrypted IV assigned to the first data transmission to encrypt the authentication tag.

[0060] In a further embodiment, during the first round, the processing logic generates encrypted data for a first portion transfer using a first DMA engine among multiple DMA engines. The processing logic calculates a first portion authentication tag for the length of the first portion transfer using the first DMA engine. The processing logic stores the first portion authentication tag and a first adjustment index in a first buffer (e.g., a first FIFO buffer) associated with the first DMA engine. The processing logic generates encrypted data for a second portion transfer performed by a second DMA engine among multiple DMA engines. The processing logic calculates a second portion authentication tag for the length of the second portion transfer using the second DMA engine. The processing logic stores the second portion authentication tag and a second adjustment index in a second buffer (e.g., a second FIFO buffer) associated with the first DMA engine. The processing logic may use other DMA engines during the first round to calculate portion authentication tags and store the portion authentication tags and adjustment indices in corresponding buffers.

[0061] In at least one embodiment, during the second round, the processing logic generates encrypted data for the third part of the transmission via a first DMA engine, and calculates a third part authentication tag based on the length of the third part transmitted via the first DMA engine. The processing logic stores the third part authentication tag and a third adjustment index in a first buffer. The processing logic generates encrypted data for the fourth part of the transmission via a second DMA engine, and calculates a fourth part authentication tag based on the length of the fourth part transmitted via the second DMA engine. The processing logic stores the fourth part authentication tag and a fourth adjustment index in a second buffer.

[0062] In at least one embodiment, during the first round, the processing logic uses a GF multiplier to calculate multiple multiplier exponents based at least on the split size of the partial transfer set and the number of DMA engines.

[0063] In at least one embodiment, the processing logic performs a context binding process to transfer a first encryption key and a first IV to multiple DMA engines. In at least one embodiment, the processing logic calculates multiple multiplier exponents during the context binding process.

[0064] In a further embodiment, the processing logic determines the authentication tag of the first data transmission by using a first IV encrypted combination authentication tag associated with the first data transmission to obtain the authentication tag of the first data transmission.

[0065] Figure 9 This is a block diagram of a computing system 900 with an accelerator according to at least some embodiments, the accelerator including a replication engine for partially transferring computation authentication tags across multiple DMA engines. The computing system 900 is considered a leading system, wherein a main system processor CPU 104 delegates high-interrupt-frequency tasks to an accompanying microcontroller 904 coupled to accelerator circuitry 102. Except that the computing system 900 includes the accompanying microcontroller 904, the computing system 900 is similar to computing system 100, as indicated by similar reference numerals. The computing system 900 can be considered a larger system characterized by the addition of a dedicated control coprocessor and may include high-bandwidth SRAM to support accelerator circuitry 102.

[0066] In some cases, Figure 9Larger models are used when higher performance and versatility are required. Performance-oriented systems can perform inference on many different network topologies; therefore, they maintain a high degree of flexibility. Additionally, these systems can perform many tasks simultaneously, rather than serializing inference operations, so that inference operations do not consume too much processing power on CPU 104. Accelerator circuitry 102 may include a memory interface coupled to a dedicated high-bandwidth SRAM to address these needs. The SRAM can be used by accelerator circuitry 102 as a cache. The SRAM can also be used by other high-performance computer vision-related components on the system to further reduce communication to main system memory 114 (e.g., DRAM). Accelerator circuitry 102 enables an interface with microcontroller 904 (or a dedicated control coprocessor) to limit the interrupt load on CPU 104. In at least one embodiment, microcontroller 904 may be a RISC-V-based PicoRV32 processor, an ARM Cortex-M or Cortex-R processor, or other microcontroller designs. Using the dedicated coprocessor (microcontroller 904), the main processor (CPU 104) can handle some of the tasks associated with managing accelerator circuitry 102. For example, while the hardware scheduler circuit is responsible for scheduling and fine-grained programming of the accelerator circuit 102, the microcontroller 904 or CPU 104 can still handle some coarse-grained scheduling of the accelerator circuit 102, input-output memory management (IOMMU) mapping of memory accesses (as needed), memory allocation of input data and fixed-weight arrays on the accelerator circuit 102, and synchronization between other system components and tasks running on the accelerator circuit 102.

[0067] The techniques disclosed herein can be incorporated into any processor capable of processing neural networks, such as a central processing unit (CPU), GPU, deep learning accelerator (DLA) circuitry, intelligent processing unit (IPU), neural processing unit (NPU), tensor processing unit (TPU), neural network processor (NNP), data processing unit (DPU), vision processing unit (VPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc. Such processors can be incorporated into personal computers (e.g., laptops), data centers, Internet of Things (IoT) devices, handheld devices (e.g., smartphones), vehicles, robots, voice-controlled devices, or any other device that performs inference, training, or any other processing on neural networks. Such processors can be used in virtualization systems, enabling an operating system running in a virtual machine on the system to utilize the processor.

[0068] As an example, processors incorporating the techniques disclosed herein can be used to process one or more neural networks in a machine to identify, classify, manipulate, process, operate, modify, or navigate physical objects in the real world. For instance, such processors can be used in autonomous vehicles (e.g., cars, motorcycles, helicopters, drones, flying devices, ships, submarines, delivery robots, etc.) to enable the vehicles to move in the real world. Additionally, such processors can be used in robots in factories to select components and assemble them into assemblies.

[0069] As an example, a processor incorporating the techniques disclosed herein can be used to process one or more neural networks to identify one or more features in an image or to alter, generate, or compress the image. For example, such a processor can be employed to enhance images rendered using rasterization, ray tracing (e.g., using NVIDIA RTX), and / or other rendering techniques. In another example, such a processor can be employed to reduce the amount of image data transmitted from a rendering device to a display device over a network (e.g., the Internet, mobile telecommunications networks, Wi-Fi networks, and any other wired or wireless network system). Such transmission can be utilized to stream image data from servers or data centers in the cloud to user devices (e.g., personal computers, video game consoles, smartphones, other mobile devices, etc.) to enhance services such as streaming images (e.g., NVIDIA GeForce Now (GFN), Google Stadia, etc.).

[0070] As an example, processors incorporating the techniques disclosed herein can be used to process one or more neural networks for any other type of application capable of utilizing neural networks. Such applications may involve translating languages, recognizing and removing sounds from audio, detecting anomalies or defects in the production of goods and services, monitoring living and non-living things, medical diagnosis, decision-making, and so on.

[0071] Other variations are within the spirit of this disclosure. Therefore, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments are shown in the accompanying drawings and described in detail above. However, it should be understood that this disclosure is not intended to be limited to one or more specific forms disclosed, but rather is intended to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of this disclosure as defined in the appended claims.

[0072] Unless otherwise stated herein or obviously contradicted by the context, the terms “a” and “an” and “described”, and similar references used in the context of describing the disclosed embodiments (especially in the context of the claims) should be interpreted as encompassing both singular and plural forms, and should not be construed as definitions of the terms. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” should be interpreted as open-ended terms (meaning “including, but not limited to”). The term “connection,” when unmodified and referring to a physical connection, should be interpreted as partially or wholly contained within, attached to, or joined together, even if something is in between. Unless otherwise stated herein, statements of numerical ranges herein are intended only as a simplified representation of each individual value falling within that range. Each individual value is incorporated into the specification as if it were individually stated herein. In at least one embodiment, unless otherwise stated or contradicted by the context, the use of the terms “set” (e.g., “set of items”) or “subset” will be interpreted as a non-empty collection comprising one or more members. Furthermore, unless otherwise stated or contradicted by the context, the term "subset" for a corresponding set does not necessarily mean a proper subset of the corresponding set, but rather that a subset can be equal to the corresponding set.

[0073] Unless otherwise explicitly stated or clearly contradicted by the context, connective phrases such as “at least one of A, B, and C” or “at least one of A, B, and C” are understood in the context to generally refer to items, terms, etc., which can be A or B or C, or any non-empty subset of the set A, B, and C. For example, in an exemplary example of a set with three members, the connective phrases “at least one of A, B, and C” and “at least one of A, B, and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Therefore, such connective language is generally not intended to imply that some embodiments require the presence of at least one of A, at least one of B, and at least one of C. Additionally, unless otherwise stated or contradicted by the context, the term “multiple” indicates a plural state (e.g., “multiple items” means multiple items). In at least one embodiment, the number of multiple items is at least two, but may be more when explicitly stated or indicated by the context. Furthermore, unless otherwise stated or clearly understood from the context, the phrase “based on” means “at least partially based on” rather than “based on only”.

[0074] Unless otherwise indicated herein or clearly contradicted by the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as those described herein (or variations thereof and / or combinations thereof) are executed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that are executed jointly on one or more processors via hardware or a combination thereof. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program, which in at least one embodiment includes a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that excludes transient signals (e.g., propagating transient electrical or electromagnetic transmissions) but includes non-transitory data storage circuitry (e.g., buffers, caches, and queues). In at least one embodiment, code (e.g., executable code or source code) is stored on one or more non-transitory computer-readable storage media (or other memory for storing executable instructions) on which executable instructions are stored, which, when executed by one or more processors of a computer system (i.e., as a result of execution), cause the computer system to perform the operations described herein. In at least one embodiment, the set of non-transitory computer-readable storage media includes multiple non-transitory computer-readable storage media, and one or more individual non-transitory storage media lack the complete code, while the multiple non-transitory computer-readable storage media collectively store the complete code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors; for example, the non-transitory computer-readable storage media stores the instructions, and the main central processing unit (“CPU”) executes some of the instructions, while the graphics processing unit (“GPU”) and / or data processing unit (“DPU”) (possibly together with the GPU) executes the other instructions. In at least one embodiment, different components of the computer system have separate processors, and the different processors execute different subsets of the instructions.

[0075] Therefore, in at least one embodiment, the computer system is configured to implement one or more services that perform the operations of the processes described herein, either individually or collectively, and such a computer system is configured with suitable hardware and / or software to enable the implementation of the operations. Furthermore, the computer system implementing at least one embodiment of this disclosure is a single device, and in another embodiment it is a distributed computer system comprising multiple devices operating in different ways, such that the distributed computer system performs the operations described herein, and that a single device does not perform all the operations.

[0076] The use of any and all examples or exemplary language (e.g., “such as”) provided herein is intended only to better illustrate embodiments of this disclosure and does not constitute a limitation on the scope of this disclosure unless otherwise required. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the disclosure.

[0077] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference as if each reference were individually and specifically indicated to be incorporated herein by reference and the entire contents of which are described herein.

[0078] The terms “coupled” and “connected”, and their derivatives, may be used in the specification and claims. It should be understood that these terms may not be intended to be synonyms with each other. Rather, in certain examples, “connected” or “coupled” may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. “Coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0079] Unless otherwise expressly stated, it will be understood that throughout this specification, terms such as “processing,” “computing,” “determining,” etc., refer to the actions and / or processes of a computer or computing system or similar electronic computing device that process and / or convert data represented as physical quantities (e.g., electrons) in the registers and / or memory of the computing system into other data represented as physical quantities in the memory, registers, or other such information storage, transmission, or display devices of the computing system.

[0080] Similarly, the term "processor" can refer to any device or part of memory that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" can be a CPU or a GPU. A "computing platform" can include one or more processors. As used herein, a "software" process can include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. Likewise, each process can refer to multiple processes that execute instructions sequentially or intermittently, sequentially, or in parallel. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, provided that a system can embody one or more methods, and a method can be considered a system.

[0081] In this document, reference may be made to obtaining, acquiring, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog and digital data can be accomplished in various ways, such as by receiving data as a parameter to a function call or a call to an application programming interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be implemented by transmitting data as an input or output parameter to a function call, an application programming interface, or an inter-process communication mechanism.

[0082] While the description herein illustrates exemplary embodiments of the described technologies, other architectures may be used to implement the described functionality and are intended to fall within the scope of this disclosure. Furthermore, although specific assignments of responsibilities have been defined above for descriptive purposes, various functions and responsibilities may be assigned and divided in different ways depending on the circumstances.

[0083] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claims.

Claims

1. An accelerator circuit, comprising: Secure storage; A scheduler circuit is used to receive a first data transmission of a first size and split the first data transmission into a set of partial transmissions. as well as The Direct Memory Access (DMA) circuitry includes a logical DMA engine, orchestration circuitry, and multiple DMA engines. Each of the multiple DMA engines includes cryptographic circuitry that implements a certified encryption algorithm to encrypt data retrieved from the secure memory or decrypt received data to be stored in the secure memory, wherein: The logical DMA engine is used to schedule the first portion of the transfer to the first DMA engine among the plurality of DMA engines and to store the first adjustment index in the first buffer in the orchestration circuit, the first buffer being associated with the first DMA engine. The first DMA engine is used to calculate the first part authentication tag for the first part transmission and to store the first part authentication tag in the first buffer. The logical DMA engine is used to schedule the second part of the transfer to the second DMA engine among the plurality of DMA engines and to store the second adjustment index in a second buffer in the orchestration circuit, the second buffer being associated with the second DMA engine. The second DMA engine is used to calculate the second part authentication tag for the second part transmission and to store the second part authentication tag in the second buffer; and The orchestration circuit is used to calculate a first combined authentication tag for the first data transmission based at least on the first adjustment index, the first partial authentication tag, the second adjustment index, and the second partial authentication tag.

2. The accelerator circuit of claim 1, wherein the DMA circuit further comprises a Galois domain (GF) multiplier, wherein the DMA circuit is configured to use the GF multiplier to calculate a plurality of multiplier exponents based at least on the split size of the partial transfer set and the number of the plurality of DMA engines.

3. The accelerator circuit of claim 2, wherein the logical DMA engine is assigned a first encryption key and a first initialization vector IV for the first data transfer, wherein the logical DMA engine is used to context-bind the first encryption key and the first IV with the plurality of DMA engines.

4. The accelerator circuit of claim 3, wherein the DMA circuit is configured to calculate the plurality of multiplier exponents during the delay of the first encryption key and the first IV being bound to the plurality of DMA engines in the context.

5. The accelerator circuit of claim 3, wherein each of the plurality of DMA engines is configured to receive a value of a block counter of the logical DMA engine, wherein the block counter is incremented for each of the partial transfer sets scheduled to one of the plurality of DMA engines, wherein each of the plurality of DMA engines is configured to generate encrypted data for a corresponding partial transfer and a partial authentication tag for calculating the length of the corresponding partial transfer, using at least the first encryption key, the first IV, and the value of the block counter.

6. The accelerator circuit of claim 1, wherein the orchestration circuit is used for: Calculate the first product of the first adjustment index and the first part of the certification label; Calculate the second product of the second adjustment index and the second part of the certification label; as well as Combine the first product with the second product to obtain the first result; The length of the first data transmission is combined with at least the first result to obtain a combined authentication tag; as well as The combined authentication tag is encrypted using a first initialization vector IV to generate the first combined authentication tag for the first data transmission.

7. The accelerator circuit of claim 1, wherein the first buffer is a first first-in-first-out (FIFO) buffer, and the second buffer is a second FIFO buffer.

8. The accelerator circuit of claim 1, wherein the first adjustment index is a multiplier index, the multiplier index being a function of the split size of the partial transfer and the number of the plurality of DMA engines.

9. The accelerator circuit of claim 1, wherein the logic DMA engine uses a polling arbitration scheme to schedule the partial transfer set to the plurality of DMA engines.

10. The accelerator circuit of claim 1, wherein the certified encryption algorithm is Advanced Encryption Standard Galois Counter Mode (AES-GCM).

11. The accelerator circuit of claim 1, wherein the accelerator circuit is a graphics processing unit (GPU), a deep learning accelerator (DLA) circuit, an intelligent processing unit (IPU), a neural processing unit (NPU), a tensor processing unit (TPU), a neural network processor (NNP), a data processing unit (DPU), a vision processing unit (VPU), an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA).

12. A method of operating an accelerator circuit, the method comprising: Receive the first data transmission of the first size; The first data transmission is divided into a first set of data transmission parts, each of which is smaller than the first size; During the first round, A subset of the first set of data transfer components is scheduled to multiple Direct Memory Access (DMA) engines, each of which includes a cryptographic hardware engine. Store a first subset of the authentication tags calculated by the plurality of DMA engines, and a first subset of the corresponding adjustment indices, and The first round of partial authentication labels is determined based on a first subset of the partial authentication labels and a first subset of the corresponding adjustment index; as well as During the final round, the authentication tag for the first data transmission is determined by combining the partial authentication tags from each round to obtain a combined authentication tag and combining the length of the first data transmission with the combined authentication tag.

13. The method of claim 12, further comprising, during the first round: Encrypted data for the first part of the transmission is generated by the first DMA engine among the plurality of DMA engines; The first part of the authentication tag is calculated using the first DMA engine to determine the length of the first part to be transmitted. The first part of the authentication tag and the first adjustment index are stored in the first buffer associated with the first DMA engine; Encrypted data for the second part of the transmission is generated by the second DMA engine among the plurality of DMA engines; The second authentication tag for the length of the second part transmitted is calculated using the second DMA engine; as well as The second part of the authentication label and the second adjustment index are stored in the second buffer associated with the second DMA engine.

14. The method of claim 13, further comprising, during the second round: The first DMA engine generates encrypted data for the transmission of the third part; The first DMA engine calculates the third part authentication tag for the length of the third part transmitted; The third part of the authentication label and the third adjustment index are stored in the first buffer; The encrypted data for the fourth part of the transmission is generated by the second DMA engine; The second DMA engine calculates the fourth part authentication tag for the length of the fourth part to be transmitted; as well as The fourth part of the authentication label and the fourth adjustment index are stored in the second buffer.

15. The method of claim 13, further comprising: During the first round, a Galois domain GF multiplier is used to calculate multiple multiplier exponents, based at least on the split size of the partial transport set and the number of the multiple DMA engines.

16. The method of claim 15, further comprising performing a context binding process to deliver a first cryptographic key and a first initialization vector IV to the plurality of DMA engines, wherein the calculation of the plurality of multiplier exponents is performed during the context binding.

17. The method of claim 15, wherein determining the authentication tag further comprises encrypting the combined authentication tag using a first initialization vector IV associated with the first data transmission to obtain the authentication tag for the first data transmission.

18. An accelerator circuit, comprising: The replication engine CE includes multiple Advanced Encryption Standard Galois Counter Mode (AES-GCM) hardware engines, each of which is configured to perform encryption and authentication. The CE includes a secure memory for storing a context including encryption keys, initialization vectors (IVs), and block counters. as well as The engine scheduler coupled to the CE, wherein: The engine scheduler is used for: Receives an encryption or decryption operation descriptor for a specified size of data transfer for the application; and The data transmission is split into a set of partial transmissions, each of which has a fixed size smaller than the specified size; During the first round, the replication engine CE was used for: Schedule a subset of the aforementioned transport set to the plurality of AES-GCM hardware engines; Stores a first subset of authentication tags calculated by the plurality of AES-GCM hardware engines, and a first subset of corresponding adjustment indices, and The partial authentication tags for the first round are determined based on a first subset of the partial authentication tags and a first subset of the corresponding adjustment indices; and During the final round, the replication engine CE was used for: The authentication tag for the data transmission is determined by combining the partial authentication tags from each round to obtain a combined authentication tag, combining the length of the data transmission with the combined authentication tag, and encrypting the combined authentication tag using the IV.

19. The accelerator circuit of claim 18, wherein the accelerator circuit is a graphics processing unit (GPU), a deep learning accelerator (DLA) circuit, an intelligent processing unit (IPU), a neural processing unit (NPU), a tensor processing unit (TPU), a neural network processor (NNP), a data processing unit (DPU), a vision processing unit (VPU), an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA).

20. The accelerator circuit of claim 18, wherein the CE comprises: Logic Computing Engine (LCE); Multiple physical computing engines (PCEs) coupled to the LCE, each of the multiple PCEs including one of the multiple AES-GCM hardware engines; as well as An orchestration circuit coupled to the LCE and the plurality of PCEs, wherein the orchestration circuit includes a first-in-first-out (FIFO) buffer for each of the plurality of PCEs, the FIFO buffer being used to store partial authentication tags and corresponding adjustment indices.

Images