Preventing untrusted software from resetting during cryptographic operations

Abstract

The present disclosure relates to preventing untrusted software resets during cryptographic operations. Apparatuses, systems, and techniques for handling faults by a direct memory access (DMA) engine. When the DMA engine detects an error associated with an encryption or decryption operation, the DMA engine reports the error to a CPU, which can be executing untrusted software that directed the DMA operation, and a secure processor. The DMA engine waits for a clear from the secure processor before responding to further instructions from potentially untrusted software.

Description

Technical Field

[0001] At least one embodiment relates to processing resources for performing and facilitating confidential data transmission. For example, at least one embodiment relates to hardware circuitry for preventing untrusted software reset during cryptographic operations. Background Technology

[0002] Accelerator circuitry includes Direct Memory Transfer (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. Serious security failures, such as authentication errors, can occur in user space, and these failures are typically reported to system software, such as the Graphics Processing Unit (GPU) Resource Manager (RM). During cryptographic operations, the system software is untrusted, so serious security failures reported to the RM in user space cannot be relied upon, as the system software can mask serious security failure reports and hide authentication errors from the user. Furthermore, even if serious security failures are reported to security software, the reset of the DMA circuitry is handled by the untrusted system software. If a reset is triggered before the security software processes the serious security failure, the untrusted system software may obscure the association of the error with the appropriate context. Attached Figure Description

[0003] Figure 1 It 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 prevents reset from untrusted software during cryptographic operations of the accelerator circuitry.

[0004] Figure 2 It is a block diagram of an accelerator circuit having a proprietary interface between a replication engine and a security processor, according to at least some embodiments;

[0005] Figure 3 It is a block diagram of a replication engine for an accelerator circuit according to at least some embodiments;

[0006] Figure 4 It is a block diagram of the interrupt lines between the copy engine and the security processor and the GPU system processor according to at least some embodiments;

[0007] Figure 5 This is a flowchart illustrating an encryption operation in which an error was detected, according to at least some embodiments;

[0008] Figure 6 This is a flowchart of a decryption operation in which an error is detected, according to at least some embodiments;

[0009] Figure 7 This is a flowchart of a method for preventing untrusted software reset during cryptographic operations according to at least some embodiments until one or more interrupt status bits are cleared; and

[0010] Figure 8 It is a block diagram of a computing system with an accelerator according to at least some embodiments, the accelerator including a replication engine that guarantees fairness among multiple users of the computing system. Detailed Implementation

[0011] As mentioned above, DMA circuitry can be used for memory-to-memory copying or moving of data within memory and can include cryptographic hardware to protect the data. During cryptographic operations, the system software is untrusted and may hide authentication errors from the user. Furthermore, untrusted system software can reset the DMA circuitry before a serious security failure is handled, potentially exposing data. For example, if partially authenticated text is not deleted by security software after an authentication error, it may be exposed. As another example, if the initialization vector (IV) counter is not reconfigured by security software after an initialization vector (IV) counter overflow error, the IV can be exposed and reused. If a serious security failure is not handled before a reset, a window exists where data used by the cryptographic hardware may be exposed to an attacker.

[0012] The aspects and embodiments of this disclosure address these and other challenges by providing a secure reporting path for reporting critical security failures and reset processing logic that retains reset signals from untrusted software until the critical security failure is cleared. In at least one embodiment, an accelerator circuit includes a DMA engine (also known as a copy engine (CE)) coupled to a secure processor via a proprietary interface and to a central processing unit (CPU) via a cryptographic interface. The DMA engine detects errors associated with encryption or decryption operations via a cryptographic hardware engine. The DMA engine sets one or more interrupt status bits in a first register accessible to the secure processor. The DMA engine reports one or more interrupts associated with the error to the CPU and the secure processor. The secure processor performs one or more operations to clear one or more interrupt status bits. The DMA engine may receive a reset signal from untrusted software. The DMA engine retains the reset signal (to prevent a DMA engine reset) until the secure processor clears one or more interrupt status bits. A DMA engine reset is performed in response to one or more interrupt status bits cleared by the secure processor.

[0013] Accelerator circuits can be graphics processing units (GPUs), deep learning accelerator (DLA) circuits, intelligent processing units (IPUs), neural processing units (NPUs), tensor processing units (TPUs), neural network processors (NNPs), data processing units (DPUs), vision processing units (VPUs), application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). Accelerator circuits can address the computational needs of the neural network inference stage 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), and fully connected neural networks.

[0014] 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 for 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, a neural network can be specified using a set of layers (referred to as “raw layers” in this paper), such as bias and batch normalization. Those raw layers can be compiled or transformed into another set of layers (referred to as “hardware layers” in this paper), where each hardware layer serves as a basic element for scheduling to be executed 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 that the accelerator circuit performs operations on, and each layer can communicate with another layer via a memory interface. For example, the first layer can be executed by a first fixed-function engine in the DLA circuit, which receives input tensors, performs operations on the input tensors to generate an output tensor, and stores 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 in memory as a second input tensor, 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.

[0015] Figure 1This 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 prevents resets from untrusted software during cryptographic operations of accelerator circuitry 102. 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 a 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.

[0016] The accelerator circuit 102 may further include a memory interface block connected to 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. A 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 could be on-chip SRAM to provide higher throughput and lower access latency.

[0017] 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 continuously until the inference of the entire network is complete. In at least one embodiment, the 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.

[0018] Figure 1The computing system 100 represents a more cost-sensitive system than a computing system with a dedicated controller or coprocessor for unit-by-unit management of the accelerator circuitry 102. 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) systems, and automation-oriented systems with well-defined tasks, where cost, area, and power are the 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 larger models to be reduced in terms of load complexity. In turn, the reduction in load complexity enables scaled-down DLA implementations where models consume less storage and require less time for system software loading and processing. 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 via the computing system 100 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 prevents resets from untrusted software during cryptographic operations of accelerator circuitry 102. In at least one embodiment, replication engine 120 includes reset processing logic 122. Reset processing logic 122 can receive a reset signal from untrusted software and can hold the reset signal (to prevent resets of replication engine 120) until all security faults are cleared. Reset processing logic 122 may allow one or more operations to be performed to protect the context associated with the encryption or decryption operations performed by accelerator circuitry 102 before a reset is allowed. For example, partially authenticated text may be removed by security software after an authentication error occurs before reset processing logic 122 allows a reset. As another example, IVs may be reconfigured after an IV counter overflow error occurs before reset processing logic 122 allows a reset. Reset processing logic 122 allows security faults to be handled before a reset, closing a window that data used by the cryptographic hardware might otherwise be exposed to an attacker. Additional details about the copy engine 120 will be provided below. Figure 2-3 Describe it.

[0019] Figure 2This is a block diagram of an accelerator circuit 102 having a proprietary interface between a replication engine and a security processor, according to at least some embodiments. The accelerator circuit 102 is coupled to a CPU 104 via a Peripheral Component Interconnect (PCI) bus 202. The accelerator circuit 102 may be coupled to one or more PCI components 204 via the PCI bus 202. The CPU 104 executes system software 206, such as an operating system (OS), a resource manager (RM), or both in kernel space. The CPU 104 also executes one or more applications 208 in user space. The accelerator circuit 102 includes a replication engine (CE) 120, a security processor 210, and interrupt reporting logic 212. In at least one embodiment, the interrupt reporting logic 212 may be an interrupt controller or part of an interrupt controller. The interrupt controller may receive one or more interrupts from the replication engine 120 and send one or more interrupts to the CPU 104. In some cases, the interrupt controller sends an interrupt to the CPU, and the CPU must access registers in the interrupt controller to determine which component issued the interrupt and / or the type of interrupt triggered. CE 120 includes a cryptographic hardware engine 222 that performs cryptographic operations. CE 120 treats system software 206, including the RM, as untrusted (also referred to herein as untrusted software 206). CE 120 can report security failures using interrupt reporting logic 212, but also treats the interrupt reporting logic 212 as untrusted. Therefore, a security interrupt line 209 exists to the security processor 210 for reporting serious security failures. The security processor 210 may be a dedicated on-chip security processor (SEC2). In another embodiment, the security processor 210 may be a GPU system processor (GSP). The security processor 210 executes security software 214 to handle security failures. The security software 214 may include a security RM. The security interrupt line 209 may be part of a private interface between the replication engine 120 and the security processor 210. The security interrupt line 209 cannot be accessed by other components, such as CPU 104 or PCI component 204. The replication engine 120 can detect errors associated with encryption or decryption operations via the cryptographic hardware engine 222 and can send or issue an interrupt on the security interrupt line 209. The interrupt is handled by security software 214. Security software 214 can be verified by the user before confidential computation begins on accelerator circuit 102. The replication engine 120 can also send or issue an interrupt on interrupt line 211 between interrupt logic 212 and the replication engine 120. Interrupt reporting logic 212 can report the interrupt to CPU 104 on interface 213 between interrupt reporting logic 212 and CPU 104. As a result of the interrupt, untrusted software 206 (e.g., untrusted RM) can send or issue a reset (also known as an engine reset) to the replication engine 120 via interface 215 between the replication engine 120 and CPU 104.The reset processing logic 122 of the replication engine 120 does not acknowledge engine resets from untrusted software 206 until all critical security faults in the context have been resolved by security software 214. This ensures that critical security faults in the CE context are detected and handled during cryptographic operations by security software 214 before a reset. The replication engine 120 thus provides the software with a reliable tamper detection mechanism and also narrows the attack window where unauthenticated text might be exposed or IVs might be reused.

[0020] In at least one embodiment, when replication engine 120 receives a reset from untrusted software 206, replication engine 120 enters a paused state, in which replication engine 120 stops issuing new requests and waits for all outstanding binding, refresh, and storage requests to respond before sending a reset confirmation back to untrusted software 206. Replication engine 120 also waits in this paused state until all security breaches are resolved by security software 214 before sending the reset confirmation back to untrusted software 206. In this way, any sensitive data can be protected from attacks. The window of attack is minimized, and infected software or tampering can be reported to the user in a guaranteed manner and handled with high priority.

[0021] In at least one embodiment, the replication engine 120 includes one or more registers 224 accessible by the CPU 104 (and optionally the PCI component 204) and one or more registers 226 inaccessible to the CPU 104 or the PCI component 204. In at least one embodiment, one or more registers 226 include control registers in a PCI configuration space accessible by the CPU 104 (or the PCI component 204). In at least one embodiment, one or more registers 224 may be memory-mapped input / output (MMIO) registers used by components coupled to the PCI bus 202. In at least one embodiment, the CPU 104 can reset the replication engine 120 by setting specified bits in the MMIO registers. As described herein, reset processing logic 122 can prevent the replication engine 120 from being reset until the security processor 210 handles a security fault. One or more registers 226 may be accessible by the security processor 210 (e.g., SEC2 or GSP). In particular, the replication engine 120 can detect errors associated with cryptographic operations and can set one or more interrupt status bits in one or more registers 226. The replication engine 120 (e.g., reset processing logic 122) may set one or more interrupt status bits in one or more registers 226 to report an interrupt to the security processor 210. In at least one embodiment, one or more registers 226 may include an interrupt status register. In response to one or more interrupts issued by the replication engine 120, the security processor 210 may perform one or more operations to protect the context of the cryptographic operation and clear one or more interrupt status bits in the interrupt status register. In at least one embodiment, the security software 214 may perform one or more operations to protect the context and clear one or more interrupt status bits in the interrupt status register of the replication engine 120. Once one or more interrupt status bits in the interrupt status register have been cleared by the security processor 210, the reset processing logic 122 may send a reset confirmation to the CPU 104 and reset itself. In this way, the replication engine 120 can guarantee that one or more interrupts are processed before resetting and sending a reset confirmation to the CPU 104.

[0022] In at least one embodiment, security software 214 may report one or more interrupts to application 208 via encrypted interface 217 between security processor 210 and CPU 104. This ensures that application 208 (i.e., the user) is notified of security failures even if the interrupt reported by interrupt reporting logic 212 is masked by untrusted software 206.

[0023] In at least one embodiment, the cryptographic hardware engine 222 is an Advanced Cryptographic Standard Galois Counter Mode (AES-GCM) hardware engine that implements the AES256-GCM cryptography. AES-GCM is an authenticated cryptographic algorithm that performs encryption and authentication of a data stream. Hardware implementations of AES-GCM circuitry are very expensive because each 16 bytes requiring simultaneous encryption necessitates a 128-bit multiplier. AES-GCM is a sequential operation that requires sequential analysis of data to compute the GHASH function. A single AES key K is used to encrypt data and derive authenticated data. The component used by GCM to generate the message authentication code is called GHASH. If multiple users / applications attempt to use the AES-GCM hardware engine, one user's operation is serialized and completed before another user's operation is serialized and completed because the block counter, initialization vector (IV), key (KEY), and GHASH require state tracking. Because the AES-GCM hardware engine can be shared, untrusted software may attempt to gain access to or retrieve sensitive data from the context of the AES-GCM hardware engine. As described above, infected software may cause a security failure and reset replication engine 120 in an attempt to obtain sensitive data related to AES-GCM operation. Reset processing logic 122 can prevent infected software from resetting replication engine 120 until the security failure is handled by trusted software, such as security software 214 of security processor 210 as described above.

[0024] Figure 3 This is a block diagram of a replication engine 120 of an accelerator circuit according to at least some embodiments. The replication engine 120 includes a hardware scheduler circuit 302 (labeled ESCHED for engine scheduler) and a direct memory access (DMA) circuit 304. The hardware scheduler circuit 302 is coupled to an auxiliary memory 306 and the DMA circuit 304. The DMA circuit 304 is coupled to system memory (…). Figure 3 A memory management unit (MMU) 330 (not shown) is coupled to the accelerator circuitry. The MMU 330 can provide routing functionality between system memory and accelerator circuitry. The MMU 330 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.). The MMU 330 can perform access checks to allow only access via the interface. The MMU 330 can restrict and report unauthorized access. DMA circuitry 304 includes cryptographic circuitry that implements certified encryption algorithms to encrypt data retrieved from secure memory or decrypt received data for storage in secure memory. In at least one embodiment, as... Figure 3As shown, the DMA circuit 304 includes a logical replication engine (LCE) 308 and a physical replication engine (PCE) 310. The DMA circuit 304 may include multiple PCEs coupled to the LCE 308. The LCE 308 may include a secure memory 312 that can store an encrypted IV, a block counter, and a hash key in each channel key slot. Each channel key slot, which can be assigned to an application, can store the application's context in a designated slot in the secure memory 312. The LCE 308 may also include a secure private interface 314 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 the IV are generated by a random number generator from a secure processor on the GPU. In other embodiments, the replication engine 120 may also include multiple LCEs.

[0025] In at least one embodiment, such as Figure 3 As shown, PCE 310 includes front-end circuitry 316, a read pipeline 318, a write pipeline 320, and cryptographic circuitry 322 providing secure data transmission for applications requiring confidentiality. In at least one embodiment, cryptographic circuitry 322 is an AES-GCM hardware engine implementing AES256-GCM cryptography. In at least one embodiment, cryptographic hardware engine 222 is AES-GCM circuitry. Alternatively, cryptographic circuitry 322 may implement other sequential cryptographic algorithms, 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. As another example, the cryptographic hardware may be used in a virtualized environment where a hypervisor allows the underlying hardware to support multiple guest virtual machines (VMs) by virtually sharing its resources (including accelerator circuitry 102). In another embodiment, DMA circuitry 304 includes LCE 308 and a first PCE 310, as well as a second PCE. A first PCE 310 is coupled to an LCE 308 and includes a cryptographic circuit 322, a first read pipeline 318, and a write pipeline 320. A second PCE is coupled to an LCE 308 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. Additional PCEs may include front-end circuitry, a read pipeline, a write pipeline, and cryptographic circuitry, respectively.

[0026] In at least one embodiment, the replication engine 120 can encrypt data associated with data transmission. To encrypt data transmission, a context is loaded (CTXT LOAD) on LCE 308, having a valid SRAM index pointing to a slot in secure memory 312 allocated to the application. The KEY (key) indicated in the slot of secure memory 312 is loaded onto cryptographic circuitry 322 (AES hardware engine). The first IV used is SRAM.IV+1, which is an incrementing IV stored in LCE 308. PCE 310 generates a memory request (read / write). PCE 310 reads plaintext data from a first region of memory (Calculated Protected Region (CPR)), encrypts the plaintext data with the KEY and IV, and adds it to an authentication tag (AT or AuthTag). During encryption operations, PCE 310 reads from protected memory (e.g., video memory), internally encrypts the data using cryptographic circuitry 322, and writes the encrypted data to an unprotected region (e.g., system memory or video memory). In at least one embodiment, PCE 310 writes encrypted data to a second region of memory (Non-Computationally Protected Region (NonCPR)). At the end of replication (or the last replication split in a time slice), PCE 310 writes the used IV to the second region of memory (NonCPR) and also writes the calculated authentication tag to the second region of memory (NonCPR). When interacting with the MMU, requests may carry region identifiers. The region identifier indicates the location where the memory region must be a CPR or a Non-Computationally Protected Region (NonCPR). Replication engine 120 may interact with the MMU to obtain the address of each region. The region identifier is specified by replication engine 120 when making an MMU conversion request because the MMU tracks the CPR and NonCPR attributes of memory regions. If the region identifier specified by replication engine 120 does not match the attributes of the target memory location, the MMU will block access and return an error to replication engine 120 (e.g., MMU_NACK). The CPR is the first region of memory containing the decrypted data. The CPR can be a memory sandbox, accessible only to selected clients and inaccessible to any malicious actors. NonCPR is any memory area other than CPR. NonCPR is untrusted because it can be accessed by malicious actors. The replication engine 120 ensures that data movement from NonCPR to CPR must follow a decryption path; that is, nonCPR needs to contain encrypted data that only the replication engine 120 with the correct key can understand. Similarly, the replication engine 120 ensures that any data movement from CPR to NonCPR traverses an encrypted path. Encrypted data in NonCPR is accessible to malicious actors but cannot be tampered with because malicious actors do not have the key to understand the encrypted data.The replication engine 120 can write authentication tags to NonCPR, so users can detect the damage from malicious actors when decrypting.

[0027] In at least one embodiment, the copy engine 120 can decrypt data associated with data transmission. To decrypt the data transmission, a context with a valid SRAM index pointing to a slot in the secure memory 312 allocated to the application is loaded onto LCE 308 (CTX LOAD). The KEY indicated in the slot of secure memory 312 is loaded onto cryptographic circuitry 322 (AES hardware engine). The first IV used is IB.IV+1, which is the IV tracked and incremented in the hardware scheduler circuitry and passed to LCE 308. PCE 310 reads the expected authentication tag from memory, reads the cryptographic data from the second region (NonCPR) of memory, decrypts the cryptographic data using the KEY and IV, and adds it to the authentication tag. During the decryption operation, PCE 310 reads from unprotected memory (e.g., system memory or video memory), internally decrypts the data using cryptographic circuitry 322, and writes the decrypted data to a protected region (e.g., CPR). In at least one embodiment, PCE 310 writes plaintext data to the first region (CPR) of memory. During the final copy split, the PCE 310 reads the authentication tag from the authentication tag address provided in the method and compares the calculated authentication tag with the provided authentication tag. If the values ​​match, the operation succeeds. If there is no match, the PCE 310 raises a fatal interrupt, no semaphore release occurs, and channel recovery is required. Channel recovery (also known as robust channel recovery or RC recovery) is a mechanism used by the resource manager or GPU PF driver to mark all pending jobs on the engine as invalid by indicating an error in each working channel. The engine is then reset. The resource manager (or GPU PF driver) uses channel errors to let the software layer (e.g., CUDA) know that the job is not yet complete.

[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 increments with each encryption / decryption channel start (SOC). The 96-bit RNG mask is a per-key mask stored in the secure PRI. The copy IV (COPY_IV) is RNG XOR [CHANNEL_CTR, ++MSG_CTR]. The replication engine detects that the IV has exceeded the maximum number of copies by checking if the MESSAG_CTR+1 value used in the COPY_IV construction is zero. The replication engine 120 tracks the encrypted IV used in each encrypted copy and performs pre-incrementing and save-and-restore from SRAM. The encrypted IV is XORed with RNG in the decryption IV method of each copy and then passed to the cryptographic hardware engine 222. The IV stored in SRAM reflects the replication completion. The replication engine 120 may have multiple encrypted copies visible to the PCE and maintain two counters, including the IV that should be sent on the network encrypted copy and the last completed copy. In context saving (CTXT_SAVE), the IV from the final 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 XOR the decrypted IV with the correct RNG before passing it from the LCE to the front-end circuitry 316.

[0029] In at least one embodiment, the replication engine 120 includes a secure private interface 314. The secure private interface 314 is accessible by security software to provide secure configuration or secret keys and to query interrupt status for encryption and decryption. The replication engine 120 can connect as a client to the security hub 324, allowing the dedicated on-chip security processor (SEC2) 326 and the GPU system processor (GSP) 328 to access these secure private interfaces 314, but not BAR0. The GSP 328 can be used to offload GPU initialization and management tasks. The SEC2 326 manages the encryption keys and other security information used by the accelerator circuitry 102.

[0030] In at least one embodiment, the secure memory 312 is a secure SRAM with N entries (e.g., 512 entries), each entry having one valid bit. Each entry has a lower and a higher 128-bit component. 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 private interface 314. The SRAM can support read, write, and invalidation functions. When the SEC2 326 / GSP 328 programs the lower 128 bits of a 256-bit entry, the SRAM index can be marked as valid. An attempt to read an invalid SRAM entry will return 0x0 in the data register. In the event of a fatal error, the SRAM state is not 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] In at least one embodiment, the DMA circuit 304 includes three interrupt status registers, including a secure interrupt status register 356 and a regular interrupt status register in the PCI configuration space 258. The CPU 104 (and other PCI components on the PCI bus 202) can access the PCI configuration space 258. In at least one embodiment, the regular interrupt status register for the CPU is in the BAR0 space and is accessible to the CPU 104. If this register, belonging to any LCE, is non-zero, an interrupt line to the CPU is generated (via the interrupt controller GIN). However, the CPU 104 or other PCI components on the PCI bus 202 cannot access the secure interrupt status register 356. The secure interrupt status register 356 can be accessed by SEC2 326 and GSP 328. Specifically, the secure interrupt status register 356 may include a first secure interrupt status register of SEC2 326, which can only be accessed by SEC2 326 via the SECHUB-CE private interface 324. If the first secure interrupt status register, belonging to any LCE, is non-zero, an interrupt line to SEC2 326 is generated. The security interrupt status register 356 may include a second security interrupt status register for the GSP 328, which can only be accessed by the GSP 328 via the SECHUB-CE private interface 324. If the second security interrupt status register belonging to any LCE is non-zero, an interrupt line to the GSP 328 is generated. The SECHUB-CE private interface 324 only securely routes access from the SEC2 326 and GSP 328 to the DMA circuit 304. During operation in at least one embodiment, if any interrupt status bit in the interrupt status register 356 is set, one or more interrupt lines to the SEC2 326 and GSP 328 are activated. The SEC2 326 (or GSP 328) can read the interrupt status register 356 to determine the fault that caused the interrupt. The SEC2 326 (or GSP 328) can perform one or more operations to remove sensitive data from the context associated with cryptographic operations performed by the cryptographic circuit 322. As described herein, DMA circuit 304 can receive external reset 301 from untrusted software and can prevent DMA circuit 304 from being reset until all interrupt status bits in interrupt status register 356 are cleared by SECHUB 324, SEC2 326 and / or GSP 328. Once the interrupt status bits in interrupt status register 356 are cleared, indicating that the fault has been handled by SEC2 326 (or SECHUB 324 or GSP 328), DMA circuit 304 can acknowledge external reset 301 and reset.

[0032] Figure 4This is a block diagram of interrupt lines between the replication engine and the security processor and GPU system processor according to at least some embodiments. In at least one embodiment, the replication engine 120 includes a first secure interrupt line 402 connected to SEC2 326 (labeled ce2sec_secure_intr) and a second secure interrupt line 404 connected to GSP 328 (labeled ce2gsp_secure_intr). Each interrupt status bit can be configured to be applied to SEC2 326 or GSP 328 via a control signal 406 (INTR_TARGET). In at least one embodiment, all LCEs share interrupt lines 402, 404. If any interrupt status bit associated with any LCE is set, the interrupt line will be activated (e.g., go high). Software at SEC 326 or GSP 328 can read the interrupt status register to determine which LCE has an error. As described herein, SEC2 326 and GSP 328 can access replication engine 120 via a secure private interface 408 between SECHUB 324 and replication engine 120. A secure private interface 408 connects between SECHUB 324 and replication engine 120 and is not accessible via the PCI configuration space (BAR0). The interrupt status register is protected by a privilege level mask (PLM) to allow only the SEC2 326 and GSP 328 to clear interrupt status bits. The PLM has a series of values, where a larger number indicates higher privilege. Microcode running on the SEC2 326 and GSP 328 (e.g., microcontrollers) can also have security levels. If a register is PLM protected, it can be accessed by microcode whose privilege level matches or exceeds the register's PLM value. An auxiliary check called `source_id` can be used to apply a second filter. This second filter can be used to allow access only to a subset of microcode conforming to the PLM standard. As described herein, if any interrupt status bit is active, the LCE will suspend until the interrupt is cleared, even if a reset bit in the PCI configuration space is programmed. In at least one embodiment, the interrupt lines to the SEC2 326 and GSP 328 can be used for error reporting. In at least one embodiment, the interrupt line is stopped, level-based, and activated as long as the safety interrupt status register is not zero (i.e., one of the status register bits is set to 1).

[0033] In at least one embodiment, SEC2 326 can act as an agent on accelerator circuit 102 to establish secure sessions between virtual machines (VMs) (e.g., or other applications 208), within which SEC2 326 can execute a key exchange protocol to obtain memory encryption keys. Replication engine 120 can connect to SECHUB 324 as a client, and SEC2 326 can program encryption keys into key slots via the SECHUB interface. In another embodiment, GSP 328 can be a central security processor on accelerator circuit 102, thereby making GSP 328 the entity responsible for establishing secure sessions.

[0034] In at least one embodiment, the replication engine 120 includes two separate interrupt lines to SEC2 326 and GSP 328. For interrupt control, there are two interrupt status registers (one for SEC2 326 and one for GSP 328) that record any error type, an interrupt enable register that masks each error type on either status register, an interrupt target register for one-time programming of the GSP / SEC2 target for each error type, and two interrupt privilege level mask registers (one with GSP only, and one with SEC2 only for source isolation). In this example, SEC2 326 is running trusted microcode, while GSP 328 is running code whose state may be (indirectly) visible to a malicious actor. A malicious actor performing confidential computing might be a system administrator. Therefore, reporting an error to GSP 328 is necessary because the attack may have been carried out via a physical probe on the physical link, and the administrator might want to know about the security of the data center. However, if the attacker also gains access to GSP 328, the attacker can suppress interrupts to GSP 328. A secure interrupt to SEC2 326 addresses this problem. Even if the GSP 328 detects the error first, it cannot clear it. This is a mechanism to ensure that the tenant (data owner) receives an attack notification. The tenant can then choose to abandon the job, migrate to a more secure server, or inquire with the system administrator according to the Service Level Agreement (SLA). Furthermore, the GSP 328 can handle all interrupts on the GPU. Assigning a separate LCE to each user allows for designs with separate SEC2 SW processes to handle errors, thus providing error isolation. Therefore, one user might attempt to attack another user on the same GPU without knowing whether the attack was successful. Hiding the outcome of the attempted attack from the attacker is also a form of security protection.

[0035] Figure 5This is a flowchart of an encryption operation 500 in which an error is detected, according to at least some embodiments. Encryption operation 500 is a simplified AES-GCM operation that shows an error occurring before the complete data transmission is finished. For AES-GCM, blocks are numbered sequentially using a block counter (32'1). The value of the block counter is combined with a first IV (96'IV) (block 502) and encrypted with an AES block cipher to obtain a first result (block 504). Specifically, the first IV and the first value of the first block counter are encrypted with a first encryption key using a first block cipher to obtain the first result. The block counter is incremented with IV (96'IV) (32'2) (block 506) and encrypted with an AES block cipher to obtain a second result (block 508). In particular, the first IV and the second value of the first block counter are encrypted with a first encryption key using a second block cipher to obtain a second result. The second result and the first plaintext 510 are combined (e.g., XORed) (block 512) to obtain the first ciphertext 514. The first ciphertext 514 is combined with block 516 and zero block 515 to obtain the first value 518 of the hash key used for the first calculation. The first value 518 is a partial authentication tag used for the first data transmission.

[0036] The block counter is incremented by IV (96'IV) (32'3) (block 522) and encrypted with an AES block cipher to obtain a third result (block 524). Specifically, the third value of the first IV and the first block counter is encrypted using a first encryption key with a second block cipher to obtain the third result. The third result and the second plaintext 526 are combined (e.g., XORed) (block 528) to obtain the second ciphertext 530. The second ciphertext 530 is combined with the first value 518 of the first computed hash key stored in secure memory 560 (block 532) to obtain the second value 534 of the hash key used for the first computation. The second value 534 is a partial authentication tag used for the first data transmission.

[0037] At the end of the data transmission, the block counter is incremented by IV (96'IV) (32'N) (block 537) and encrypted with an AES block cipher to obtain a fourth result (block 538). Specifically, the first IV and the nth value of the first block counter are encrypted with the first encryption key using the Nth block cipher to obtain the fourth result. The fourth result and the Nth plaintext 540 are combined (e.g., XORed) (block 542) to obtain the Nth ciphertext 544. The Nth ciphertext 544 is combined with the Nth value of the first computed hash key stored in the secure memory 560 (block 546) to obtain the Nth value 548 of the first computed hash key. Since this is the last block of data transmission, the Nth value 548 is combined with the length of the ciphertext to obtain a fifth result 552. The fifth result 552 is combined with the first result from block 504 to obtain the first authentication tag 554.

[0038] like Figure 5 As shown, error 501 can be detected during encryption operation 500. When an error is detected, if a reset occurs before the error can be handled, some authentication tags, plaintext, IVs, or other sensitive data may be exposed to an attacker. Using the above embodiment, a reset will not occur until the security processor can clear one or more interrupt status bits associated with error 501. That is, the security processor can ensure that the plaintext is not exposed or that the IV can be reconfigured or reused by an attacker before a reset.

[0039] Figure 6 This is a flowchart of a decryption operation 600 in which an error is detected, according to at least some embodiments. Decryption operation 600 is a simplified AES-GCM operation, illustrating a context switch before complete data transmission. 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 using a first encryption key with a first block cipher 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). In particular, the first IV and the second value of the first block counter are encrypted using a first encryption key with a second block cipher to obtain a second result. The second result and the first ciphertext 610 are combined (e.g., XORed) (block 612) to obtain the first plaintext 614. The first ciphertext 610 and zero block 615 are combined in block 616 to obtain the first value 618 of the first computed hash key. The first value 618 is a partial authentication tag used for the first data transmission.

[0040] The block counter is incremented by IV (96'IV) (32'3) (block 622) and 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 using a first encryption key with a second block cipher to obtain the third result. The third result and the second ciphertext 626 are combined (e.g., XORed) (block 628) to obtain the second plaintext 630. The second ciphertext 626 is combined with the first value 618 of the first computed hash key stored in secure memory 660 (block 632) to obtain the second value 634 of the first computed hash key. The second value 634 is a partial authentication tag used for the first data transmission.

[0041] At the end of the data transmission, the block counter is incremented by 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 the first encryption key using the Nth block cipher to obtain the fourth result. The fourth result and the Nth ciphertext 640 are combined (e.g., XORed) (block 642) to obtain the Nth plaintext 644. The Nth plaintext 644 is combined with the Nth value of the first computed hash key stored in secure memory 660 (block 646) to obtain the Nth value 648 of the first computed hash key. Since this is the last block of data transmission, the Nth value 648 is combined with the ciphertext length to obtain a fifth result 652. The fifth result 652 is combined with the first result from block 604 to obtain a first authentication tag 654. The authentication tag can be compared with the expected authentication tag. If a match occurs, the operation is successful. If no match occurs, an error is detected as described herein.

[0042] like Figure 6 As shown, error 601 can be detected during decryption operation 600. When an error is detected, if a reset occurs before the error can be handled, some authentication tags, plaintext, IVs, or other sensitive data may be exposed to an attacker. Using the above embodiment, a reset will not occur until the security processor can clear one or more interrupt status bits associated with error 501. That is, the security processor can ensure that the plaintext is not exposed or that the IV can be reconfigured or reused by an attacker before a reset.

[0043] Figure 7 This is a flowchart of a method 700 for preventing untrusted software reset during cryptographic operations until one or more interrupt status bits are cleared, according to at least some embodiments. Method 700 can be performed by processing logic including hardware, software, firmware, or any combination thereof. In at least one embodiment, method 700 is performed by… Figure 1 , 2 Or accelerator circuit 102 of 3 is executed. In at least one embodiment, method 700 is performed by... Figure 1 , 2 Or, the replication engine 120 can be executed.

[0044] Reference Figure 7Method 700 begins with processing logic detecting an error associated with an encryption or decryption operation of the DMA engine's cryptographic hardware engine (block 702). The processing logic sets one or more interrupt status bits in a register accessible by the secure processor of the accelerator circuitry (block 704). The processing logic reports one or more interrupts associated with the error to the CPU coupled to the accelerator circuitry (block 706). The processing logic receives a reset signal from untrusted software executed by the CPU (block 708). The processing logic holds the reset signal until one or more interrupt status bits are cleared by the secure processor (block 710). In response to one or more interrupt status bits being cleared by the secure processor, the processing logic resets the DMA engine (block 712), and then method 700 ends.

[0045] In another embodiment, the processing logic performs one or more operations to protect the context associated with the encryption or decryption operation and clears one or more interrupt status bits in the register in response to one or more operations.

[0046] In a further embodiment, the processing logic detects a second error associated with a second encryption or decryption operation of the cryptographic hardware engine. The processing logic sets one or more interrupt status bits in a second register accessible by the GSP. The processing logic reports one or more interrupts associated with the second error to the CPU. The processing logic receives a second reset signal from untrusted software executed by the CPU. The processing logic holds the second reset signal until one or more interrupt status bits in the second register are cleared by the GSP. The processing logic resets the DMA engine in response to one or more interrupt status bits being cleared by the GSP.

[0047] Figure 8 This is a block diagram of a computing system 800 with an accelerator according to at least some embodiments, the accelerator including a replication engine that guarantees fairness among multiple users of the computing system. The computing system 800 is considered a headed system, wherein a main system processor CPU 104 delegates high-interrupt-frequency tasks to an accompanying microcontroller 804 coupled to accelerator circuitry 102. The computing system 800 is similar to computing system 100 as indicated by similar reference numerals, except that the computing system 800 includes the accompanying microcontroller 804. The computing system 800 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.

[0048] In some cases, Figure 8Larger models can be 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. Furthermore, 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 dedicated high-bandwidth SRAM to address these needs. SRAM can be used by accelerator circuitry 102 as a cache. SRAM can also be used by other high-performance computer vision-related components on the system to further reduce traffic to main system memory 114 (e.g., DRAM). Accelerator circuitry 102 enables interfacing with microcontroller 804 (or a dedicated control coprocessor) to limit interrupt load on CPU 104. In at least one embodiment, microcontroller 804 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 804), the main processor (CPU 104) can handle some of the tasks associated with managing accelerator circuitry 102. For example, although the hardware scheduler circuit is responsible for the scheduling and fine-grained programming of the accelerator circuit 102, the microcontroller 804 or CPU 104 can still handle some coarse-grained scheduling of the accelerator circuit 102, input-output memory management (IOMMU) mapping of memory accesses, memory allocation of input data and fixed weight arrays on the accelerator circuit 102, as well as synchronization between other system components and tasks running on the accelerator circuit 102, as needed.

[0049] 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 integrated 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 performing inference, training, or any other processing of 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.

[0050] As an example, a processor 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 a processor can be used in autonomous vehicles (e.g., cars, motorcycles, helicopters, drones, airplanes, ships, submarines, delivery robots, etc.) to enable the vehicle to move in the real world. Furthermore, such a processor can be used in robots in factories to select parts and assemble parts into components.

[0051] 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 instance, 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 the rendering device to the display device over a network (e.g., the Internet, mobile telecommunications networks, Wi-Fi networks, and any other wired or wireless networking system). Such transmissions can be used 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 streaming image services such as NVIDIA GeForce Now (GFN), Google Stadia, etc.

[0052] As an example, a processor incorporating the techniques disclosed herein can be used to process one or more neural networks for any other type of application that can utilize neural networks. Such applications might 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.

[0053] 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 the specific one or more 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.

[0054] Unless otherwise stated herein or obviously contradicted by the context, the use of the terms “a”, “an”, “the”, and similar designations in the context of describing the disclosed embodiments (especially in the context of the following claims) shall be interpreted as encompassing both the singular and plural and not as definitions of the terms. Unless otherwise stated, the terms “comprising,” “having,” “including,” and “containing” shall be interpreted as open-ended terms (meaning “including, but not limited to”). “Connection,” when unmodified and referring to a physical connection, shall be interpreted as being partially or wholly contained in, attached to, or connected together, even if something intervenes. Unless otherwise stated herein, the enumeration of numerical ranges herein is intended only as a shorthand method for individually referring to each individual value falling within that range. Each individual value is included in the specification as if it were individually referenced herein. In at least one embodiment, unless otherwise stated or contradicted by the context, the use of the terms “set” (e.g., “item set”) or “subset” shall be interpreted as a non-empty set comprising one or more members. Furthermore, unless otherwise stated or contradicted by the context, the term “subset” of the corresponding set does not necessarily mean a proper subset of the corresponding set, but rather that the subset and the corresponding set can be equal.

[0055] Unless explicitly stated otherwise or clearly contradicted by the context, it is understood that conjunctions such as phrases in the form of "at least one of A, B, and C" or "at least one of A, B, and C" can be used in contexts generally used to refer to items, terms, etc., where the context can be A or B or C, or any non-empty subset of the set of A and B and C. For example, in an illustrative case of a set with three members, the conjunctions "at least one of A, B, and C" and "at least one of A, B, and C" refer to any one of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Therefore, such conjunction language is generally not intended to imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C. Furthermore, unless explicitly stated otherwise 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 indicated or indicated by the context. Furthermore, unless otherwise stated or clearly indicated from the context, the word "based on" means "at least partially based on" rather than "based on only".

[0056] The operations of the processes described herein can be performed in any suitable order unless otherwise stated herein or obviously contradicted by the context. In at least one embodiment, processes such as those described herein (or variations 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 applications) executed jointly on one or more processors via hardware or a combination thereof. In at least one embodiment, code, for example in the form of a computer program, is stored on a computer-readable storage medium comprising a plurality of instructions executable by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transient computer-readable storage medium that does not include transient signals (e.g., propagation of transient electrical or electromagnetic transmissions) but includes non-transient data storage circuitry (e.g., buffers, caches, and queues) within a transient signal transceiver. 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 storing executable instructions) on which executable instructions are stored, causing the computer system to perform the operations described herein when the executable instructions are executed by one or more processors of a computer system (i.e., as a result of execution). In at least one embodiment, the set of non-transitory computer-readable storage media comprises multiple non-transitory computer-readable storage media, and one or more individual non-transitory storage media lack all the code, while the multiple non-transitory computer-readable storage media collectively store all the 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 store the instructions and the main central processing unit (“CPU”) executes some instructions while the graphics processing unit (“GPU”) and / or data processing unit (“DPU”)—possibly in conjunction with the GPU—executes other instructions. In at least one embodiment, different components of the computer system have separate processors and different processors execute different subsets of instructions.

[0057] Therefore, in at least one embodiment, the computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such a computer system is configured with suitable hardware and / or software capable of performing 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 differently operating devices, such that the distributed computer system performs the operations described herein and that a single device does not perform all the operations.

[0058] 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 stated. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0059] All references cited in this article, including publications, patent applications and patents, are incorporated into this article to the same extent as if each reference were individually and specifically indicated to be incorporated into and fully elaborated in this article.

[0060] The terms “coupled” and “connected”, as well as 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.

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

[0062] Similarly, the term "processor" can refer to any device or part of a device 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. Furthermore, each process can refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. 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.

[0063] 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 of a function call or by calling 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 using data as an input or output parameter of a function call, a parameter of an application programming interface, or an inter-process communication mechanism.

[0064] 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 a specific allocation of responsibilities may be defined above for the purposes of description, various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0065] 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: A direct memory access (DMA) engine coupled to a central processing unit (CPU) includes a cryptographic hardware engine. as well as A security processor, coupled to the DMA engine via a private interface and to the CPU via an encrypted interface, wherein the DMA engine is used for: Detect errors associated with encryption or decryption operations of the cryptographic hardware engine; Set one or more interrupt status bits in a first register accessible to the security processor; Report one or more interrupts associated with the error to the CPU and the security processor; Receive a reset signal from untrusted software executed by the CPU; The reset signal is maintained until the one or more interrupt status bits are cleared by the security processor; as well as A reset is initiated in response to the clearing of one or more interrupt status bits by the security processor.

2. The accelerator circuit of claim 1, further comprising an interrupt controller coupled to the DMA engine and the CPU, wherein the interrupt controller is configured to receive the one or more interrupts from the DMA engine and send the one or more interrupts to the CPU.

3. The accelerator circuit of claim 1, wherein the security processor is used for: Perform one or more operations to protect the context associated with the encryption or decryption operation; and In response to the one or more operations, the one or more interrupt status bits in the first register are cleared.

4. The accelerator circuit of claim 3, wherein the security processor is further configured to execute trusted software, wherein the trusted software is configured to send the one or more interrupts to the untrusted software.

5. The accelerator circuit as claimed in claim 1, wherein the cryptographic hardware engine is an Advanced Encryption Standard Galois Counter Mode (AES-GCM) hardware engine.

6. The accelerator circuit of claim 1, wherein the DMA engine comprises: The first register is accessible to the security processor, wherein the first register is not accessible to the CPU; and The CPU-accessible second register, wherein the second register is a memory-mapped input / output (MMIO).

7. The accelerator circuit as described in 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).

8. The accelerator circuit of claim 1, wherein the accelerator circuit is a graphics processing unit (GPU), wherein the DMA engine includes a second register accessible by the CPU, wherein the untrusted software is a first resource manager, wherein the DMA engine is configured to receive the reset signal by setting bits in the second register via the first resource manager, wherein the second resource manager, executed by the secure processor, is configured to clear the one or more interrupt status bits in the first register.

9. The accelerator circuit of claim 1, wherein the accelerator circuit includes a control register in the CPU-accessible Peripheral Component Interconnect (PCI) configuration space, wherein the first register is not accessible by the CPU.

10. The accelerator circuit of claim 1, wherein the DMA engine comprises: The first interrupt line is activated if any interrupt status bit in the first register is set. First logical replication engine LCE; A first physical replication engine (PCE) is coupled to the first LCE and includes the cryptographic hardware engine; A second PCE is coupled to the first LCE and includes a second cryptographic hardware engine; as well as A second LCE, wherein a second resource manager executed by the security processor reads the first register to determine which of the first LCE or the second LCE has the error.

11. The accelerator circuit of claim 1, wherein the accelerator circuit is a graphics processing unit (GPU), wherein the GPU includes the DMA engine, the security processor, and the GPU system processor (GSP), wherein the GSP is coupled to the DMA engine via a proprietary interface, wherein the DMA engine is further configured to: Detect a second error associated with a second encryption or decryption operation of the cryptographic hardware engine; Set one or more interrupt status bits in the second register accessible by the GSP; Report one or more interrupts associated with the second error to the CPU; Receive a second reset signal from the untrusted software executing the CPU; The second reset signal is maintained until one or more interrupt status bits in the second register are cleared by the GSP; and A reset is initiated in response to one or more interrupt status bits being cleared by the GSP.

12. The accelerator circuit of claim 11, further comprising a security hub coupled to the DMA engine, the security processor, and the GSP.

13. A method for preventing reset of untrusted software, comprising: Errors associated with encryption or decryption operations performed by the cryptographic hardware engine of the accelerator circuit's direct memory access (DMA) engine are detected by the accelerator circuit. Set one or more interrupt status bits in a register accessible by the security processor of the accelerator circuit; Report one or more interrupts associated with the error to the central processing unit (CPU) coupled to the accelerator circuitry; Receive a reset signal from the untrusted software executing the CPU; The reset signal is maintained until the one or more interrupt status bits are cleared by the security processor; as well as A reset is initiated in response to the clearing of one or more interrupt status bits by the security processor.

14. The method of claim 13, further comprising: Perform one or more operations to protect the context associated with the encryption or decryption operation; as well as In response to the one or more operations, clear the one or more interrupt status bits in the register.

15. The method of claim 13, further comprising: Detect a second error associated with a second encryption or decryption operation of the cryptographic hardware engine; Set one or more interrupt status bits in a second register accessible by the GPU system processor GSP; Report one or more interrupts associated with the second error to the CPU; Receive a second reset signal from the untrusted software executing the CPU; The second reset signal is maintained until the one or more interrupt status bits in the second register are cleared by the GSP; as well as A reset is initiated in response to one or more interrupt status bits being cleared by the GSP.

16. An accelerator system, comprising: Central Processing Unit (CPU); as well as Graphics processing unit (GPU) coupled to the CPU, wherein the GPU includes: Direct Memory Access (DMA) circuitry, including an Advanced Encryption Standard Galois Counter Mode (AES-GCM) hardware engine; and A processor, coupled to the DMA circuitry via a proprietary interface and to the CPU via an encrypted interface, wherein the DMA circuitry is used for: Detect errors associated with encryption or decryption operations of the AES-GCM hardware engine; Set one or more interrupt status bits in a first register accessible to the processor; Report one or more interrupts associated with the error to the CPU; Receive a reset signal from untrusted software executed by the CPU; The reset signal is maintained until the one or more interrupt status bits are cleared by the processor; and A reset is initiated in response to one or more interrupt status bits being cleared by the processor.

17. The system of claim 16, wherein the processor is at least one of a security processor or a GPU system processor.

18. The system of claim 16, wherein the processor is configured to: Perform one or more operations to protect the context associated with the encryption or decryption operation; and In response to the one or more operations, the one or more interrupt status bits in the first register are cleared.

19. The system of claim 16, wherein the DMA circuit comprises: The first register accessible to the processor, wherein the first register is not accessible to the CPU; and The CPU-accessible second register, wherein the second register is a memory-mapped input / output (MMIO), wherein the untrusted software is a first resource manager for sending the reset signal by setting bits in the second register being programmed, wherein the second resource manager executed by the processor is used to clear the one or more interrupt status bits.

20. The system of claim 16, wherein the DMA circuitry includes a second register accessible by the CPU, wherein the untrusted software is a first resource manager, wherein the first resource manager is configured to send the reset signal via bits in the second register being programmed, and wherein the second resource manager executed by the processor is configured to clear the one or more interrupt status bits.

Images