Direct user-mode work submission in processors that support secure computing

Abstract

This disclosure relates to direct user-mode job submission in a processor that supports secure computing. Various embodiments include systems for initiating tasks in a computing system operating in secure mode. The system includes a central processing unit (CPU) that can access insecure memory but not secure memory. The system also includes an accelerator (e.g., a GPU) that can access both insecure and secure memory. The CPU encrypts the copy task and the secure task for the accelerator and stores both in the insecure memory. A copy engine in the accelerator reads, decrypts, and authenticates the copy task and stores the decrypted copy task in secure memory. The copy engine executes the decrypted copy task to read, decrypt, and authenticate the secure task and stores the decrypted secure task in secure memory. The accelerator schedules the decrypted secure task to execute in secure mode.

Description

TECHNICAL FIELD

[0001] Various embodiments relate generally to parallel processing computing architectures, and more particularly to direct user mode work submission in processors that support secure computing. BACKGROUND

[0002] A computing system generally includes, among other things, one or more processing units, such as central processing units (CPUs) and / or graphics processing units (GPUs), and one or more memory systems. The processing units execute user mode software applications that submit and initiate compute tasks, referred to herein as "work," to "channels" executing on one or more compute engines included in the processing units. The user mode software applications submit and initiate the work by writing a stream of commands, referred to herein as "methods," to a data structure located in memory. This data structure is referred to herein as a "push buffer segment." A pointer to the push buffer segment is written to a push buffer to initiate processing of the methods in the push buffer segment. The user mode software applications notify a scheduler of pending work. Upon receiving the notification, the scheduler schedules the methods contained in the channels for execution on target compute engines based on a scheduling algorithm. The scheduler reads the push buffer data from memory, processes the push buffer data, and forwards the corresponding methods to the target compute engines for execution.

[0003] Under certain conditions, a computing system can run in a secure mode in which data associated with a process running in one context is protected from interference or unauthorized access from other processes running in other contexts, or in some cases, from the operating system and / or hypervisor. When a processing unit runs in secure mode, access to certain portions of memory is restricted to provide a secure work space. In one example, when a GPU runs in secure mode, only the scheduler is allowed to access the push buffer segments, the push buffers, and pointers to certain channels from within a compute-protected region of the GPU's memory. Furthermore, since the path to the protected region of the GPU's memory is untrusted, a user mode driver executing on the CPU cannot directly write to the compute-protected region to update these data structures in order to submit new work. Instead, only certain secure processors that execute signed secure microcode and certain direct memory access (DMA) engines, also referred to herein as "replication engines," can move data into the compute-protected region. Thus, when the GPU runs in secure mode, the CPU cannot directly initiate new work to the GPU.

[0004] One possible method for enabling the CPU to launch new work to the GPU running in secure mode is for the user mode driver to write the new push buffer in encrypted form to the unsecure system memory. The user mode driver sends a request to the secure microcode executing on the secure processor to copy the encrypted data from system memory, decrypt and validate the encrypted data, and write the decrypted data to the compute protected region for the dispatcher to process. The secure processor notifies the dispatcher of the new work. Thus, whenever any one or more user mode software applications submit new work, the secure processor performs the copy, decryption, validation, and notification tasks to submit the new work to the dispatcher. Generally, the secure processor is not designed for such bulk data movement. Moreover, a typical GPU can have only one or two secure processors compared to tens of compute engines, each of which can support thousands of lanes. In such a GPU, the one or two secure processors are responsible for processing the work of tens of thousands or even hundreds of thousands of lanes. As a result, when user mode software applications submit and launch a large number of compute tasks, the secure processor becomes a bottleneck, causing performance degradation.

[0005] Another possible method for enabling the CPU to launch new work to the GPU running in secure mode is for the secure processor to program the copy engine lanes to move the new work submitted by the user mode driver into the compute protected region. One drawback of this approach is that it introduces an extra level of indirection such that the user mode driver on the CPU submits the new work to the secure processor, the secure processor programs the copy engine to move the new work, and the dispatcher forwards the corresponding method to the target compute engine for execution. This extra indirection increases the processing latency of the new work, causing extra latency in launching the new work. In extreme cases, this work launch latency can be high enough to render the GPU unusable as an accelerator when running in secure mode.

[0006] As previously mentioned, there is a need in the art for more efficient techniques for launching new work on processing units running in secure mode. SUMMARY

[0007] Various embodiments of the present disclosure set forth a computer-implemented method for launching a secure task on a processing unit. The method includes reading an encrypted copy task from unsecure memory. The method also includes decrypting the encrypted copy task to generate a decrypted copy task. The method also includes executing the decrypted copy task to cause an encrypted secure task to be copied from unsecure memory to secure memory. The method also includes decrypting the encrypted secure task to generate a decrypted secure task. The method also includes scheduling the decrypted secure task for execution.

[0008] Other embodiments include systems that implement one or more aspects of the disclosed technology, as well as one or more computer-readable media comprising instructions for performing one or more aspects of the disclosed technology, and methods for performing one or more aspects of the disclosed technology.

[0009] At least one technical advantage of the disclosed technology over the prior art is that with the disclosed technology, the secure processor is not directly involved in initiating a job in addition to initializing the job start channel. Rather, job initiation is performed by the replication engine, which is a more resource-rich than the secure processor. Typically, the replication engine is designed to saturate the interface bandwidth while decrypting and validating data. Unlike the secure processor, the replication engine is specifically designed to perform fast secure data movement. As a result, the initiation delay of a new job is reduced and performance is improved compared to previous methods. Another advantage of the disclosed technology is that the replication engine copies encrypted data from the unsecure system memory, decrypts the data, validates the data, and stores the decrypted data in secure memory. Thus, the replication engine is able to initiate a new job in a secure mode without compromising security. These advantages represent one or more technical improvements over prior art methods. BRIEF DESCRIPTION OF DRAWINGS

[0010] For a more detailed description of the relevant features of the various embodiments described above, reference is made to the detailed description of the invention concepts briefly summarized above, which is described in connection with the various embodiments, some of which are illustrated in the drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the invention concepts and in no way limit the scope of the application, as there are many other effective embodiments.

[0011] Figure 1 is a block diagram of a computer system configured to implement one or more aspects of the various embodiments;

[0012] Figure 2 is a block diagram of an accelerator processing subsystem of Figure 1 including a parallel processing unit (PPU) included in the accelerator processing subsystem of

[0013] Figure 3 is a block diagram of a general processing cluster (GPC) included in the parallel processing unit (PPU) of Figure 2 including a parallel processing unit (PPU) included in the accelerator processing subsystem of

[0014] Figure 4 is a block diagram of a secure task initiation system included in the PPU of Figure 2 including a parallel processing unit (PPU) included in the accelerator processing subsystem of

[0015] Figure 5 is a block diagram of a secure task initiation system included in the PPU of Figures 1-2a block diagram of unprotected memory of a PP memory and data structures in a compute protected region; and

[0016] Figure 6 a flowchart of method steps for launching a secure task on an accelerator (e.g. Figure 2 a PPU) running in a secure mode in accordance with various embodiments. DETAILED DESCRIPTION

[0017] In the following description, numerous specific details are set forth to provide a more thorough understanding of the different embodiments. However, it will be apparent to one skilled in the art that the present inventive concepts can be practiced without one or more of these specific details.

[0018] System Overview

[0019] Figure 1 A block diagram of a computer system 100 configured to implement one or more aspects of the various embodiments is shown. As shown, the computer system 100 includes, but is not limited to, a central processing unit (CPU) 102, a system memory 104, which is coupled via a memory bridge 105 and communication path 113 to an accelerator processing subsystem 112. The memory bridge 105 is further coupled via a communication path 106 to an I / O (input / output) bridge 107, which is in turn coupled to a switch 116.

[0020] In operation, the I / O bridge 107 is configured to receive user input information from an input device 108, such as a keyboard or mouse, and forward the input information to the CPU 102 for processing via the communication path 106 and the memory bridge 105. In some examples, the input device 108 is used to verify the identity of one or more users to allow authorized users to access the computer system 100 and deny unauthorized users access to the computer system 100. The switch 116 is configured to provide connectivity between the I / O bridge 107 and other components of the computer system 100, such as a network adapter 118 and various additional cards 120 and 121. In some examples, the network adapter 118 is used as a primary or dedicated input device to receive input data for processing via the disclosed techniques.

[0021] As also shown in the figure, I / O bridge 107 is coupled to system disk 114, which can be configured to store content, applications, and data for use by CPU 102 and accelerator processing subsystem 112. Generally, system disk 114 provides non-transitory storage for applications and data and may include fixed or removable hard disk drives, flash memory devices, and CD-ROMs (optical disc read-only memory), DVD-ROMs (digital versatile discs), Blu-ray, HD-DVDs (high-definition DVDs), or other magnetic, optical, or solid-state storage devices. Finally, although not explicitly shown, other components (such as universal serial bus or other port connections, optical disc drives, digital versatile disc drives, film recording devices, etc.) may also be connected to I / O bridge 107.

[0022] In various embodiments, memory bridge 105 may be a northbridge chip, and I / O bridge 107 may be a southbridge chip. Furthermore, communication paths 106 and 113, as well as other communication paths, can be implemented within computer system 100 using any technically suitable protocol (including but not limited to High-Speed ​​Peripheral Component Interconnect (PCIe), HyperTransport, or any other bus or point-to-point communication protocol known in the art).

[0023] In some embodiments, the accelerator processing subsystem 112 includes a graphics subsystem that supplies pixels to a display device 110, which can be any conventional cathode ray tube, liquid crystal display, light-emitting diode display, etc. In this embodiment, the accelerator processing subsystem 112 incorporates circuitry optimized for graphics and video processing, including, for example, video output circuitry. (The following is a continuation of the previous paragraph.) Figure 2 As described in more detail below, this circuitry can be incorporated across one or more accelerators included in the accelerator processing subsystem 112. An accelerator includes any or more processing units capable of executing instructions, such as a central processing unit (CPU). Figures 2-4 Parallel processing units (PPU), graphics processing units (GPU), intelligent processing units (IPU), neural processing units (NAU), tensor processing units (TPU), neural network processors (NNP), data processing units (DPU), vision processing units (VPU), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), etc.

[0024] In some embodiments, accelerator processing subsystem 112 includes two processors, referred to herein as a primary processor (typically a CPU) and a secondary processor. Typically, the primary processor is a CPU and the secondary processor is a GPU. Additionally or alternatively, each of the primary processor and the secondary processor can be any one or more types of accelerators disclosed herein, in any technically feasible combination. The secondary processor receives secure commands from the primary processor via an unsecure communication path. The secondary processor accesses memory and / or other storage systems, such as system memory 104, Compute Express Link (CXL) memory extenders, memory-managed disk storage, on-chip memory, etc. The secondary processor accesses this memory and / or other storage systems over an unsecure connection. The primary processor and the secondary processor can communicate with each other via a GPU-to-GPU communication channel, such as Nvidia Link (NVLink). Further, the primary processor and the secondary processor can communicate with each other via network adapter 118. Typically, the distinction between the unsecure communication path and the secure communication path depends on the application. A particular application program typically considers communication within a die or package to be secure. Communication of unencrypted data over a standard communication channel (e.g., PCIe) is considered unsecure.

[0025] In some embodiments, accelerator processing subsystem 112 incorporates circuitry optimized for general-purpose and / or compute processing. Again, such circuitry can be incorporated across one or more accelerators included in accelerator processing subsystem 112 that are configured to perform such general-purpose and / or compute operations. In other embodiments, one or more accelerators included in accelerator processing subsystem 112 are configurable to perform graphics processing, general-purpose processing, and compute processing operations. System memory 104 includes at least one device driver 103 that is configured to manage processing operations of one or more accelerators in accelerator processing subsystem 112.

[0026] In various embodiments, accelerator processing subsystem 112 can be integrated with one or more other elements of Figure 1 to form a single system. For example, accelerator processing subsystem 112 can be integrated with CPU 102 and other connection circuitry on a single chip to form a system-on-a-chip (“SoC”).

[0027] It should be understood that the system shown herein is illustrative and that variations and modifications are possible. The connection topology (including the number and arrangement of network bridges, the number of CPUs 102, and the number of accelerator processing subsystems 112) can be modified as desired. For example, in some embodiments, system memory 104 can be connected directly to CPU 102, rather than through memory bridge 105, and other devices would communicate with system memory 104 via memory bridge 105 and CPU 102. In other alternative topologies, accelerator processing subsystems 112 can be connected to I / O bridge 107 or directly to CPU 102, rather than to memory bridge 105. In other embodiments, I / O bridge 107 and memory bridge 105 can be integrated into a single chip, rather than existing as one or more discrete devices. Finally, in certain embodiments, Figure 1 One or more of the components shown can not be present. For example, in some embodiments, the exchange 116 can be eliminated, and the network adapters 118 and additional cards 120, 121 would connect directly to the I / O bridge 107.

[0028] Figure 2 is an accelerator processing subsystem 112 in accordance with various embodiments Figure 1 A block diagram of a parallel processing unit (PPU) 202 included in the accelerator processing subsystem 112 of Figure 2 One PPU 202 is described, but as mentioned above, the accelerator processing subsystem 112 can include any number of PPUs 202. Moreover, Figure 2 The PPU 202 of Figure 1 An accelerator included in the accelerator processing subsystem 112 of Figures 2-4 The techniques disclosed in relation to the PPU 202 in apply equally to any type of accelerator included within the accelerator processing subsystem 112 in any combination. As shown, the PPU 202 is coupled to a local parallel processing (PP) memory 204. The PPU 202 and the PP memory 204 can be implemented by one or more integrated circuit devices, such as programmable processors, application specific integrated circuits (ASICs), or memory devices, or any other technologically feasible means.

[0029] In some embodiments, PPU 202 includes a graphics processing unit ("GPU") that is configurable to perform a variety of graphics processing operations, including graphics processing operations in support of graphics rendering pipeline. In processing graphics data, PP memory 204 can be used as graphics memory to store one or more frame buffers (and, if desired, one or more other render targets) as well. PP memory 204 can be used, among other things, to store and update pixel data, and to transfer final pixel data or display frames to display device 110 for display. In some embodiments, PPU 202 can also be configured to general-purpose processing and computing operations.

[0030] In operation, CPU 102 is the main processor of computer system 100, controlling and coordinating the operations of the other system components. In particular, CPU 102 issues commands that control the operation of PPU 202. In some embodiments, CPU 102 writes a command stream for PPU 202 into a data structure (not explicitly shown) that can be located in system memory 104, PP memory 204, or another storage location accessible to both CPU 102 and PPU 202. In addition, or in the alternative, a processor and / or accelerator other than CPU 102 can write one or more command streams for PPU 202 into the data structure. A pointer to the data structure is written into a push buffer to initiate processing of the command stream(s) in the data structure. PPU 202 reads the command stream from the push buffer and then executes the commands asynchronously with respect to the operation of CPU 102. In embodiments in which multiple push buffers are generated, an application can specify, via device driver 103, an execution priority for each push buffer to control the scheduling of different push buffers. Figure 1 Figure 2

[0031] As also shown, PPU 202 includes an I / O (input / output) unit 205 that communicates with the rest of computer system 100 via communication path 113 and memory bridge 105. I / O unit 205 generates data packets (or other signals) to be transmitted on communication path 113 and also receives all incoming data packets (or other signals) from communication path 113, directing the incoming data packets to the respective components of PPU 202. For example, commands related to processing tasks can be directed to host interface 206, while commands related to memory operations (e.g., reading from or writing to PP memory 204) can be directed to crossbar unit 210. Host interface 206 reads each push buffer and sends the command stream stored in the push buffer to front end 212.

[0032] As noted above in connection with Figure 1 ​​The connection of the PPU 202 to the rest of the computer system 100 can vary. In some embodiments, the accelerator processing subsystem 112, which includes at least one PPU 202, is implemented as an add-in card that is inserted into a bus slot of a computer system 100. In other embodiments, the PPU 202 is integrated on a

[0033] In operation, the front-end 212 sends processing tasks received from the host interface 206 to a work distribution unit (not shown) within the task / work unit 207. The work distribution unit receives pointers to processing tasks, which are encoded as task metadata (TMD) and stored in memory. The pointers to the TMD are included in a command stream that is stored as a push buffer and received by the front-end 212 from the host interface 206. The processing tasks that can be encoded as TMD include an index associated with data to be processed, as well as state parameters and commands that define how to process the data. For example, the state parameters and commands can define a program to be executed on the data. The task / work unit 207 receives tasks from the front-end 212 and ensures that the GPCs 208 are configured in an active state before initiating each processing task specified by the TMD. A priority can be specified for each TMD, which is used to schedule execution of the processing tasks. Processing tasks can also be received from the processing cluster array 230. Optionally, the TMD can include a parameter that controls whether the TMD is added to the head or tail of a list of processing tasks (or a list of pointers to processing tasks), thereby providing another level of control over the priority of execution.

[0034] The PPU 202 advantageously implements a highly parallel processing architecture with a processing cluster array 230 that includes a group of C general processing clusters (GPCs) 208, where C > 1. Each GPC 208 is capable of executing a large number (e.g., hundreds or thousands) of threads concurrently, where each thread is an instance of a program. In various applications, different GPCs 208 can be allocated to

[0035] Memory interface 214 includes a set of D partition units 215, where D > 1. Each partition unit 215 is coupled to one or more dynamic random access memories (DRAMs) 220 that reside within PP memory 204. In one embodiment, the number of partition units 215 is equal to the number of DRAMs 220, with each partition unit 215 coupled to a different DRAM 220. In other embodiments, the number of partition units 215 can be different from the number of DRAMs 220. One of ordinary skill in the art will recognize that DRAMs 220 can be replaced by any other technically suitable storage device. In operation, various render targets, such as texture maps and frame buffers, can be stored across DRAMs 220, allowing partition units 215 to write portions of each render target in parallel, effectively using available bandwidth of PP memory 204.

[0036] A given GPC 208 can process data to be written to any of the DRAMs 220 within PP memory 204. Crossbar unit 210 is configured to route the output of each GPC 208 to the input of any partition unit 215 or to any other GPC 208 for further processing. GPCs 208 communicate with memory interface 214 via the crossbar unit 210 to read from or write to various DRAMs 220. In one embodiment, crossbar unit 210 is connected to I / O unit 205 in addition to being connected to memory interface 214 via PP memory 204, enabling processing cores in different GPCs 208 to communicate with system memory 104 or other memories not local to PPU 202. In Figure 2 In embodiments, crossbar unit 210 is connected with I / O unit 205. In various embodiments, crossbar unit 210 can use virtual channels to separate traffic between GPCs 208 and partition units 215.

[0037] Likewise, GPC 208 can be programmed to perform processing tasks related to various applications, including, but not limited to, linear and nonlinear data transforms, filtering of video and / or audio data, modeling operations (e.g., application of physical laws such as fluid mechanics to determine the movement of a fluid mesh over time), mesh rendering operations (e.g., tessellation shading programs, vertex shading programs, geometry shading programs, and / or pixel / fragment shading programs), general compute operations, etc. In operation, PPU 202 is configured to transfer data from system memory 104 and / or PP memory 204 to one or more on-chip memory units, process the data, and write results to system memory 104 and / or PP memory 204. Other system components (including CPU 102, another PPU 202 in accelerator processing subsystem 112, or another accelerator processing subsystem 112 in computer system 100) can then access the results data.

[0038] As noted above, any number of PPUs 202 can be included in accelerator processing subsystem 112. For example, a plurality of PPUs 202 can be provided on a single add-in card, or multiple add-in cards can be connected to communication path 113, or one or more PPUs 202 can be integrated into a bridge chip. PPUs 202 in multi-PU systems can be identical or different. For instance, different PPUs 202 might have different numbers of processing cores and / or different amounts of PP memory 204. In implementations where multiple PPUs 202 are present, the PPUs can operate in parallel to process data with a throughput that is greater than would be possible with a single PPU 202. Systems including one or more PPUs 202 can be implemented in various configurations and form factors, including but not limited to desktop, laptop, handheld personal computer, or other handheld device, server, workstation, game console, embedded system, etc.

[0039] Figure 3 is in accordance with various embodiments Figure 2a block diagram of a general processing cluster (GPC) 208 included within a parallel processing unit (PPU) 202. In operation, GPC 208 can be configured to execute a large number of threads in parallel to perform graphics, general processing, and / or compute operations. As used herein, a "thread" refers to an instance of a particular program executing on a particular set of input data. In some embodiments, single-instruction, multiple-data (SIMD) instruction issue techniques are used to support parallel execution of a large number of threads. In other embodiments, single-instruction, multiple-thread (SIMT) techniques are used to support parallel execution of a large number of threads. Unlike SIMD execution, where all processing engines typically execute the same instructions, SIMT execution allows different threads to follow different execution paths through a given program. Persons of ordinary skill in the art will recognize that a SIMD processing architecture represents a functional subset of a SIMT processing architecture.

[0040] Operation of GPC 208 is controlled via a pipeline manager 305 that distributes processing tasks to one or more stream processors (SPs) 310. The pipeline manager 305 can also be configured to control the operation of work distribution crossbar 330 by specifying destinations for processed data output by the SPs 310.

[0041] In one embodiment, GPC 208 includes a group of M SPs 310, where M > 1. Further, each SP 310 includes a group of function execution units (FEUs) (not shown), such as execution units and load store units. Processing operations for a particular FEU can be pipelined such that a new instruction can be issued before a previous instruction has completed execution. Any combination of FEUs can be provided within a given SP 310. In various embodiments, the FEUs can be configured to support a variety of different operations, including integer and floating-point arithmetic (e.g., addition and multiplication) comparison operations, Boolean operations (e.g., AND, OR, XOR), bit shifts, and computation of various algebraic functions (e.g., planar interpolation and trigonometric, exponential, and logarithmic functions). Advantageously, the same FEUs can be configured to perform different operations.

[0042] In operation, each SM 310 is configured to process one or more thread groups. As used herein, a "thread group" or "warp" refers to a group of threads that execute the same program, where one thread in the group is assigned to a different execution unit in the SM 310. A thread group can include fewer threads than the number of execution units in the SM 310, in which case some execution units can be idle during processing of this thread group. A thread group can also include more threads than the number of execution units in the SM 310, in which case processing can occur in successive clock cycles. Since each SM 310 can support up to G thread groups, up to G*M thread groups can be executed by a PPU 202 at any given time.

[0043] Further, multiple related thread groups can be active (in different execution stages) in the SM 310 at the same time. This set of thread groups is referred to herein as a "cooperative thread array" ("CTA") or "thread array." The size of a particular CTA is equal to m*k, where k is the number of threads in a thread group, which typically is an integer number of the number of execution units in the SM 310, and m is the number of thread groups that are simultaneously active in the SM 310. In various embodiments, software applications written in the Compute Unified Device Architecture (CUDA) programming language describe the behavior and operation of threads executing on the GPC 208, including any of the behavior and operation described above. A given processing task can be specified in a CUDA program such that the SM 310 can be configured to perform and / or manage general compute operations.

[0044] Although Figure 3 Not shown is a level one (LI) cache or use of space in a respective LI cache external to the SM 310 to support load and store operations of the execution units, etc. Each SM 310 can also have access to a level two (L2) cache (not shown) shared by all GPCs 208 in the PPU 202. The L2 cache can be used to transfer data between threads. Finally, the SM 310 can also access off-chip "global" memory, which can include the PP memory 204 and / or system memory 104. It is to be understood that any memory external to the PPU 202 can be used as global memory. Further, as discussed above, the global memory can include the PP memory 204 and / or system memory 104. Figure 3As shown, GPC 208 may include a Level 1.5 (L1.5) cache 335, which is configured to receive and store data requested from memory by SM 310 via memory interface 214. This data may include, but is not limited to, instructions, uniform data, and constant data. In embodiments where GPC 208 has multiple SMs 310, the SMs 310 may advantageously share common instructions and data cached in the L1.5 cache 335.

[0045] Each GPC 208 may have an associated memory management unit (MMU) 320 configured to map virtual addresses to physical addresses. In various embodiments, the MMU 320 may reside within the GPC 208 or the memory interface 214. The MMU 320 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of tiles or memory pages, optionally mapping to cache line indices. The MMU 320 may include an address translation back buffer (TLB) or a cache residing within the SM 310, one or more L1 caches, or the GPC 208.

[0046] In graphics and computing applications, the GPC 208 can be configured to couple each SM 310 to a texture unit 315 to perform texture mapping operations, such as determining texture sampling locations, reading texture data, and filtering texture data.

[0047] In operation, each SM 310 sends the processed task to the work allocation crossbar switch 330 so that the processed task can be provided to another GPC 208 for further processing, or the processed task can be stored in the L2 cache (not shown), the parallel processing memory 204, or the system memory 104 via the crossbar switch unit 210. Furthermore, the pre-raster operation (preROP) unit 325 is configured to receive data from the SM 310, direct the data to one or more raster operation (ROP) units in the partitioning unit 215, perform color mixing optimization, organize pixel color data, and perform address translation.

[0048] It should be understood that the core architecture described herein is illustrative and can be varied and modified. Among other things, the GPC 208 may include any number of processing units, such as SM 310, texture units 315, or preROP units 325. Furthermore, as combined with the above... Figure 2The PPU 202 may include any number of GPCs 208, which are configured to be functionally similar to each other, such that execution behavior is independent of which GPC 208 receives a specific processing task. Furthermore, each GPC 208 operates independently of the other GPCs 208 in the PPU 202 to execute tasks of one or more applications. In view of the foregoing, those skilled in the art should understand that... Figures 1-3 The architecture described herein does not limit the scope of the various embodiments of this disclosure.

[0049] Please note that, as used herein, references to shared memory may include any one or more technically feasible memories, including but not limited to local memory shared by one or more SM 310s or memory accessible via memory interface 214, such as cache memory, parallel processing memory 204, or system memory 104. Also note that, as used herein, references to cache memory may include any one or more technically feasible memories, including but not limited to L1 cache, L1.5 cache, and L2 cache.

[0050] Start the security task in safe mode

[0051] Various embodiments include techniques for initiating secure tasks on processing units operating in secure mode. These secure tasks execute on compute engines and / or one or more other engines within the GPU. These secure tasks execute in a trusted execution environment. In the context of the GPU, secure tasks may include graphics instructions, compute instructions, copy instructions, video encoding and / or decoding instructions, image decompression instructions for Joint Photographic Experts Group (JPEG) format and / or other image formats, optical flow accelerator (OFA) instructions, etc. Using the disclosed techniques, a user-mode driver executing on the CPU submits new work to the GPU without relying on the intervention of secure microcode executing on a secure processor included within the GPU. Instead, using the disclosed techniques, the new work submitted by the user-mode driver is copied and decrypted by one or more copy engines, a GPU resource richer than a secure processor.

[0052] The replication engine has the capability to read encrypted data from insecure system memory, decrypt and authenticate the encrypted data, and then write the decrypted data to a computationally protected region of memory. Through a two-level push buffer structure, the replication engine channel is activated so that CPUs that cannot directly submit new instructions to the channel can perform these replication operations.

[0053] Each process executing on the main processor (e.g., CPU) can submit work to a secondary processor (e.g., a replication engine channel on the GPU). Each process is assigned a separate, dedicated job-starting replication engine channel, also referred to herein as a "job-starting channel." In some examples, each guest kernel starting work on the GPU is assigned a different job-starting channel. The push buffer data structure of the job-starting channel resides in a compute-protected region of memory. When a user-mode driver is initialized, the job-starting channel is initialized by secure microcode executed on the secure processor. The push buffer entries for the job-starting channel are predetermined and do not change after secure processor initialization. In some embodiments, each user-mode driver executing on the CPU is also assigned a startup completion indicator channel. The job-starting channel and the startup completion indicator channel are generated by the secure processor that executes the secure microcode during initialization. After these two channels are generated, they will operate without any further intervention from the secure processor unless an error condition is detected. If an error condition is detected, the secure microcode executed on the secure processor resolves the error, for example, by re-initializing the job-starting channel and the startup completion indicator channel.

[0054] The job initiation channel consists of a pair of push buffer entries. The first push buffer entry points to a predefined push buffer segment residing in the compute-protected region of memory. When executed by the initiation copy engine, the method in this push buffer segment performs a decrypted copy from a specific address in system memory to a fixed-size buffer of a predefined target buffer located in the compute-protected region of memory. The second push buffer entry points to this target buffer in the compute-protected region of memory, serving as the source for the next push buffer segment. Therefore, any data copied to the compute-protected region of memory by the copy operation triggered by the first push buffer segment becomes the content of the second push buffer segment and is subsequently used as the channel's method.

[0055] To initiate a job within the PPU, a user-mode driver executing on the CPU generates new push buffer segments for different target engine channels. The user-mode driver encrypts the new push buffer segments and stores them in system memory. The user-mode driver generates a series of replication engine methods to perform replication operations, moving the newly submitted push buffer segments to their corresponding target locations within the compute-protected region of memory. The user-mode driver encrypts and stores the sequence of replication engine methods. The user-mode driver stores the encrypted replication engine methods in a predefined system memory location, which is the source buffer of the corresponding job initiation channel replication instruction stored in the first push buffer segment. Furthermore, the user-mode driver encodes the methods in the buffers to update the placement pointer of the job initiation channel, thereby identifying the end of the second push buffer segment. Once the source buffer is filled, the user-mode driver notifies the scheduler of the pending jobs in the job initiation channel.

[0056] Upon receiving notification of pending jobs in a job start channel, the scheduler marks the job start channel as PENDING and subsequently schedules it. After loading the channel, methods from the first push buffer segment are executed by the replication engine. These methods cause the replication engine to copy the encrypted source buffer to a compute-protected region of memory using replication engine instructions. Because the target location of this copy operation is the push buffer segment pointed to by the second push buffer entry of the job start channel, the scheduler retrieves the copied data as the method of the job start channel and forwards the method to the replication engine for execution. These methods have instructions for the replication engine to copy all newly submitted push buffer data structures for other channels executed on different compute engines of the user-mode software application. Additionally or alternatively, push buffer data structures for other channels can be executed on any one or more engines within a trusted execution environment. In the case of a GPU, push buffer data instructions may include graphics instructions, compute instructions, additional copy instructions, video encoding and / or decoding instructions, image decompression instructions in JPEG format and / or other image formats, optical flow accelerator (OFA) instructions, etc. These methods also include instructions for the replication engine and / or scheduler to notify the channel that a new job has been submitted. Furthermore, these methods include instructions to update the placement pointer of the job startup channel. When these instructions are executed, the placement pointer of the job startup channel is incremented, making the job startup channel ready again to repeat the same steps upon receiving subsequent notifications. Therefore, by repeatedly copying the encrypted instructions from the source buffer from system memory to the compute-protected region of memory, and then sending the notification to the scheduler of the job startup channel, a user-mode driver can start a job on any replication engine channel assigned to a user-mode driver. Moreover, the security processor does not participate in the job startup process except for the initial setup of the job startup channel.

[0057] Figure 4 According to various embodiments Figure 2 A block diagram of the Secure Task Startup System 400 included in the PPU 202 is shown. As illustrated, the Secure Task Startup System 400 includes, but is not limited to, a notifier 410, a page isolation region 420, a hardware unit 430, and a compute-protected region 440. The page isolation region 420 is a page-isolated, but otherwise insecure, unprotected memory region. The page isolation region 420 includes, but is not limited to, a data A memory block 448. The data A memory block 448 resides in the user-mode address space. The hardware unit 430 includes, but is not limited to, a scheduler 432 and one or more copy engines 434. The compute-protected region 440 includes a set of data structures to support various operations of the Secure Task Startup System 400. The compute-protected region 440, without limitation, includes a pointer 422, a push buffer 424, a push buffer segment 426, a run list 442, a RAM FIFO context 444, a preemption buffer 446, and a data B memory block 448. The run list 442, RAM FIFO context 444, and preemption buffer 446 are initialized by the security engine and isolated from user-mode access. After the security processor is initialized, certain engines within the scheduler 432 and PPU 202 directly access the run list 442, RAM FIFO context 444, and preemption buffer 446. To initiate a secure task, the copy engine 434 copies an encrypted memory block, such as data A memory block 428, from insecure memory and fills the compute-protected region 440 with placement pointers 422, push buffers 424, and push buffer segments 426.

[0058] Notifier 410 receives notifications from various user channels, job start channels, and start-up completion indication channels, as further described herein. Notifier 410 forwards each notification to scheduler 432 to indicate that the channel that issued the notification has pending jobs available for scheduler 432 to schedule for execution. In some examples, notifier 410 includes memory-mapped registers included in scheduler 432. In such examples, a user process gains access to notifier 410 when the memory-mapped registers included in notifier 410 are mapped into the memory space of a user process via one or more page tables.

[0059] Each placement pointer 422 is mapped to a single user channel, job start channel, or start-up completion indication channel. For a specific channel, the corresponding placement pointer 422 indicates the end of a valid push buffer entry in the corresponding push buffer 424. For each channel, the scheduler 432 maintains a fetch pointer (not shown) that indicates the currently processed push buffer entry in the corresponding push buffer 424. After the current push buffer entry in the corresponding push buffer 424 is completed, the scheduler advances the fetch pointer to point to the next push buffer entry. When the fetch pointer of a specific channel equals the placement pointer 422 of that channel, the scheduler 432 determines that there is no additional work for that channel. The scheduler 432 stops processing the push buffer entries for the channel until the placement pointer 422, push buffer 424, and push buffer segment 426 of that channel are updated, and the notifyer 410 sends a notification for the channel to the scheduler 432.

[0060] Each push buffer 424 maintains a sequence of push buffer entries for a specific channel, where each push buffer entry points to a corresponding push buffer segment 426. Push buffer segment 426 includes methods, where each method includes instructions for performing a specific operation. When a method within a push buffer segment completes execution, the get pointer advances to the next push buffer entry in the push buffer. If the get pointer equals the place pointer, then the work on the push buffer is complete. Otherwise, the get pointer points to the next push buffer entry, which in turn points to the next push buffer segment for the channel.

[0061] Run list 442 is an ordered list of channels that the scheduler 432 reads to determine which channels to consider for execution. At any given time, run list 442 holds a subset of all channels that can be executed on the engine. Typically, run list 442 is read by the scheduler 432 but not written to. Run list 442 is generated by the safety engine when executing in safe mode, thereby validating run list 442.

[0062] The RAM FIFO context 444 is a per-channel memory structure used by the scheduler 432 and the engine to save and restore channel states to support channel switching. The RAM FIFO context 444 specifically includes a page directory library (PDB), method execution pointers, and host state. The page directory library is the address of a page table structure used to translate virtual address memory requests for a channel into physical addresses. The scheduler 432 does write to the RAM FIFO context 444, compared to the run list 442. However, a pointer to the RAM FIFO context 444 is included in the run list 442, thus locking the location of the RAM FIFO context 444. The RAM FIFO context 444 is a fixed data structure that is read and written by hardware. Although methods included in the push buffer segment 426 can modify values ​​in the RAM FIFO context 444, the trust boundary of the RAM FIFO context 444 is the same as that of the standard context used for isolation from user mode to kernel state. The RAM FIFO context 444 is generated by the security engine during execution in safe mode, thereby verifying the RAM FIFO context 444.

[0063] Preemption buffer 446 is a context buffer in memory where the engine saves queued unexecuted methods and other related states when a channel is preempted. A channel is preempted if it is switched off the engine before all work in the queue is completed. In this case, the engine saves the unexecuted methods and other related states of the channel to the corresponding preemption buffer 446. When the channel is rescheduled on the engine again, the engine first fetches and executes the saved methods before executing new methods in the method stream. Similar to RAM FIFO context 444, preemption buffer 446 has a fixed hardware write / read structure. Typically, preemption buffer 446 is only written to and read by the engine. Furthermore, preemption buffer 446 is located in a computationally protected area of ​​PP memory 204, thereby minimizing the risk of intentional or unintentional tampering or corruption.

[0064] The replication engine 434 performs replication operations for starting a job via a job initiation channel and a job completion indication channel. The replication engine 434 executes methods to initiate a new job associated with the job initiation channel and the job completion indication channel. The replication engine 434 reads encrypted data from the insecure system memory 104. The replication engine has the capability to read encrypted data from the insecure system memory, decrypt and authenticate the encrypted data, and then write the decrypted data to the computationally protected area of ​​the PP memory 204. Generally, any replication engine 434 can initiate a job for a channel executed on any engine. Furthermore, any replication engine 434 can execute a job initiation channel, where the job initiation channel can initiate a job for another channel executed on the same replication engine 434.

[0065] In addition, replication engine 434 performs replication operations for performing tasks through the user channel. Replication engine 434 executes push buffer segment methods that are decrypted, authenticated, and stored by replication engine 434.

[0066] Data A memory block 428 represents a storage area within the insecure page isolation region 420. Correspondingly, data B memory block 448 represents a storage area within the secure computing protected region 440. When data is transferred between data A memory block 428 and data B memory block 448, the security task initiation system 400 performs certain tasks to maintain data security. Specifically, when the replication engine 434 performs a replication operation associated with the working initiation channel, the replication engine 434 reads encrypted data from the insecure page isolation region 420. A user-mode driver executing on the CPU 102 generates encrypted data and generates an authentication tag verified by the replication engine 434. The replication engine 434 decrypts the encrypted data and verifies the data using the authentication tag. After the data block is committed to memory, the replication engine 434 authenticates the data as it progresses towards the end of the replication operation. As a result, the replication engine 434 is able to authenticate and replicate data blocks of any size. The methods within the data block are authenticated before execution. As a result, these methods are determined to be trustworthy before execution. If the data block is successfully authenticated, the data block is written in decrypted form to the computationally protected area 440 in the PP memory 204.

[0067] The replication engine 434 copies data blocks to the compute-protected region 440 in the PP memory 204. However, if authentication of the copied data block fails, the replication engine 434 prevents the execution of a second subsequently copied data block. More specifically, the replication engine 434 does not prevent data from being written to the compute-protected region 440. Instead, the replication engine 434 performs the first copy operation of the data block to the compute-protected region 440. During the first copy operation, the compute engine 434 reads and decrypts the user-provided method. The replication engine 434 performs the authentication process when the first copy operation of the data block is completed. At this time, the write operation associated with the first copy operation has been forwarded to the compute-protected region 440 by the replication engine 434. If the authentication process passes, the replication engine 434 initiates the second copy operation of the data block. The second copy operation moves the user data and initiates the user work contained in the data block. However, if the authentication process fails, the replication engine 434 does not initiate the second copy operation of the data block. As a result, the failure of the authentication process of the first copy operation does not lead to the corruption of the user data and the user method therein.

[0068] This authentication technique prevents source address and size attacks. Furthermore, the replication engine 434 authenticates the target address of the method in the data blocks stored in the computationally protected region 440 of the PP memory 204 and the associated page tables. This authentication technique prevents target address attacks. In some embodiments, when the replication engine 434 decrypts and copies encrypted data, the replication engine 434 may incrementally check the authentication tag. In such embodiments, the replication engine 434 may not be able to determine whether the authentication tag matches until the decryption and copying operation is complete. Therefore, the replication engine 434 does not prevent data from being copied to the computationally protected region 440 of the PP memory 204. Conversely, if the replication engine 434's authentication fails to verify the authentication tag, the replication engine 434 does not indicate the completion of the copying operation to the user-mode driver executing on the CPU 102.

[0069] It should be understood that the system shown herein is illustrative and variations and modifications are possible. As described herein, a user-mode driver executing on CPU 102 generates new jobs for PPU 202 and submits the new jobs through the job initiation channel. However, new jobs for PPU 202 can be generated by any one or more technically feasible processing units. Similarly, new jobs generated by CPU 102 can be executed by any one or more technically feasible processing units.

[0070] Figure 5 It is stored according to various embodiments Figures 1-2 A block diagram of the data structures in the unprotected memory 500 and compute-protected region 440 of the PP memory 204. The unprotected memory 500 may be included in the system memory 104, the PP memory 204, and / or another memory system within the GPU. The compute-protected region 440 is included in the PP memory 204. In some examples, the PP memory 204 may be subdivided into two regions, a first region including the unprotected memory 500 and a second region including the compute-protected region 440. As shown, the unprotected memory 500 includes, but is not limited to, X buffer 510, A buffer 520, and B buffer 530. The compute-protected region 440 includes, but is not limited to, push buffer 502, a first push buffer segment 504, and a second push buffer segment, also referred to herein as X' buffer 512. The compute-protected region 440 further includes, but is not limited to, A' buffer 522 and B' buffer 532.

[0071] The process of starting a new job in secure mode involves two channels running on a replication engine capable of performing encryption and decryption. These channels include a job initiation channel and a start-up completion indication channel. Both channels are generated by a security processor that executes secure microcode during initialization. After these channels are generated, they will run without any further intervention from the security processor unless an error condition is detected. If an error condition is detected, the secure microcode executing on the security processor resolves the error, for example, by reinitializing the job initiation channel and the start-up completion indication channel.

[0072] When a user-mode software application executes on CPU 102, it periodically submits new work to PPU 202. In doing so, the user-mode software application generates a push buffer segment containing methods to be executed by the computational engine in PPU 202. A user-mode driver associated with the user-mode software application and executing on CPU 102 encrypts the push buffer segment and stores the encrypted push buffer segment in insecure, unprotected memory 500. As shown, the encrypted push buffer segment includes buffer A 520 and buffer B 530. Furthermore, the user-mode driver generates, encodes, and stores the push buffer segment at a defined location in unprotected memory 500. This encrypted push buffer segment includes copying buffer A 520 and buffer B 530 to the computationally protected region 440 of PP memory 204 and then notifying the scheduler. As shown, this encrypted push buffer segment includes buffer X 510. The user-mode driver notifies the scheduler 432 of pending work in the job initiation channel.

[0073] In response, PPU 202 accesses the first entry in push buffer 502. This first entry, initialized by the security processor, references a first push buffer segment 504, also initialized by the security processor. The first push buffer segment 504 includes a method for copying an X buffer 510 located at a defined location in unprotected memory 500 to an X' buffer 512 located at a defined location in compute-protected region 440. The copy engine 434 executes the methods included in the first push buffer segment 504 to read, decrypt, and authenticate the methods included in X buffer 510, and stores the decrypted methods into X' buffer 512.

[0074] PPU 202 accesses the second entry in push buffer 502. This second entry references X' buffer 512. Replication engine 434 executes the method included in X' buffer 512. When executing the first method, replication engine 434 reads, decrypts, and authenticates the method included in A buffer 520, and stores the decrypted method in A' buffer 522. Similarly, when executing the second method, replication engine 434 reads, decrypts, and authenticates the method included in B buffer 530, and stores the decrypted method in B' buffer 532. When executing the third method, replication engine 434 notifies scheduler 432 of the pending jobs included in A' buffer 522 and B' buffer 532. Scheduler 432 forwards the jobs included in A' buffer 522 and B' buffer 532 to the target compute engine for execution. More details about the job initiation channel and initiation completion indication channel will now be described.

[0075] The user-mode driver executing on CPU 102 generates a series of direct memory access (DMA) operations that can be executed by the copy engine to copy and decrypt the user push buffer structure from insecure unprotected memory 500 to the compute-protected region 440 of PP memory 204. The user push buffer structure includes push buffer entries, push buffer segments, and placement pointers for various user-mode channels.

[0076] The method for DMA operations generated by the user-mode driver is stored in encrypted form in a set of staging buffers, such as X buffer 510, in unprotected memory 500. System memory may include any technically feasible number of such staging buffers, also referred to herein as "memory buffers". Each staging buffer is located at a different, predefined, fixed location in system memory. Furthermore, the size of each staging buffer is predefined and fixed. In some embodiments, DMA operations for copying a set of user push buffer structures cannot fit into a single staging buffer, for example, when a user process submits hundreds of individual push buffer segments. In such embodiments, DMA operations may be partitioned and stored in multiple staging buffers. Additionally or alternatively, DMA operations may be performed in multiple steps or stages.

[0077] The job startup channel reads the encrypted push buffer data structures of the user-mode channel from the insecure, unprotected memory 500. The job startup channel decrypts these push buffer data structures and stores them in the compute-protected region 440 of the PP memory 204. Subsequently, the scheduler 432 retrieves these push buffer data structures from the compute-protected region and forwards them to the target compute engine for execution.

[0078] In a specific example, the job initiation channel push buffer 424 can have 8 entries. After the security processor initializes the job initiation channel, the place pointer 422 is set to 2, while the get pointer is set to 0. The difference between the place pointer 422 and the get pointer is 2, indicating that the job initiation channel push buffer 424 includes two active push buffer entries. Upon receiving a notification of a new job, the scheduler 432 reads and executes the first two push buffer entries in the job initiation channel, such as entry 0 and entry 1.

[0079] Even-numbered startup channel push buffer entries (numbered 0, 2, 4, 6) point to corresponding push buffer segments that have methods for performing DMA operations to copy hierarchical buffers (e.g., X buffer 510) from a predefined location in unprotected memory 500 to a predefined location in compute-protected region 440. These push buffer segments are referred to herein as "startup execution push buffer segments". The startup execution push buffer segments pointed to by push buffer entries 0, 2, 4, and 6 copy hierarchical buffers 0, 1, 2, and 3, respectively. Each hierarchical buffer has a predefined fixed size. As a result, a particular hierarchical buffer may be only partially filled with valid data, while the remainder of the hierarchical buffer contains invalid data. In any case, the user-mode driver executing on CPU 102 encrypts the entire hierarchical buffer. Similarly, the copy engine reads the entire hierarchical buffer from unprotected memory 500, decrypts and stores the hierarchical buffer, and then stores the entire hierarchical buffer in compute-protected region 440 of PP memory 204. Therefore, the last valid method in the hierarchical buffer is followed by an "end pushbuffer segmentcontrol" method to indicate the end of the pushbuffer segment.

[0080] The start execution push buffer segment releases a non-waiting idle scheduler semaphore release, which updates the placement pointer 422 of the start completion indicator channel. Placement pointer 422 is set to ((1+j)&0x3), where j = the number of push buffer entries / 2. The start execution push buffer segment releases a non-waiting idle scheduler semaphore release, which notifies the start completion indicator channel of pending work. The start execution push buffer segment releases a waiting idle DMA semaphore release, which causes the scheduler to wait for the replication engine to complete the replication operation of the hierarchical buffer before continuing. As part of the replication operation, the replication engine authenticates the replication of methods in the hierarchical buffer. If replication authentication fails at this point, the worker start channel stops execution. Because only the state of the worker start channel is corrupted, the system can determine that only the worker start channel needs to be reset, since no user channels are corrupted.

[0081] Odd-numbered job start channel push buffer entries (numbered 1, 3, 5, 7) point to the respective push buffer segments corresponding to their push buffer entry numbers. These odd-numbered job start channel push buffer entries include a synchronization wait indicator. The wait indicator prevents the execution of the odd-numbered push buffer segments until the corresponding even-numbered push buffer segment completes the hierarchical buffer copy operation, as indicated by waiting for the completion of the idle DMA semaphore. At this time, the associated odd-numbered push buffer segments include a decrypted version of the copy engine method generated by the user-mode driver and stored in the encrypted hierarchical buffer. These copy engine methods include instructions for copying the encrypted user push buffer segments in decrypted form from unprotected memory 500 to the compute-protected region 440 of PP memory 204. When the scheduler 432 issues a retrieval for the decrypted push buffer segments, the scheduler retrieves the decrypted version of the method generated by the user-mode driver. These methods generate a copy operation to copy the encrypted user push buffer, push buffer segments, and placement pointer in decrypted form from unprotected memory 500 to the compute-protected region 440 of PP memory 204. These methods then notify scheduler 432 of pending jobs for the relevant user channels. In some embodiments, a single job initiation channel can initiate new jobs for multiple user channels.

[0082] In some embodiments, the startup execution push buffer segment does not include a host-level semaphore acquisition method to avoid premature scheduling of the startup completion indication channel. In such an embodiment, if a semaphore acquisition method is required in the working startup channel, the startup completion indication channel places pointer 422 updated and notifies that the method can be moved from the first (even-numbered) startup execution push buffer segment and placed in the second (odd-numbered) startup execution push buffer segment after the semaphore acquisition operation.

[0083] The startup completion indication channel includes a separate push buffer 424 from the push buffer 424 used for the working startup channel. The startup completion indication channel push buffer 424 may contain a different number of entries than the working startup channel push buffer 424. In a specific example, the working startup channel push buffer 424 may contain 8 entries, and the startup completion indication channel push buffer 424 may contain 4 entries. After initialization, both the place pointer 422 and the get pointer for the startup completion indication channel push buffer 424 are set to 0.

[0084] Each startup completion indicator channel push buffer entry points to a separate corresponding push buffer segment. Each push buffer segment "j" performs a similar operation. Push buffer segment "j" includes a constant copy and flush method that updates the working startup channel placement pointer 422 to ((4+j*2)&0x7). This method flushes data from the previous push buffer segment and prepares the working startup channel for the next working startup operation. Push buffer segment "j" also includes a copy operation to write an encrypted version of push buffer segment "j" to a predefined and fixed location in unprotected memory 500. This encrypted version is encrypted and has an authentication tag. Therefore, the encrypted version is referred to as the authenticated encryption of push buffer segment "j". This operation indicates to the user-mode driver executing on CPU 102 that the hierarchical buffer corresponding to push buffer segment "j" has been consumed.

[0085] In summary, the user-mode driver executing on CPU 102 sequentially submits new work to PPU 202 using hierarchical buffers. To initiate a new job, the user-mode driver updates the next sequential hierarchical buffer using relevant methods. While PPU 202 is processing the current hierarchical buffer, the user-mode driver can update the next sequential hierarchical buffer. The user-mode driver polls values ​​at predefined and fixed locations in unprotected memory 500 until a value indicates that PPU 202 has consumed the current hierarchical buffer. When the user-mode driver determines that PPU 202 has consumed the current hierarchical buffer, it notifies scheduler 432 that the next hierarchical buffer is ready for processing.

[0086] If the user-mode driver prematurely notifies the scheduler 432 or fails to properly update the next hierarchical buffer, the startup execution push buffer segment indication authentication check for the replicated hierarchical buffer fails. This situation results in corruption of the working startup channel, but not of any user channels or user data stored in the compute-protected area 440 of the PP memory 204. Therefore, the security processor is able to recover from the error by resetting the working startup channel without resetting any user process channels.

[0087] Figure 6 It is an accelerator (e.g., according to various embodiments) for operation in safe mode. Figure 2 The flowchart illustrates the method steps for initiating a security task on the PPU 202. Alternatively or concurrently, the method steps may be executed by one or more alternative accelerators, including but not limited to CPU, GPU, IPU, NPU, TPU, NNP, DPU, VPU, ASIC, FPGA, etc., in any combination. Despite the combination... Figures 1-5The system describes the method steps, but those skilled in the art will understand that any system configured to perform these method steps in any order is within the scope of this disclosure.

[0088] As shown in the figure, method 600 begins at step 602, where a user-mode driver executing on CPU 102 generates a new push buffer segment for the target engine channel on PPU 202. The new push buffer segment represents work submitted by the user-mode driver that will be executed by PPU 202. The push buffer segment includes one or more command streams formatted in data structures located in unprotected memory 500, accessible to both CPU 102 and PPU 202.

[0089] In step 604, the user-mode driver encrypts the new push buffer segment and stores it in unprotected memory 500. Because the push buffer segment is encrypted, other processes executing in CPU 102 and / or PPU 202 cannot decipher the method contained in the push buffer segment. In some examples, the encrypted push buffer segment is signed to support authentication of the push buffer segment, thereby reducing or eliminating the possibility of corruption of the method included in the push buffer segment.

[0090] In step 606, the user-mode driver generates a sequence of replication engine methods to perform a replication operation to move the newly submitted push buffer segment to the corresponding target location in the compute-protected region 440 of the PP memory 204. In step 608, the user-mode driver encrypts the sequence of replication engine methods and stores it in unprotected memory 500. The user-mode driver stores the encrypted replication engine methods in a predefined system memory location, which is the source buffer of the corresponding job start channel replication instruction stored in the first push buffer segment in the job start channel. Furthermore, the user-mode driver encodes the methods in the buffer to update the job start channel placement pointer, thereby identifying the end of the second push buffer segment. Because these methods are encrypted, other processes executing in CPU 102 and / or PPU 202 cannot decrypt them.

[0091] In step 610, the user-mode driver sends a notification to the notifier 410. The notifier 410 then initiates the pending work notification work channel, which was generated in steps 602 and 606 and encrypted and stored in steps 604 and 608, respectively.

[0092] In step 612, the replication engine 434 copies the encrypted replication engine method to a buffer in the unprotected memory 500 and then to the compute-protected region 440 in the PP memory 204. More specifically, the replication engine 434 accesses a first entry in the push buffer 502. This first entry, initialized by the security processor, references a first push buffer segment 504, also initialized by the security processor. The first push buffer segment 504 includes a method for copying the encrypted replication engine method, stored in step 608 at a defined location in the unprotected memory 500, to a corresponding defined location in the compute-protected region 440. The replication engine 434 executes the method included in the first push buffer segment 504 to read, decrypt, and authenticate the method and stores the decrypted method in the compute-protected region 440.

[0093] In step 614, replication engine 434 executes a decryption replication engine method stored in the compute-protected region 440 of PP memory 204 to generate more pending work for one or more user channels. More specifically, replication engine 434 accesses a second entry in push buffer 502. This second entry references a decryption method stored in compute-protected region 440. Replication engine 434 executes the decryption method. When executing the method, replication engine 434 may read, decrypt, and authenticate methods included in one or more encrypted buffers in unprotected memory 500, and store the decrypted methods in the corresponding buffers in compute-protected region 440 of PP memory 204. Replication engine 434 further executes a method to notify scheduler 432 of the pending methods included in the decrypted buffers.

[0094] In step 616, scheduler 432 notifies the relevant target engine channels of the pending work included in the decryption buffer. Scheduler 432 forwards the methods included in the decryption buffer to the target computing engines for execution. One or more computing engines, such as replication engine 434, then execute the methods included in the decryption buffer.

[0095] Then method 600 terminates. Alternatively, method 600 proceeds to step 602 to initiate another security task. Thus, by repeatedly copying the encrypted instructions in the source buffer from the unprotected memory 500 to the computationally protected region 440 of the PP memory 204, and then sending a notification for a job initiation channel to the scheduler 432, the user-mode driver can initiate a job on any copy engine channel assigned to the user-mode driver.

[0096] In summary, various embodiments include techniques for initiating secure tasks on processing units operating in secure mode. These secure tasks are executed on compute engines and / or one or more other engines within the GPU. These secure tasks are executed in a trusted execution environment. In the context of the GPU, secure tasks may include graphics instructions, compute instructions, copy instructions, video encoding and / or decoding instructions, image decompression instructions for Joint Photographic Experts Group (JPEG) format and / or other image formats, optical flow accelerator (OFA) instructions, etc. Using the disclosed techniques, a user-mode driver executing on the CPU submits new work to the GPU without relying on the intervention of secure microcode executing on a secure processor included in the GPU. Instead, using the disclosed techniques, the new work submitted by the user-mode driver is copied and decrypted by one or more copy engines, a GPU resource richer than a secure processor.

[0097] The replication engine has the capability to read encrypted data from insecure system memory, decrypt and authenticate the encrypted data, and then write the decrypted data to a computationally protected region of memory. Through a two-level push buffer structure, replication engine channels are activated to perform these replication operations for CPUs that cannot directly submit new instructions to the channels.

[0098] Each user-mode driver executing on the CPU is allocated a separate, dedicated worker startup replication engine channel, also referred to herein as a "worker startup channel." The push buffer data structure of the worker startup channel resides in a compute-protected region of memory. When the user-mode driver is initialized, the worker startup channel is initialized by secure microcode executing on the secure processor. The push buffer entries for the worker startup channel are predetermined and do not change after the secure processor initialization.

[0099] The job initiation channel consists of a pair of push buffer entries. The first push buffer entry points to a predefined push buffer segment located in the compute-protected region of memory. When executed by the initiation copy engine, the method in this push buffer segment performs a decrypted copy from a specific address in system memory to a fixed-size buffer of a predefined target buffer located in the compute-protected region of memory. The second push buffer entry points to this target buffer in the compute-protected region of memory, serving as the source for the next push buffer segment. Therefore, any data copied to the compute-protected region of memory by the copy operation triggered by the first push buffer segment becomes the content of the second push buffer segment and is subsequently used as the channel's method.

[0100] To initiate work within the PPU 202, a user-mode driver executing on the CPU generates new push buffer segments for different target engines. The user-mode driver encrypts the new push buffer segment and stores it in system memory. The user-mode driver generates a sequence of replication engine methods to perform replication operations, moving the newly submitted push buffer segment to its corresponding target location in a compute-protected region of memory. The user-mode driver encrypts and stores the sequence of replication engine methods. In some examples, the encrypted push buffer segments are signed to support authentication, thereby reducing or eliminating corruption of the methods included in the push buffer segments. The user-mode driver stores the encrypted replication engine methods in a predefined system memory location, which is the source buffer of the corresponding job initiation channel replication instruction stored in the first push buffer segment. Furthermore, the user-mode driver encodes the methods in the buffer to update the job initiation channel's placement pointer, thereby identifying the end of the second push buffer segment. Once the source buffer is filled, the user-mode driver notifies the scheduler of pending jobs in the job initiation channel.

[0101] Upon receiving notification of pending work in a job initiation channel, the scheduler marks the job initiation channel as pending and subsequently schedules it. After loading the channel, methods from the first push buffer segment are executed by the replication engine. These methods cause the replication engine to copy the encrypted source buffer to a compute-protected region of memory using replication engine instructions. Because the target location of this copy operation is the push buffer segment pointed to by the second push buffer entry of the job initiation channel, the scheduler retrieves the copied data as the methods of the job initiation channel and forwards the methods to the replication engine for execution. These methods have instructions for the replication engine to copy all newly submitted push buffer data structures that are intended for other channels executed on different compute engines and / or other engines of user-mode software applications. The methods also include instructions for the replication engine and / or scheduler to notify the channel that a new work has been submitted. Furthermore, these methods include instructions to update the placement pointer of the job initiation channel. When these instructions are executed, the placement pointer of the job initiation channel is incremented, making the job initiation channel ready again to repeat the same steps upon receiving subsequent notifications. Therefore, by repeatedly copying the encrypted instructions from the source buffer from system memory to a computationally protected region of memory, and then sending a notification to the scheduler of the job startup channel, a user-mode driver can start a job on any replication engine channel assigned to a user-mode driver. Furthermore, the security processor does not participate in the job startup process except for the initial setup of the job startup channel.

[0102] At least one technical advantage of the disclosed technology over existing technologies lies in the fact that, using the disclosed technology, the security processor does not directly participate in the startup process, except for initializing the job startup channel. Instead, job startup is performed by a replication engine, a more abundant resource than the security processor. Typically, the replication engine is designed to saturate the interface bandwidth while simultaneously decrypting and authenticating data. Unlike the security processor, the replication engine is specifically designed to perform fast, secure data movement. Therefore, compared to previous methods, the startup latency of new jobs is reduced, and performance is improved. Another advantage of the disclosed technology is that the replication engine copies encrypted, decrypted, and authenticated data from insecure system memory and stores the decrypted data in secure memory. Therefore, the replication engine can start new jobs in secure mode without compromising security. These advantages represent one or more technical improvements over existing methods.

[0103] Any and all combinations of any claim element recited in any way in any claim and / or any element described in this application fall within the scope of this disclosure and protection.

[0104] Various embodiments have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

[0105] Aspects of this embodiment may be embodied as a system, method, or computer program product. Therefore, aspects of this disclosure may take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all collectively referred to herein as a "module" or "system." Furthermore, aspects of this disclosure may take the form of a computer program product embodied in one or more computer-readable media containing computer-readable program code.

[0106] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium includes, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples (not an exhaustive list) of computer-readable storage media may include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the context of this document, a computer-readable storage medium can be any tangible medium that may include or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0107] Aspects of this disclosure have been described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such processors can be, but are not limited to, general-purpose processors, special-purpose processors, application-specific processors, or field-programmable gate arrays.

[0108] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code comprising one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative embodiments, the functions indicated in the blocks may not occur in the order shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or a combination of dedicated hardware and computer instructions.

[0109] While the foregoing description is directed to embodiments of this disclosure, other and further embodiments of this disclosure may be designed without departing from its essential scope, as defined by the appended claims.

Claims

1. A computer-implemented method for launching a secure task on a processing unit, the method comprising: reading an encrypted copy task from an unsecure memory; decrypting the encrypted copy task to generate a decrypted copy task; executing the decrypted copy task to copy an encrypted secure task from the unsecure memory to a secure memory; decrypting the encrypted secure task to generate a decrypted secure task; and scheduling the decrypted secure task for execution.

2. The computer-implemented method of claim 1, wherein at least one of the decrypted copy task or the decrypted secure task is executed in a secure mode.

3. The computer-implemented method of claim 1, further comprising: authenticating the decrypted copy task; and determining that the authentication is successful prior to executing the decrypted copy task.

4. The computer-implemented method of claim 1, further comprising: authenticating the decrypted secure task; and determining that the authentication is successful prior to scheduling the decrypted secure task for execution.

5. The computer-implemented method of claim 1, wherein reading the encrypted copy task from the unsecure memory comprises: accessing a first push buffer entry comprising a first pointer; accessing a first method stored in a memory location in the secure memory and associated with the first pointer; and executing the first method to copy a first memory buffer comprising the encrypted copy task to a second memory buffer.

6. The computer-implemented method of claim 5, wherein the first memory buffer resides in a first fixed location in the unsecure memory and the second memory buffer resides in a second fixed location in the secure memory.

7. The computer-implemented method of claim 5, wherein executing the decrypted copy task comprises: accessing a second push buffer entry comprising a second pointer associated with the second memory buffer; accessing a second copy task stored in a memory location in the secure memory and associated with the second memory buffer; and executing the second copy task to copy a third memory buffer comprising the encrypted secure task to a fourth memory buffer.

8. The computer-implemented method of claim 7, wherein the third memory buffer resides in a first fixed location in the unsecure memory and the fourth memory buffer resides in a second fixed location in the secure memory. prior to reading the encrypted copy task from the unsecure memory, receiving a notification indicating that the encrypted copy task is stored in the unsecure memory. prior to scheduling the decrypted secure task for execution, receiving a notification indicating that the decrypted secure task is stored in the secure memory.

11. The computer-implemented method of claim 1, further comprising: reading a second encrypted copy task from the unsecure memory; decrypting the second encrypted copy task to generate a second decrypted copy task; 9. The computer-implemented method of claim 1, further comprising: ​ 10. The computer-implemented method of claim 1, further comprising: ​ ​ ​ ​ authenticate the second decrypted copy task; determine that the authentication fails; and prevent execution of the second decrypted copy task.

12. The computer-implemented method of claim 1, further comprising: preventing execution of a decrypted copy task, waiting for a notification of a second encrypted secure task; receiving the notification of the second encrypted secure task; executing the decrypted copy task to cause the second encrypted secure task to be copied from the unsecure memory to the secure memory; decrypting the second encrypted secure task to generate a second decrypted secure task; and scheduling the second decrypted secure task for execution.

13. One or more non-transitory computer-readable media storing program instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of: reading an encrypted copy task from unsecure memory; decrypting the encrypted copy task to generate a decrypted copy task; executing the decrypted copy task to cause an encrypted secure task to be copied from the unsecure memory to secure memory; decrypting the encrypted secure task to generate a decrypted secure task; and scheduling the decrypted secure task for execution.

14. The one or more non-transitory computer-readable media of claim 13, further comprising: authenticating the decrypted copy task; and determining that the authentication succeeds prior to executing the decrypted copy task.

15. The one or more non-transitory computer-readable media of claim 13, further comprising: authenticating the decrypted secure task; and determining that the authentication succeeds prior to scheduling the decrypted secure task for execution.

16. The one or more non-transitory computer-readable media of claim 13, wherein reading the encrypted copy task from the unsecure memory comprises: accessing a first push buffer entry comprising a first pointer; accessing a first method stored in a memory location in the secure memory and associated with the first pointer; and executing the first method to copy a first memory buffer comprising the encrypted copy task to a second memory buffer.

17. The one or more non-transitory computer-readable media of claim 16, wherein the first memory buffer resides at a first fixed location in the unsecure memory and the second memory buffer resides at a second fixed location in the secure memory.

18. The one or more non-transitory computer-readable media of claim 16, wherein executing the decrypted copy task comprises: accessing a second push buffer entry comprising a second pointer associated with the second memory buffer; accessing a second copy task stored in a memory location in the secure memory and associated with the second memory buffer; and executing the second copy task to copy a third memory buffer comprising the encrypted secure task to a fourth memory buffer.

19. The one or more non-transitory computer-readable media of claim 18, wherein the third memory buffer resides in a first fixed location in the unsecure memory and the fourth memory buffer resides in a second fixed location in the secure memory.

20. A system comprising: a memory that stores instructions; and a processor coupled to the memory, the processor, upon executing the instructions: reads an encrypted copy task from unsecure memory; decrypts the encrypted copy task to generate a decrypted copy task; executes the decrypted copy task causing an encrypted secure task to be copied from the unsecure memory to secure memory; decrypts the encrypted secure task to generate a decrypted secure task; and schedules the decrypted secure task for execution. ​

Images