Method and apparatus for performing gpu tasks in confidential computing architecture

Abstract

The embodiment of the present specification provides a method and device for executing GPU tasks in a confidential computing architecture. The confidential computing architecture includes a secure world, a domain world, an unsecure world, and a root world. The corresponding method includes: the GPU software in the unsecure world configuring a stake data structure in the unsecure world memory according to the task code and the cache description of the GPU task, wherein the stake data structure includes the cache area allocated according to the cache description and the metadata indicating each cache area. Then, the root monitor in the root world configures a real data structure corresponding to the stake data structure in the domain section of the memory, and stores the confidential data to be processed in the real data structure. The root monitor updates the GPT table, so that according to the updated GPT table, the target section storing the metadata and the task code is accessible to the GPU and has the domain world permission for other objects. In addition, the root monitor modifies the target mapping relationship, so that the GPU executes the above-mentioned GPU task by using the target section and the real data structure.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to a confidential computing framework, and in particular, to a method and apparatus for executing GPU tasks in a confidential computing framework. BACKGROUND

[0002] With the development of computing technology in various industries, and the increase of cloud and terminal users, people store a large amount of data in various computer devices. With the development of the industry, people's concern for the security of devices and data is also increasing. In order to ensure the security of devices and data, various architecture manufacturers have also proposed their own solutions, such as ARM proposing TrustZone, AMD proposing SEV, Intel proposing SGX, etc. These solutions provide a secure trusted execution environment for users to securely store and process data, so as to protect it from untrusted kernels and traditional applications. Taking Arm TrustZone as an example, it regards the running environment of traditional kernels and applications as an unsafe world, and creates an isolated secure world, and defines a secure layer with the highest authority for world switching. The unsafe world cannot directly access the secure world and needs to pass through the firmware verification of the secure layer to access specific resources.

[0003] Although the ARM confidential computing architecture effectively ensures the security of users' data, it still has some deficiencies, one of which is the inability to provide support for confidential computing on accelerators such as GPUs. This makes it very challenging to use GPUs for task acceleration in this technical framework, and there is a need for improvement. SUMMARY

[0004] One or more embodiments of the present specification describe a method and apparatus for executing GPU tasks in a confidential computing architecture, which can provide a confidential computing environment for the execution of GPU tasks based on the hardware characteristics of the existing confidential computing architecture, and support GPU confidential computing.

[0005] According to a first aspect, a method for executing GPU tasks in a confidential computing architecture is provided, the confidential computing architecture comprising a secure world, a domain world, an unsafe world, and a root world; the method comprising:

[0006] The GPU software of the unsafe world configures a stake data structure of a first stake task in the unsafe world segment of the memory according to the task code and the cache description of the first GPU task provided by the user, the stake data structure comprising a plurality of cache areas allocated according to the cache description, and metadata indicating each cache area;

[0007] The root monitor in the root world configures a real data structure corresponding to the stub data structure in a segment of the memory corresponding to the first domain, and stores confidential data to be processed in the real data structure;

[0008] The root monitor updates a granularity protection table (GPT) so that according to the updated GPT table, a target segment storing the metadata and the task code of the first GPU task is accessible to the GPU and has the authority of the domain world to other objects;

[0009] The root monitor modifies a target mapping relationship so that the GPU executes the first GPU task using the target segment and the real data structure.

[0010] According to a second aspect, a root monitor in a confidential computing architecture is provided, the confidential computing architecture including a secure world, a domain world, an unsecure world and a root world; the root monitor is located in the root world and includes a shadow task component and a GPU environment protection component, wherein:

[0011] The shadow task component is configured to, in response to the GPU software of the unsecure world configuring a stub data structure of a first stub task in an unsecure world segment of the memory, configure a real data structure corresponding to the stub data structure in a segment of the memory corresponding to the first domain, and store confidential data to be processed in the real data structure, wherein the stub data structure includes a plurality of buffer areas allocated according to a user-provided buffer description and metadata indicating each buffer area;

[0012] The GPU environment protection component is configured to update a granularity protection table (GPT) so that according to the updated GPT table, a target segment storing the metadata and the task code of the first GPU task provided by the user is accessible to the GPU and has the authority of the domain world to other objects;

[0013] The shadow task component is further configured to modify a target mapping relationship so that the GPU executes the first GPU task using the target segment and the real data structure.

[0014] According to a third aspect, a computing device is provided, including a memory and a plurality of processors, the computing device forming a confidential computing architecture, the confidential computing architecture including a secure world, a domain world, an unsecure world and a root world; the root world includes the root monitor as described in the second aspect.

[0015] In the scheme provided by the embodiments of the present specification, GPU confidential computing is implemented compatible with Arm confidential computing architecture CCA through a shadow task mechanism. According to the shadow task mechanism, a stub task not containing real data is created by GPU software in a non-secure world, and the stub task is scheduled and managed as a regular process. After the stub task is submitted, a real GPU task containing real data is created by a root monitor, and a protected execution environment is provided for the real GPU task. Then, the root monitor replaces the stub task with the real GPU task, so that the GPU hardware executes the real GPU task in the protected execution environment. In this way, GPU confidential computing is implemented in Arm confidential computing architecture CCA. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0017] Figure 1 A schematic diagram of Arm confidential computing architecture is shown.

[0018] Figure 2 Access permission control of each world to physical address space in confidential computing architecture is shown.

[0019] Figure 3 A schematic diagram of running GPU tasks in confidential computing architecture according to an embodiment is shown.

[0020] Figure 4 A method of executing GPU tasks in confidential computing architecture according to an embodiment is shown.

[0021] Figure 5 A schematic diagram of data structures in each stage under shadow task mechanism is shown.

[0022] Figure 6 A GPT table maintained by a root monitor in an example scenario is shown.

[0023] Figure 7 A secondary layer representation according to an embodiment is shown. DETAILED DESCRIPTION

[0024] The scheme provided by the present specification will be described below in conjunction with the drawings.

[0025] To ensure the security of data, ARM provides TrustZone technology. In this technology, the running environment of traditional kernel and application program is regarded as a non-secure world (Normal World), and a separate secure world (Secure World) is created outside the non-secure world, and a secure layer with the highest privilege is defined for world switching.

[0026] Specifically, in the Armv8-A architecture, the CPU core divides the exception into four levels, EL0 to EL3, based on the privilege division, wherein EL0 represents the application level, EL1 is used for the kernel, EL2 represents the hypervisor, and EL3 represents the secure layer monitor. The four levels can also be used to represent the privilege level of the running environment. In the TrustZone technology, the CPU security state is divided into a non-secure (Normal) state and a secure state. EL0 and EL1 can run in either state, for example, an untrusted operating system OS (untrusted OS) can be executed in EL1 of the non-secure world, and a trusted OS can be executed in EL1 of the secure world. EL2 can be used in the secure state. EL3, i.e., the secure layer monitor, always exists in the secure world and is used for switching the secure state.

[0027] Under this architecture, the non-secure world cannot directly access the secure world and needs to pass the verification of the secure layer monitor to access specific resources. Sensitive or confidential data, and high-privilege software applications run in the secure world, thereby providing a trusted execution environment TEE for these confidential data.

[0028] On the basis of the above TrustZone infrastructure, ARM recently released an improved Arm Confidential Compute Architecture (CCA). The Arm Confidential Compute Architecture is part of the Armv9-A architecture, which introduces a realm management extension based on the original TrustZone architecture. The extension introduces a realm world and a root world in addition to the non-secure world and the secure world that already exist in the TrustZone technology. To support the isolation of different worlds, the CCA architecture provides a realm management extension (RME) component at the hardware layer to extend the isolation mode.

[0029] Figure 1 A schematic diagram of the Arm Confidential Compute Architecture is shown. As Figure 1As shown, in Arm confidential computing architecture CCA, the runtime environment is divided into four worlds: secure world, non-secure world (Normal), enclave world and root world. The root world runs the root world monitor with the highest privilege, responsible for the isolation and communication between the worlds. The enclave world is used to provide a protected virtual machine confidential computing environment named confidential enclave for virtual machines. The enclave world runs the enclave management monitor RMM, responsible for managing the execution of enclave virtual machines and interacting with the non-secure world. Users can put virtual machines as enclave virtual machines into the confidential enclave to isolate illegal access from external software. Specifically, users can create virtual machines through the virtual machine manager in the non-secure world, and transfer them to the enclave world through the enclave management monitor RMM to become enclave virtual machines. The enclave management monitor RMM will be responsible for the checks and protections related to the security of the confidential enclave. Enclave virtual machines are isolated from each other using virtualization technology, and the enclave management monitor will be responsible for managing the accessible address space of different enclave virtual machines. Enclave virtual machines do not need to trust the non-secure world and the secure world, but only need to trust the enclave management monitor and the root world monitor.

[0030] Correspondingly, the Arm confidential computing architecture CCA also divides the physical address space PAS (Physical address spaces) of the memory into four worlds. Figure 2 The security state of each world in the confidential computing architecture is shown to control the access permission of the physical address space. As shown in the figure, Figure 2 As shown, the root world has the highest access permission and can access the address space of all four worlds. The non-secure world has the lowest access permission and can only access the address space of the non-secure world. The secure world and the enclave world can access the address space of the non-secure world, as well as the address space belonging to their own world.

[0031] In the Arm confidential computing architecture, the address space access control of different worlds is achieved by constructing a granular protection table GPT (Granule Protection Table) and performing a granular protection check GPC (Granule Protection Check) based on the GPT table. Specifically, the confidential computing architecture CCA maintains a granular protection table GPT in the memory, which records the security state of each segment of physical memory in a fine-grained manner. Typically, the granularity of the record is in units of memory pages (4KB size segments). In this way, the GPT table records the security state and access permission of each memory page. When the allocation of memory pages migrates and changes between different worlds, the entries in the GPT can be dynamically updated.

[0032] When a processor accesses memory, the aforementioned RME components in the hardware layer perform a granularity protection check (GPC). In the check, the security state of the current CPU is obtained, and the security state of the memory page being requested to access is obtained by reading the GPT table, and it is checked whether the two match. If the GPC check fails (for example, if a host OS of a non-secure world requests to access the memory of a realm world), a granularity protection exception signal is sent, thereby rejecting this memory access, thereby guaranteeing the isolation between the worlds. Through the above isolation mechanism, the Arm confidential computing architecture further provides an isolated confidential computing environment for the realm virtual machine of the realm world.

[0033] On the other hand, more and more tasks hope to be able to be accelerated by the GPU. However, the existing Arm computing framework is difficult to provide effective confidential protection for GPU computing tasks. On the one hand, because the GPU of most Arm devices belongs to an embedded GPU, it does not contain independent memory, and the Arm computing framework regards the GPU as an untrusted ordinary peripheral, so the GPU needs to share memory with the CPU and many untrusted peripherals, and is more vulnerable to attacks. On the other hand, according to the current workflow of most ARM device GPUs, the task execution and scheduling of the GPU are managed by GPU software (such as GPU drivers and related programming software libraries). However, the GPU software is in the non-secure world and is vulnerable to attacks.

[0034] Specifically, the GPU software is used to manage the computing environment of the GPU and interact with the GPU hardware. Generally, in order to prepare the execution environment, the GPU software allocates physical memory and creates GPU caches according to the requirements of the GPU task. Next, the core components of the GPU task are loaded into the memory, including the GPU task code, the data to be processed, and the metadata (for example, a pointer indicating the address of the GPU cache or a job descriptor). The GPU software also creates a GPU page table and configures the corresponding GPU registers, thereby allowing the GPU to access the above core components via direct memory access (DMA). The GPU software also plans the execution order of the GPU task and submits the GPU task through memory mapping (MMIO).

[0035] Suppose a very strong adversary who controls the entire software stack of the unsecure world and the secure world, including GPU software, untrusted OS, virtual machine manager hypervisor, and the same level of software in the secure world. The adversary wants to spy on or even tamper with the confidential data of the GPU task, including the input data, intermediate data, or execution results of the task. Then, the adversary has the possibility to access the above-mentioned unified memory, read the confidential data stored therein, or control peripherals capable of DMA to read the above-mentioned memory data, thereby launching an attack. In addition, the adversary can also obtain kernel permissions by exploiting vulnerabilities in the kernel, compromise or control the GPU software, obtain the core component information of the task, or initiate tampering attacks by changing the execution order of confidential tasks, modifying GPU register states, and the like.

[0036] To solve the problem of secure operation of the GPU, some researchers have proposed using a GPU trusted computing environment TEE to create an isolated environment for the GPU to run. At present, most of the work of the GPU trusted computing environment is deployed on the Intel platform. However, considering the differences in hardware architecture characteristics, it is difficult to directly transplant these works to the Arm platform. As for the design for the Arm platform, some researchers have proposed the StrongBox scheme and the CRONUS scheme, but they both rely on the traditional Arm TrustZone technology and the components of the secure world, and cannot resist the attackers envisaged by the Arm confidential computing architecture (that is, the secure world will also be destroyed and used by the attacker). In addition, these schemes conflict with the workflow of the Arm confidential computing architecture to some extent. For example, the StrongBox scheme relies on virtualization, which results in the inability to directly compatible with the virtual machine manager, and the CRONUS scheme completely deploys the GPU software inside the trusted execution environment, which is inconsistent with the framework design of the CCA confidential computing architecture.

[0037] In view of this, in the embodiments of the present specification, a scheme is proposed based on the hardware characteristics of the Arm confidential computing architecture, which provides security protection for the GPU computing task without affecting the original functional design of the Arm confidential computing architecture, thereby supporting confidential computing on the GPU.

[0038] Figure 3 A schematic diagram showing a GPU task running in a confidential computing architecture according to one embodiment is shown. Figure 3The system architecture shown conforms to Arm's Confidential Computing Architecture (CCA). In the insecure world, a host machine runs, containing GPU drivers and other DMA peripheral drivers. A hypervisor creates and manages several confidential computing "realms." In the newly introduced realm worlds within the CCA, a Realm Management Monitor (RMM) is deployed to achieve memory isolation between different "realms." The root world deploys a root monitor with the highest privileges, used to manage isolation and switching between worlds, and to provide security authentication mechanisms such as key management and remote verification. The root monitor can be implemented as secure firmware.

[0039] In the CCA architecture described above, the Domain Management Monitor (RMM) of the Domain World and the Root World are considered completely trustworthy. This is because these components require very little memory and code, thus exposing a small attack surface and making them less vulnerable to attack. Furthermore, other components are considered untrustworthy, including the software in the Secure World.

[0040] In the embodiments of this specification, to achieve confidential GPU computation, two components are introduced into the root monitor in the root world: a shadow task component and a GPU environment protection component. The shadow task component is used to implement the shadow task mechanism in each embodiment, while the GPU environment protection component is used to protect the GPU runtime environment from attacks. Furthermore, in this embodiment, the GPU software (including the GPU driver and related function libraries) still runs on the host machine in the insecure world, but requires minor modifications to facilitate the completion of the shadow task mechanism.

[0041] The shadow task mechanism is a new mechanism introduced to make GPU workflows compatible with Arm's confidential computing architecture. Its core idea is to allow GPU software on the host side to create and manage stub applications, such as allocating memory, creating GPU buffers, scheduling and submitting tasks. These stub applications, for example... Figure 3 The stub applications 1 and 2 in the root world have data structures similar to ordinary GPU tasks, including GPU page tables, metadata, and GPU buffers. However, the GPU buffers of these stub applications do not contain actual data to be processed; they only provide a description of the GPU buffer. GPU software can submit these stub applications as usual. Unlike conventional methods, upon submission, the root monitor in the root world replaces the stub applications with the corresponding real GPU applications. The real GPU applications have similar data structures to the stub applications, but they are filled with real confidential data to be processed. The root monitor ultimately submits the real GPU applications to the GPU for computation. Therefore, the solution in this embodiment allows the insecure world to schedule and manage GPU tasks from different domains without accessing the actual confidential data, which aligns with the concept of Arm's confidential computing architecture.

[0042] The following describes the process of scheduling and executing a GPU computing task and providing a confidential isolation environment for it through a shadow task mechanism, in connection with a single GPU application, or a GPU task.

[0043] Figure 4 A method of executing a GPU task in a confidential computing architecture according to an embodiment is shown; Figure 5 A schematic diagram of the data structure of each stage under the shadow task mechanism is shown. It can be understood that, Figure 4 and Figure 5 The method and shadow task mechanism in Figure 3 are executed based on the confidential computing architecture shown in

[0044] First, in the initialization phase or preparation phase, the user can apply for a domain and transmit real data that needs to be processed by the GPU task into it through an encrypted channel. Specifically, the hypervisor in the non-secure world can create a virtual machine according to the user's request, and deploy it to the domain world as a confidential domain by interacting with the domain management monitor RMM. For the convenience of description (and to distinguish from other specific domains when necessary), the domain applied for by the user will be referred to as the first domain in the following. After creating the first domain, the user can conduct key negotiation with the first domain to establish a secure channel. Specifically, the user can exchange keys with the first domain through the DH (Diffie-Hellman) protocol, the DH protocol based on elliptic curve, or other various protocols, so as to negotiate an encryption key. Then, based on the negotiated key, both can establish a secure encryption channel. Through the secure encryption channel, the first domain can receive the confidential data transmitted by the user and store it in the domain world.

[0045] On the other hand, the user provides the other two core components of the GPU task to be executed (hereinafter referred to as the first GPU task) to the host in the non-secure world: task code and cache description. The cache description is used to show the requirements and description of the GPU data cache, which includes the attributes that the GPU data cache is expected to have, such as the number and size of the cache area, the data attributes and types (such as input data or result data, the type and size of the data, etc.) that each cache area should store. In order to prevent the GPU software from tampering with the task code after being attacked, in an embodiment, the user also provides signature information, that is, signs the task code and cache description, and attaches the signature after the transmitted task code and cache description.

[0046] As Figure 5As shown, according to the initialization phase, the first domain obtains the secret data / real data provided by the user, and stores it in the protected domain world (shown in gray). The host obtains the two core components (task code and cache description) provided by the user, and stores them in the unprotected area of the non-secure world (shown in white).

[0047] Based on the above two core components obtained by the host, the GPU software in the host of the non-secure world can create a stub task based on the two core components. As described above, the GPU software mainly includes the GPU driver software, and also includes some function libraries related thereto, such as user layer runtime function libraries (such as OpenCL libraries). The GPU software is modified to create a stub application in the non-secure world based on the shadow task mechanism.

[0048] Specifically, as shown in step S41 in the middle, the GPU software of the non-secure world configures the stub data structure of the first stub task in the non-secure world segment of the memory according to the task code and the cache description of the first GPU task provided by the user, which includes a plurality of cache areas created according to the cache description, and metadata indicating the cache areas. Figure 4

[0049] Specifically, the GPU creates the first stub task and configures the stub data structure, which can include the following steps. As described above, the cache description indicates the number, size, and padding data of the expected GPU data cache. According to such a cache description, the GPU software can allocate corresponding memory space in the non-secure world segment of the memory, create a code cache area, and a plurality of stub data cache areas that meet the requirements of the cache description. In some embodiments, the cache description requires the creation of a plurality of data cache areas, for example, one of which is used to store input data, and another is used to store execution results. Optionally, sometimes the cache description also indicates the creation of a data cache area for storing intermediate results. The GPU software allocates these data cache areas as stub data cache areas according to the requirements of the cache description.

[0050] Different from the conventional processing, the GPU software only stores the task code in the code cache area, but does not fill the real data in the stub data cache area. That is, at most, the stub data cache area stores the description information of the data that should be stored in the cache area, and does not store the real data to be processed. Based on the plurality of cache areas allocated in this way, the GPU software generates metadata for indicating the plurality of cache areas. Specifically, the metadata can include some pointers pointing to the addresses of the respective cache areas. The GPU software also stores the metadata in the non-secure segment of the memory.

[0051] ​Further, the GPU software generates, according to the allocated memory, a GPU page table for executing the first stub task, which can be referred to as a stub GPU page table. The stub GPU page table records the mapping between the virtual addresses and the physical addresses of the memory in the process of executing the GPU task. Initially, the GPU memory mapping MMIO (Memory-Mapped Input / Output) is configured to point to the stub GPU page table. Specifically, the GPU has a page table base address register TTBR for storing the base address of the page table. The TTBR is mapped to the address in the memory through the GPU memory mapping MMIO. Initially, the page table base address is pointed to the memory address storing the stub GPU page table, i.e., to the stub GPU page table, through the GPU MMIO.

[0052] In this way, the GPU software creates the first stub task and configures it with the stub data structure. As shown in the example, in the memory segment of the non-secure world, the GPU software allocates a data buffer 1, a data buffer 2 and a code buffer, and stores only the corresponding data description in the data buffers 1 and 2 and stores the previously obtained task code in the code buffer. According to the allocated buffers, the GPU software generates metadata, which points to the above-mentioned data buffers 1 and 2 and the code buffer. Further, the GPU software generates the stub GPU page table and causes the GPU memory mapping to point to the stub GPU page table. Figure 5

[0053] It can be seen that the process of creating the stub task is similar to that of creating a regular task, except that the data buffer therein is not filled with real data. Therefore, the created stub task is a "hollow shell" task without real data, but has exactly the same data structure as the real task and can be managed and scheduled.

[0054] Therefore, after creating the above-mentioned first stub task, the GPU software inserts it into the GPU task queue as usual, arranges the execution order of the task, and submits the first stub task to the GPU hardware via the root monitor.

[0055] Upon receiving the submission of the first stub task, the root monitor creates a real task in the domain world, i.e., performs the step S42. In this step, the root monitor configures the real data structure corresponding to the stub data structure in the memory in the first domain segment corresponding to the first domain, and stores the secret data provided by the user therein. Figure 4

[0056] ​​Specifically, the root monitor creates a real data buffer of corresponding size and attributes based on the stub data buffer in the stub data structure, and fills it with real data or leaves it temporarily empty according to the description therein. In one embodiment, the stub data structure has multiple data buffers, including an input data buffer for storing input data and a result data buffer for storing result data. Thus, the root monitor creates the corresponding real input data buffer and result data buffer in the first domain segment, stores the previously user-provided confidential data in the created input data buffer, and leaves the result data buffer temporarily empty.

[0057] In addition, the root monitor creates a real GPU page table based on the stub GPU page table and stores it in the first domain segment. To do this, the root monitor can first validate the page table entries recorded in the stub GPU page table, for example, checking for duplicate or invalid mappings. If the validation passes, the root monitor constructs the real GPU page table by copying or replaying the page table entries. However, it's important to note that since the data cache in the stub cache structure does not store real data and does not participate in real GPU computation, entries related to the data cache in the real GPU page table are modified to point to the real data cache in the real data structure.

[0058] Continuing with the previous example, such as Figure 5 As shown, during the real application creation phase, within the protected domain segment, real data buffer 1 and data buffer 2, corresponding to the two data buffers in the stub task, are created. Real confidential data is stored in data buffer 1, while data buffer 2 is temporarily left empty to store result data. Additionally, the root monitor generates real GPU page tables, which are stored within this first domain segment.

[0059] When a real GPU task needs to be executed, the root monitor first provides a protected execution environment for it. Specifically, the root monitor protects memory access to core components of the GPU task through the Granularity Protection Check (GPC) memory protection mechanism provided by the Arm Confidential Computing architecture. Since the real data buffer and the real GPU page table are already in a protected world, additional protection is needed for target segments storing important and sensitive data in the insecure world. These target segments include those storing metadata and task code. Furthermore, the GPU memory-mapped MMIO segment, containing the base address of the GPU page table, is also a segment that should be protected.

[0060] Therefore, according to the GPC mechanism, the root monitor executes step S43, which updates the granularity protection table GPT so that, according to the updated GPT table, the target segment is accessible to the GPU and has domain world permissions for other objects.

[0061] As mentioned before, the confidential computing architecture CCA maintains a granular protection table GPT in memory, in which the security status of each piece of physical memory is recorded in a fine-grained manner, for GPC checking, so as to implement memory isolation. According to the scheme of the present embodiment, the root monitor can maintain multiple versions of the GPT table, so that the target segment has different access permissions for different objects.

[0062] Specifically, the root monitor maintains at least a first version GPT table and a second version GPT table. The first version GPT table is used for access to memory by the CPU and other peripherals, and in the updated first version GPT table, the target segment storing the metadata and the task code can be set to belong to the domain world. In addition, in order to protect the GPU memory mapping MMIO segment, it can be set to belong to the root world in the above-mentioned first version GPT table. According to the permissions of the different worlds shown in the table, various applications requesting memory access through the CPU or other peripherals, including software in the secure world, cannot access the above-mentioned target segment and GPU memory mapping. Figure 2

[0063] The second version GPT table is a GPT table for the first domain for the GPU, which can be generated and initialized when the first domain is created. Through the update of step S43, the target segment is set to an accessible segment in this GPT table. Specifically, in one example, in the updated second version GPT table, the first domain segment and the target segment are set to belong to the non-secure world and can be accessed; other segments are set to belong to the root world and cannot be accessed.

[0064] In this way, the root monitor ensures the isolation of the memory space required by the real GPU task by updating the GPT table, so that it is not accessed or stolen by other applications, thereby providing a protected execution environment for the execution of the real GPU task.

[0065] Preferably, before executing the real GPU task, the task code and the cache description are also verified to prevent the attacked GPU software from tampering with the task code or the cache description. Specifically, as mentioned before, the user can attach a signature when providing the task code and the cache description. Then, the root monitor can verify the signature based on the signature of the task code stored in the current code cache area and the cache description stored in the stub data cache area. In addition, the root monitor can also check the GPU state to ensure that there is no hidden storage of malicious task code.

[0066] After passing the various checks / verifications, the root monitor can submit and start the execution of the real GPU task. To this end, in step S44, the root monitor modifies the target mapping relationship, so that the GPU executes the first GPU task using the above-mentioned target segment and the real data structure.

[0067] ​In particular, the root monitor modifies the GPU memory mapping to point the GPU page table base address to the real GPU page table stored in the first domain, so that the stub GPU page table is replaced by the real GPU page table. In addition, the root monitor also modifies the pointer of the metadata to point to the real data buffer, so that the stub data buffer is replaced by the real data buffer. Thus, the GPU executes the first GPU task using the target segment and the real data structure. In particular, the GPU addresses to the code buffer and the real data buffer based on the real GPU page table and the modified metadata, so as to process the real confidential data in the real data buffer based on the task code in the code buffer.

[0068] Continuing the previous example. As Figure 5 shown, to execute the real GPU task, the target segment and the GPU memory mapping storing the metadata and the task code are set as the protected region by the aforementioned step S43. Thus, when executing the real GPU task, the real GPU page table is addressed according to the GPU memory mapping; the code buffer and the real data buffer are located according to the real GPU page table and the metadata, so that the real confidential data can be processed based on the task code stored therein. According to the indication of the metadata, the GPU can also store the running result of the task processing in the real result data buffer (i.e., the data buffer 2). Through the setting of step S43, the data used in the above process are all in the protected memory region, so as to ensure the confidentiality of the task execution.

[0069] After the execution of the first GPU task is completed, the root monitor can restore the original execution environment. In particular, the root monitor can first restore the register mapping address in the GPU memory mapping MMIO and the pointer in the metadata. Then, the previous GPU execution environment is cleared, including flushing the TLB entries corresponding to the GPU page table, etc. After clearing the GPU execution environment, the normal access permission of the aforementioned target segment can be restored by updating the GPT table again, i.e., the target segment is restored to belong to the non-secure world.

[0070] As Figure 5 shown, in the environment restoration phase after the execution of the GPU task, the data in the execution process can be cleared, and the previously temporarily protected target segment (the GPU memory mapping segment, the metadata segment and the code buffer segment) is restored to the unprotected non-secure world. The result data generated by the execution is stored in the first domain segment of the domain world, and the user can read the running result from the first domain through the secure channel. Thus, the confidential execution and confidential calculation of the GPU task are completed.

[0071] Recalling the above procedure, GPU confidential computing is implemented compatible with Arm confidential computing architecture CCA through the shadow task mechanism. According to the shadow task mechanism, a stub task not containing real data is created by GPU software in the non-secure world, and the stub task is scheduled and managed as a regular process. After the stub task is submitted, the root monitor creates a real GPU task containing real data and provides a protected execution environment for the real GPU task. Then, the root monitor replaces the stub task with the real GPU task, so that the GPU hardware executes the real GPU task in the protected execution environment. In this way, GPU confidential computing is implemented in the Arm confidential computing architecture CCA.

[0072] As mentioned before, the provision of the secure execution environment for the GPU is implemented by maintaining and updating multiple versions of the GPT table. Maintaining multiple versions of the GPT table can put some pressure on the execution performance of the entire architecture. In some embodiments, optimization of the GPT table maintenance method is also proposed to further improve system performance.

[0073] As mentioned before in connection with step S43, in order to provide a secure execution environment for the first GPU task, the root monitor needs to maintain at least two versions of the GPT, wherein the first version of the GPT table is used for access control of the memory by the CPU and other peripherals, and the second version of the GPT table is used for the GPU to execute the first domain task. In fact, although the other peripherals and the CPU have the same access permission settings for the target segment corresponding to the first GPU task, different peripherals still have their own permission settings for other segments of the memory, which are different from those of the CPU. In addition, there can be multiple domains in the domain world that are isolated from each other, supporting confidential execution of multiple GPU tasks. At this time, it is also necessary to maintain the corresponding GPT table for other domains. Therefore, in fact, the root monitor can need to maintain significantly more than 2 versions of the GPT table.

[0074] Figure 6 GPT tables maintained by the root monitor in one example scenario are shown. As shown in Figure 6 In this example scenario, at least domains R1 and R2 are included in the domain world. It is assumed that the users of the two domains respectively require that GPU task 1 be executed based on domain R1 and GPU task 2 be executed based on domain R2. Therefore, the GPU software creates R1 stub tasks and R2 stub tasks in the segments originally belonging to the non-secure world. The segment in which the R1 stub task stores its corresponding metadata and task code is referred to as target segment 1, and the segment in which the R2 stub task stores its corresponding metadata and task code is referred to as target segment 2.

[0075] In order to provide isolated execution environments for GPU task 1 and GPU task 2, the root monitor needs to maintain at least Figure 6 four GPT tables as shown.

[0076] In the GPT table for the CPU, the memory segments corresponding to the domains R1 and R2 belong to the domain world as usual. In addition, the above-mentioned target segment 1 and target segment 2, which originally belong to the non-secure world, are also set as domain world segments. In addition, the GPU memory mapping MMIO segment is set to belong to the root world.

[0077] The GPT table for the untrusted peripheral is generally similar to the GPT table for the CPU, where the settings about the domains R1, R2, target segment 1 and target segment 2 are exactly the same. The difference is that the peripheral has its corresponding memory access restrictions, and the part of the memory segment that the CPU can access (e.g. the small segment at the very front in the figure) is set to belong to the root world in the GPT table of the peripheral, which the peripheral has no access to.

[0078] The GPU GPT table for domain 1 is the GPT table applicable when the GPU executes the GPU task 1 corresponding to the domain 1. In this table, the domain R1 and the target segment 1 are set to belong to the non-secure world and can be accessed; all other segments are set to belong to the root world and cannot be accessed. This means that when the GPU executes the GPU task 1 corresponding to the domain 1, only the memory data of the domain R1 and the target segment 1 can be accessed, and no other segment data can be accessed.

[0079] The GPU GPT table for domain 2 is the GPT table applicable when the GPU executes the GPU task 2 corresponding to the domain 2. In this table, the domain R2 and the target segment 2 are set to belong to the non-secure world and can be accessed; all other segments are set to belong to the root world and cannot be accessed. This means that when the GPU executes the GPU task 2 corresponding to the domain 2, only the memory data of the domain R2 and the target segment 2 can be accessed, and no other segment data can be accessed.

[0080] When a hardware (CPU, GPU or peripheral) requests access to the memory, the RME in the hardware layer performs GPC checks according to the corresponding applicable GPT table, thereby performing memory access control.

[0081] As can be seen from the two GPU GPT tables for the domain 1 and the domain 2, memory isolation is also performed between GPU tasks of different domains, ensuring the security of the execution environment. It can be understood that if more GPU tasks need to be executed based on more domains, more GPT tables need to be maintained.

[0082] In order to reduce the burden of maintaining multiple GPT tables, in an embodiment, a hierarchical table is adopted to maintain the GPT table. Specifically, the GPT table supports a hierarchical table architecture composed of a top-level table and a sub-level table, wherein the descriptors in the sub-level table are only used to describe the security attributes of the memory segment, without having to describe the address, read-write permission and other attributes. Based on such characteristics, a sub-level table shared by the CPU and various peripherals can be constructed. Specifically, a memory region is pre-designated, and a sub-level table is constructed to manage the access control of the memory region. The GPU software is set to create a stub task in the predetermined memory region. Further, the GPT tables of the CPU and various peripherals are configured so that their table descriptors all point to the unified sub-level table. In use, only the security attributes in the sub-level table need to be flexibly modified in different stages to set whether to protect the target segment storing the metadata and task code. Since the GPT tables of the GPU and various peripherals all point to the sub-level table, they can share the security settings in the sub-level table.

[0083] Figure 7 A sub-level table is shown according to an embodiment. As shown, Figure 7 a predetermined memory segment is designated as GPU memory, and a sub-level table is established for this memory, wherein the page descriptors indicate the security attributes (which world it belongs to) of the corresponding pages. The GPT tables of the CPU and various peripherals all point to the sub-level table through the table descriptors. Whenever the GPU software creates a stub application, a stub data structure is created in the GPU memory segment, and when it is necessary to protect the metadata and task code, the security attributes of the corresponding part in the sub-level table are modified. Since the sub-level table is shared by multiple GPT tables, the above modification is synchronized to each GPT table, thereby simplifying the maintenance of multiple GPT tables and the synchronization of the same content.

[0084] Regarding multiple GPT tables for multiple domains, for example Figure 6 the GPU GPT table for domain 1 and the GPU GPT table for domain 2 in have similar patterns: only two world attributes, non-secure world (accessible) and root world (inaccessible). Therefore, the GPT tables for different domains can be generated based on the same template, according to which the entire memory is first set to the root world, and then the corresponding domain segment is set to the non-secure world (normal). When performing GPU confidential computing, additionally, the target segment corresponding to the current GPU task (the segment storing the metadata and task code) is set to the non-secure world, thereby allowing the GPU to access it.

[0085] In the above manner, the maintenance and update of the GPT table can be optimized, and the execution performance of the GPU task can be further improved.

[0086] In another aspect, corresponding to the above method process, the embodiments of the present disclosure also disclose a root monitor in a confidential computing architecture, the confidential computing architecture comprising a secure world, a domain world, an unsecure world and a root world; the root monitor is located in the root world. The root monitor can comprise a shadow task component and a GPU environment protection component.

[0087] The shadow task component is configured to, in response to GPU software of the unsecure world configuring a stake data structure of a first stake task in an unsecure world segment of a memory, configure a real data structure corresponding to the stake data structure in a segment corresponding to the first domain in the memory, and store confidential data to be processed therein, wherein the stake data structure comprises a plurality of cache areas allocated according to a cache description provided by a user, and metadata indicating each cache area.

[0088] The GPU environment protection component is configured to update a granularity protection table (GPT) so that, according to the updated GPT table, a target segment storing the metadata and task code of the first GPU task provided by the user has the authority of the domain world for the GPU and for other objects.

[0089] The shadow task component is further configured to modify a target mapping relationship so that the GPU executes the first GPU task using the target segment and the real data structure.

[0090] The specific execution process of the shadow task component and the GPU environment protection component can refer to the descriptions of the foregoing embodiments of the shadow task component and the GPU environment protection component, and will not be repeated here. Figure 4 and Figure 5

[0091] In typical embodiments, the root monitor is implemented as secure firmware.

[0092] According to embodiments of still another aspect, a computing device is also provided, comprising a memory and a plurality of processors, the computing device forming a confidential computing architecture, the confidential computing architecture comprising a secure world, a domain world, an unsecure world and a root world; the root world comprising the aforementioned root monitor.

[0093] Those skilled in the art should be aware that, in one or more of the above examples, the functions described in the present disclosure can be implemented in hardware, software, firmware or any combination thereof. When implemented in software, the functions can be stored in a computer readable medium or transmitted as one or more instructions or codes on a computer readable medium.

[0094] ​The above detailed description of the specific embodiments of the present application has been given to illustrate the purpose, technical solutions and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solutions of the present application shall be included in the protection scope of the present application.

Claims

1. A method for executing a GPU task in a confidential computing architecture, the confidential computing architecture comprising a secure world, a domain world, an unsecure world, a root world; the method comprising: allocating, by GPU software in the unsecure world, a staked data structure of a first staked task in an unsecure world section of a memory according to task code and cache description of the first GPU task provided by a user, the staked data structure comprising a plurality of cache regions allocated according to the cache description and metadata indicating each cache region; allocating, by a root monitor in the root world, a real data structure corresponding to the staked data structure in a section of the memory corresponding to a first domain, and storing confidential data to be processed in the real data structure; the first domain being a confidential domain applied by the user and deployed in the domain world; updating, by the root monitor, a granularity protection table (GPT) so that, according to the updated GPT table, a target section storing the metadata and the task code is accessible to the GPU and has the authority of the domain world to other objects; wherein updating the GPT table comprises: updating a first version of the GPT table so that, in the updated first version of the GPT table, the target section belongs to the domain world; the first version of the GPT table being used for CPU and a plurality of peripherals; and updating a second version of the GPT table so that, in the updated second version of the GPT table, the section of the first domain and the target section are set as unsecure world memory accessible, and other sections are not accessible; wherein the second version of the GPT table is used for the GPU to execute the task of the first domain; modifying, by the root monitor, a target mapping relationship so that the GPU executes the first GPU task using the target section and the real data structure.

2. The method of claim 1, wherein, the GPU software comprising a GPU driver and a related function library. 3.The method of claim 1, further comprising, before allocating the staked data structure of the first staked task: receiving, by the first domain, the confidential data provided by the user through a secure channel; receiving, by a host in the unsecure world, the task code and the cache description. 4.The method of claim 3, further comprising: negotiating, by the first domain and the user, a key through a key negotiation protocol; constructing the secure channel based on the key.

5. The method of claim 1, wherein, allocating the staked data structure of the first staked task comprises: allocating a code cache region to store the task code; allocating a plurality of staked data cache regions according to the cache description to store the cache description in corresponding staked data cache regions; generating the metadata comprising pointers to the code cache region and the plurality of staked data cache regions.

6. The method of claim 5, wherein, allocating the real data structure corresponding to the staked data structure comprises: allocating a plurality of real data cache regions corresponding to the plurality of staked data cache regions to store the confidential data in the real data cache regions.

7. The method of claim 6, wherein, the plurality of real data cache regions comprising an input data cache region storing the confidential data and a result data cache region for storing an execution result of the first GPU task.

8. The method of claim 6, wherein, configuring the stupa data structure of the first stupa task further comprises generating a stupa GPU page table according to the stupa data cache area; configuring the real data structure corresponding to the stupa data structure further comprises generating a real GPU page table according to the stupa GPU page table and the real data cache areas.

9. The method of claim 6, wherein, the root monitor modifies the target mapping relationship, including: modifying the pointer in the metadata to point to the real data cache areas and the code cache area.

10. The method of claim 8, wherein, the root monitor modifies the target mapping relationship, including: modifying the GPU memory mapping to point to the real GPU page table.

11. The method of claim 5, wherein, the user-provided task code and cache description of the first GPU task are accompanied by signature information; before modifying the target mapping relationship, the method further comprises: the root monitor verifies the task code stored in the code cache area according to the signature information.

12. The method of claim 1, wherein, in the updated first version GPT table, the GPU memory mapping segment is set to belong to the root world.

13. The method of claim 1, wherein, the first version GPT table includes a first GPT table for the CPU and a plurality of second GPT tables for a plurality of peripherals; the first GPT table and the plurality of second GPT tables point to the same level table through a table descriptor; the sub-level table is constructed for a preset memory segment, and the target segment belongs to the preset memory segment.

14. The method of claim 1, further comprising: after executing the first GPU task, restoring the target segment to belong to the non-secure world.

15. A root monitor in a confidential computing architecture, the confidential computing architecture including a secure world, a domain world, a non-secure world and a root world; the root monitor is located in the root world and includes a shadow task component and a GPU environment protection component, wherein: the shadow task component is configured to, in response to the non-secure world GPU software configuring a stupa data structure of a first stupa task in a non-secure world segment of memory, configure a real data structure corresponding to the stupa data structure in a segment corresponding to a first domain in the memory, and store confidential data to be processed therein, wherein the stupa data structure includes a plurality of cache areas allocated according to user-provided cache description and metadata indicating each cache area, and the first domain is a confidential domain in the domain world applied by the user. The GPU environment protection component is configured to update a granularity protection table (GPT) so that, according to the updated GPT table, a target section storing the metadata and task code of a first GPU task provided by a user has the rights of a domain world for the GPU and for other objects; and wherein updating the granularity protection table (GPT) specifically comprises: updating a first version GPT table so that, in the updated first version GPT table, the target section belongs to a domain world; the first version GPT table is used for a CPU and a plurality of peripherals; and updating a second version GPT table so that, in the updated second version GPT table, the section of the first domain and the target section are set as accessible non-secure world memory, and other sections are not accessible; wherein the second version GPT table is used for the GPU to execute a task of the first domain. The shadow task component is further configured to modify a target mapping relationship so that the GPU executes the first GPU task using the target section and the real data structure.

16. A computing device comprising a memory and a plurality of processors, the computing device forming a confidential computing architecture, the confidential computing architecture comprising a secure world, a domain world, a non-secure world, and a root world; the root world comprising the root monitor of claim 15.

Images