Patent Description:
GPU (Graphics Processing Unit) compute workloads are becoming more important across multiple business domains to accelerate processing intensive workloads. There is also a strong incentive to move these workloads to the cloud for optimizing the overall cost of processing.

However, guaranteeing confidentiality and integrity for GPU workloads is also becoming more critical as compute workloads in the server space gain importance. While confidentiality and integrity during the period that data is being operated on by the GPU is critical, it is similarly important that the GPU performance is not unnecessarily compromised to achieve this end goal. <CIT> describes trusted local memory management in a virtualized GPU. <CIT> describes an apparatus which accesses secure pages in a trust domain using secure lookups in first and second sets of page tables.

Embodiments described here are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Embodiments described herein are directed to device memory protection for supporting trust domains.

In improving processing operation, compute workloads may be transferred to a processing accelerator, such as a graphics processing unit (GPU), to accelerate operations. However, such processing by an accelerator requires proper handling of security concerns, which may be complicated by the implementation of trust domains that can modify the privilege levels for certain elements. As used herein, "trust domain" (TD) refers to a hardware-isolated, virtual machine (VM), and "accelerator" refers to an apparatus to accelerate processing operation by one or more processors. An accelerator may include, for example, a GPU (Graphics Processing Unit) or other similar apparatus.

A VMM (Virtual Machine Manager, which operates as a hypervisor for virtual machine management) and PF KMD (Physical Function Kernel Mode Driver) have traditionally operated at a higher privilege for a GPU. These are responsible for providing isolation between virtual machines or processes using page tables.

To support the required security posture for moving compute loads to the cloud, it is important to provide protections against elements the VMM or PF KMD can control, while still allowing for needed functionality to keep the GPU operational for processing of use cases.

In some embodiments, an apparatus, system, or process is implemented to provide confidentiality and integrity of device memory. Techniques are provided to protect GPU local memory page tables in addition to adding confidentiality and integrity support to all of device memory, while avoiding added performance overhead. An embodiment may be applied to any accelerator with attached memory that is utilized in implementing a requirement for memory protection.

In a virtualized GPU that supports SR-IOV (Single-Root Input-Output Virtualization), GPU memory resources are managed by system software on the host. Depending on whether memory is system memory (on the host side) or device memory (on the accelerator side), the VMM, host operating system (OS), or PF KMD are responsible for managing the physical address translations tables. However, these entities are not trusted in a trust domain. For example, in TDX I/O operation, the VMM, host OS, and PF KMD are not generally trusted by the trust domain.

In some embodiments, an apparatus, system, or process enables use of GPU memory resources of a TD in a trusted manner, while preserving the role of processing resources, including the VMM, host OS, and PF KMD, as the manager of those resources. In some embodiments, device memory protection is provided for the trust domains from any other entity including the VMM, and further protects the device memory from physical attacks.

<FIG> and <FIG> illustrate memory tables and memory confidentiality for supporting trust domains, according to some embodiments. In some embodiments, to assist in providing confidentiality and integrity requirements for support of trust domains, the following key concepts are implemented:.

As illustrated in <FIG>, a system or apparatus <NUM> includes translation tables <NUM> including a table structure with multiple levels. As used herein, translation tables refers in general to tables that are used to translate a virtual address to device physical address. In some embodiments, memory requests <NUM> to a device memory <NUM> originating from a GPU <NUM> utilize translation tables <NUM> to translate virtual addresses to device physical addresses, the translation tables <NUM> including a first level table <NUM>, the first level table being a per process PPGTT table, and a second level table <NUM>, the second level table being an LMTT table providing final device physical addresses. In some embodiments, the memory request pass through the first level table <NUM> to the second level table, which is used to obtain the final device physical address.

The second level table <NUM> reside in the device memory <NUM> and may be used for local memory in place of, for example, the Intel VT-d (Intel Virtualization Technology for Directed I/O) translation tables used for system memory managed by system software (i.e., by the host OS (Operating System) and VMM (Virtual Memory Manager)). The translation tables <NUM> are managed by the Host KMD, in coordination with the VMM or host OS. In some embodiments, a separate table structure is allocated for each trust domain or assignable interface that receives local memory resources.

In some embodiments, to support confidentiality and integrity requirements, a secure version of the translation tables <NUM> is generated. An associated GPU <NUM>, which may include one or more trust domains <NUM>, can run multiple contexts at a given point of time on the different engines and each of these could be running on behalf of different virtual functions (VFs), wherein some of the VFs may be trust domains <NUM> and others may be non-trusted VMs. The GPU hardware is to use the secure version of the second level table for trust domain accesses and the non-secure version for the requests from the non-trusted VMs.

As illustrated in <FIG>, a system or apparatus <NUM> includes the GPU <NUM>, with a memory encryption block <NUM> that supports both confidentiality and integrity being added ahead of a memory controller <NUM> for device memory <NUM>. In some embodiments, the memory encryption block <NUM> is not only used to provide protection from physical attacks, but further is used to provide the isolation between the different VFs (Virtual Functions) and also to detect any type of integrity attacks on the trust domain data. Separate keys for encryption may be provided for each trust domain to ensure that an integrity failure will occur when one trust domain attempts to read or write data belonging to another TD.

As shown in <FIG>, memory requests <NUM> may include a certain number of integrity bits. In some embodiments, in addition to bits for a MAC value <NUM>, a TD bit <NUM> in a memory request <NUM> is further provided to ensure that encrypted data belonging to a TD is not returned back to a non-TD entity, thus providing protection against, for example, translation table re-mapping attacks by the PF KMD or VMM. To ensure that latency is optimized, the integrity may be implemented using a hash function on CRC (Cyclic Redundancy Check) bits of the memory controller <NUM>. The current proposal uses <NUM> bits for the MAC (Message Authentication Code) <NUM> along with an extra bit to indicate the CL (Cache Line) belongs to a TD. The <NUM> bits are stored in the CRC bits available for the memory request transactions. This technology may be applied to ensure there is no added performance impact from additional integrity related information added to the solution as existing bits can be utilized in the integrity protection. In some embodiments, the hash computation for integrity support is performed post encryption by the memory and encryption block.

<FIG> and <FIG> illustrates an example of a system to provide device memory protection for supporting trust domains, according to some embodiments. As illustrated in <FIG>, an example of a system <NUM> includes one or more processors <NUM>, which may include a central processing unit (CPU), and an accelerator that may include a GPU <NUM>. The accelerator <NUM> includes a device memory <NUM> and a memory controller <NUM>. Processors <NUM> may include one or more TDs <NUM>, and the accelerator <NUM> may include one or more TDs <NUM>.

In some embodiments, the device memory <NUM> includes translation tables <NUM> (as further illustrated in <FIG> as translation tables <NUM>), wherein the translation tables <NUM> include a first level table, the first level table being a per process table, and a second level table, the second level table providing final device physical addresses. In some embodiments, the translation tables <NUM> includes both secure and non-secure versions, wherein the secure version may be generated by the graphics security controller <NUM>. In some embodiments, the GPU hardware is to use the secure version of the second level table for trust domain accesses and the non-secure version for the requests from non-trusted VMs.

In some embodiments, a memory encryption block <NUM> is provided ahead of the memory controller <NUM> for memory <NUM>, wherein the memory encryption blocks include support for both confidentiality (in encrypting data for storage) and integrity (in applying one or more integrity protection technologies).

In some embodiments, in order to minimize the added latency in the system <NUM> that may be caused by the memory confidentiality and integrity protection, the integrity provided by the encryption block <NUM> is implemented, for example, using a hash function on the CRC bits of the memory controller <NUM>, as further illustrated in <FIG>. In some embodiments, the integrity may alternatively or additionally be implemented using storage in a sequestered memory region; or by another integrity protection technology.

In some embodiments, separate keys <NUM> and key IDs <NUM> are generated for each trust domain <NUM> by a security controller <NUM> to ensure integrity failure occurs when one trust domain attempts to reads or write data belonging to another trust domain. For every guest, the security controller <NUM> will assign keys <NUM> and key IDs <NUM>.

For example, as illustrated in <FIG>, the key IDs <NUM> can be allocated by the security controller <NUM> into the GPU <NUM> and programmed explicitly into registers <NUM> that are associated with the respective trust domains. Alternatively, the security controller may allocate the key IDs <NUM> by creating a secure table <NUM>, wherein the page table <NUM> may include a mapping of key ID to trust domain ID; or may include inserting the key IDs in the page table entry itself <NUM>. Each of such alternatives may be applied to provide necessary support in the GPU <NUM>.

If Key IDs are programmed in registers <NUM>, the registers themselves are provided appropriate protection, wherein only the graphics security controller <NUM> can update the registers as these are protected from other agents. If a secure device memory page table <NUM> is used, this may be created by the security controller <NUM> using a key for a given guest virtual machine. The secure device memory page table <NUM> is both encrypted and integrity protected in memory using a dedicated key.

In some embodiments, a VMM/hypervisor does not have access to the key assigned to any guest. GPU hardware enforces the appropriate key for reading the guest page tables, and also enforces a guest specific key for any memory accesses when they arise from the appropriate guest. For any requests that target system memory on the host side, the GPU <NUM> may rely on the host IOMMU (Input-Output Memory Management Unit) and the memory encryption block in host for the appropriate translation and protections. The GPU hardware is to ensure that any system memory operations go out as GPA (Guest Physical Address) after translating virtual address through PPGTT for trust domains, thereby ensuring the host side protections for trust domains naturally occur.

In some embodiments, when a trust domain <NUM> starts, the trust domain goes through a TD initialization phase. As part of the TD initialization, a unique key is assigned to the trust domain <NUM> by the graphics security controller <NUM>. The graphics security controller <NUM> sets up the Key ID mapping (as illustrated in <FIG>) for the virtual function in the GPU as well. Depending on the number of trust domains simultaneously supported in the GPU, a secure scheme involving directly updating GPU registers or using integrity protected memory for the table that maps Key ID to trust domain ID can be followed.

<FIG> illustrates security in translation tables, according to some embodiments. As part of moving a trust domain to a secure state, a graphics security controller, such as graphics security controller <NUM> illustrated in <FIG> and <FIG>, is used to ensure that pages are not aliased, and, once the pages are assigned, such pages are not re-assigned by the hypervisor/VMM without an explicit indication going back to the trust domain.

In some embodiments, the provision of security in translation tables is accomplished by the graphics security controller creating an integrity protected version of the table in memory (referred to herein as the secure version of the translation table), and the hardware (such as of the GPU) enforcing use of the secure version of the translation table when accesses originate from a trust domain. In some embodiments, if a multi-level page table is used, a unique key is used for each of the levels to ensure that an attack presented by an untrusted host through rearranging the different levels of the table is prevented. In this case, any unexpected access to the translation table would result in an integrity failure when the table is being read by a trust domain as the key IDs are hardware enforced. In some embodiments, the physical function or a non-trusted VF cannot use a trust domain Key ID for accessing or updating the page tables.

For example, as illustrated in <FIG>, in a system or process <NUM> a physical function <NUM> may access a translation table in memory <NUM>. In some embodiments, the translation table in memory <NUM> is processed by a graphics security controller <NUM> to provide integrity and security protection of the translation table. The graphics security controller <NUM> is to generate an encrypted translation table in memory, the encrypted table also include integrity protection. In some embodiments, the encryption includes use of a separate key for each trust domain, a separate key for each level of the page table, or both. In some embodiments, the use of the encrypted table is enforced by device hardware, such as by the GPU hardware handling memory accesses that originate from a trust domain.

<FIG> illustrates translation table access for secure and non-secure sources, according to some embodiments. In some embodiments, when GPU hardware is operating on behalf of a trust domain, as part of the normal process flows, GPU hardware will first obtain the trust domain to Key ID mapping that's been set up by the graphics security controller, such as the mapping for key IDs <NUM> established by graphics security control <NUM> as illustrated in <FIG>.

In some embodiments, as part of the context set up for a trust domain, the GPU is to fetch a secure version of the translation table, such as the secure version of translation tables <NUM> illustrated in <FIG>, using the appropriate keys. Only the secure version of the translation table is used by the GPU while operating on behalf of a trust domain. Any integrity failure on the secure table itself is detected and reported back to the trust domain. All trust domain memory transactions leaving the GPU will have the Key ID enforced by the GPU. For non-trusted workloads that could be simultaneously running on the GPU, the non-secure version of the translation table is used and all memory transactions leaving the GPU will not use encryption or integrity protection.

In some embodiments, as illustrated in <FIG>, for a physical function (PF) or regular (i.e., non-secure) virtual function (VF) running on behalf of a non-TD VM <NUM>, in a submission on a GPU engine <NUM>, the GPU hardware enforces use of the non-secure translation table, and specifically use of the normal (non-secure) second level table, and utilizes a key ID for clear data <NUM> (shown as a Clear Key ID) for all fetches from the device memory <NUM>. In this manner functions for non-secure sources are able to handle memory accesses without requiring decryption of the translation table.

In some embodiments, for a trust domain running on behalf of a TD VM <NUM>, in a submission on the GPU engine <NUM>, the GPU hardware enforces use of the appropriate key for the secure translation table <NUM>, utilizing a VM key ID for all fetches from the device memory <NUM>. In this manner, data for secure TD VM sources is security and integrity protected utilizing the encrypted translation table.

<FIG> is a flowchart to illustrate a setup process for device memory protection in support of trust domains, according to some embodiments. In a process <NUM> illustrated in <FIG>, a physical function (PF) allocates device memory for one or more trust domain (TD) virtual machines (VMs) <NUM>, such as the allocation of a portion of memory in memory <NUM> illustrated in <FIG> for a TD VM. The PF may create an LMTT mapping for the device memory for the TD VM using an untrusted key ID <NUM>. In some embodiments, an address translation table includes a table structure with multiple levels, including a first level per process PPGTT table, and a second level LMTT table providing final device physical addresses.

In some embodiments, the process continues with transitioning a particular TD to a secure state <NUM>. A security controller, such as graphics security controller <NUM> illustrated in <FIG>, is then to allocate a key ID for the TD <NUM>. The allocation of key IDs by the security controller may include allocating the key IDs as explicit registers that are mapped to the respective trust domains, allocating the key IDs by creating a secure table, wherein the page table may include a mapping of key ID to trust domain ID; or including the key IDs in the page table entry itself, as illustrated in <FIG>.

In some embodiments, the security controller is to read the LMTT table of the address translation tables with an untrusted key ID <NUM>. The security controller is then to write a secure LMTT back to memory with a trusted key ID <NUM>. In this manner, there is no requirement for locking the table in the reading and writing process, and integrity is ensured using a unique key ID per each TD. In some embodiments, GPU hardware may be operable to enforce the secure use of the translation table, the GPU hardware to use the secure version of the translation tables for trust domain accesses and the non-secure version of the translation table for accesses from non-trusted VMs.

<FIG> is a flowchart to illustrate a runtime process for device memory protection in support of trust domains, according to some embodiments. In a process <NUM> following the setup process <NUM> illustrated in <FIG>, a GPU memory access request is received <NUM>, and a determination is made regarding the secure (associated with a TD) or non-secure status of the memory access request <NUM>. For example, the secure status may be indicated by the status of a TD bit, such as TD bit <NUM> illustrated in <FIG>, or other method of communicating the TD status for the memory access request. If the memory request is a secure memory request <NUM>, the GPU is to access the secure version of the translation tables <NUM>. The process then proceeds with receiving one or more keys for use in access the secure translation tables <NUM>. If integrity is then verified for the page table access <NUM>, the process may continue with receipt of the physical address for the request and completing the memory access <NUM>. If integrity is not verified <NUM>, such as in circumstances in which an incorrect key is utilized, an integrity failure may then be reported to the trust domain <NUM>.

If the memory request is a non-secure memory request <NUM>, the GPU is to access the non-secure version of the translation tables <NUM>, and the process may proceed with receiving the physical address for the request and completing the memory access <NUM>.

<FIG> illustrates an embodiment of an exemplary computing architecture for device memory protection for supporting trust domains, according to some embodiments. In various embodiments as described above, a computing architecture <NUM> may comprise or be implemented as part of an electronic device. In some embodiments, the computing architecture <NUM> may be representative, for example, of a computer system that implements one or more components of the operating environments described above. The computing architecture <NUM> may be utilized to provide device memory protection for supporting trust domains, such as described in <FIG>.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive or solid state drive (SSD), multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the unidirectional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in <FIG>, the computing architecture <NUM> includes one or more processors <NUM> and one or more graphics processors <NUM>, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors <NUM> or processor cores <NUM>. In one embodiment, the system <NUM> is a processing platform incorporated within a system-on-a-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

An embodiment of system <NUM> can include, or be incorporated within, a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system <NUM> is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system <NUM> can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system <NUM> is a television or set top box device having one or more processors <NUM> and a graphical interface generated by one or more graphics processors <NUM>.

In some embodiments, the cache memory <NUM> is shared among various components of the processor <NUM>.

In some embodiments, one or more processor(s) <NUM> are coupled with one or more interface bus(es) <NUM> to transmit communication signals such as address, data, or control signals between processor <NUM> and other components in the system. The interface bus <NUM>, in one embodiment, can be a processor bus, such as a version of the Direct Media Interface (DMI) bus. However, processor buses are not limited to the DMI bus, and may include one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express), memory buses, or other types of interface buses. In one embodiment the processor(s) <NUM> include an integrated memory controller <NUM> and a platform controller hub <NUM>. The memory controller <NUM> facilitates communication between a memory device and other components of the system <NUM>, while the platform controller hub (PCH) <NUM> provides connections to I/O devices via a local I/O bus.

Memory device <NUM> can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, non-volatile memory device such as flash memory device or phase-change memory device, or some other memory device having suitable performance to serve as process memory. Memory device <NUM> may further include non-volatile memory elements for storage of firmware. In one embodiment the memory device <NUM> can operate as system memory for the system <NUM>, to store data <NUM> and instructions <NUM> for use when the one or more processors <NUM> execute an application or process. Memory controller hub <NUM> also couples with an optional external graphics processor <NUM>, which may communicate with the one or more graphics processors <NUM> in processors <NUM> to perform graphics and media operations. In some embodiments a display device <NUM> can connect to the processor(s) <NUM>. The display device <NUM> can be one or more of an internal display device, as in a mobile electronic device or a laptop device, or an external display device attached via a display interface (e.g., DisplayPort, etc.). In one embodiment the display device <NUM> can be a head mounted display (HMD) such as a stereoscopic display device for use in virtual reality (VR) applications or augmented reality (AR) applications.

In some embodiments the platform controller hub <NUM> enables peripherals to connect to memory device <NUM> and processor <NUM> via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller <NUM>, a network controller <NUM>, a firmware interface <NUM>, a wireless transceiver <NUM>, touch sensors <NUM>, a data storage device <NUM> (e.g., hard disk drive, flash memory, etc.). The data storage device <NUM> can connect via a storage interface (e.g., SATA) or via a peripheral bus, such as a Peripheral Component Interconnect bus (e.g., PCI, PCI Express). The touch sensors <NUM> can include touch screen sensors, pressure sensors, or fingerprint sensors. The wireless transceiver <NUM> can be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver such as a <NUM>, <NUM>, Long Term Evolution (LTE), or <NUM> transceiver. The firmware interface <NUM> enables communication with system firmware, and can be, for example, a unified extensible firmware interface (UEFI). The network controller <NUM> can enable a network connection to a wired network. In some embodiments, a high-performance network controller (not shown) couples with the interface bus <NUM>. The audio controller <NUM>, in one embodiment, is a multi-channel high definition audio controller. In one embodiment the system <NUM> includes an optional legacy I/O controller <NUM> for coupling legacy (e.g., Personal System <NUM> (PS/<NUM>)) devices to the system. The platform controller hub <NUM> can also connect to one or more Universal Serial Bus (USB) controllers <NUM> connect input devices, such as keyboard and mouse <NUM> combinations, a camera <NUM>, or other USB input devices.

In the description above, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described embodiments. It will be apparent, however, to one skilled in the art that embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form. There may be intermediate structure between illustrated components. The components described or illustrated herein may have additional inputs or outputs that are not illustrated or described.

Various embodiments may include various processes. These processes may be performed by hardware components or may be embodied in computer program or machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor or logic circuits programmed with the instructions to perform the processes. Alternatively, the processes may be performed by a combination of hardware and software.

Portions of various embodiments may be provided as a computer program product, which may include a computer-readable medium having stored thereon computer program instructions, which may be used to program a computer (or other electronic devices) for execution by one or more processors to perform a process according to certain embodiments. The computer-readable medium may include, but is not limited to, magnetic disks, optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically-erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or other type of computer-readable medium suitable for storing electronic instructions. Moreover, embodiments may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer.

Many of the methods are described in their most basic form, but processes can be added to or deleted from any of the methods and information can be added or subtracted from any of the described messages without departing from the basic scope of the present embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations can be made. The particular embodiments are not provided to limit the concept but to illustrate it. The scope of the embodiments is not to be determined by the specific examples provided above but only by the claims below.

If it is said that an element "A" is coupled to or with element "B," element A may be directly coupled to element B or be indirectly coupled through, for example, element C. When the specification or claims state that a component, feature, structure, process, or characteristic A "causes" a component, feature, structure, process, or characteristic B, it means that "A" is at least a partial cause of "B" but that there may also be at least one other component, feature, structure, process, or characteristic that assists in causing "B. " If the specification indicates that a component, feature, structure, process, or characteristic "may", "might", or "could" be included, that particular component, feature, structure, process, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, this does not mean there is only one of the described elements.

An embodiment is an implementation or example. It should be appreciated that in the foregoing description of exemplary embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various novel aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed embodiments requires more features than are expressly recited in each claim. Rather, as the following claims reflect, novel aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims are hereby expressly incorporated into this description, with each claim standing on its own as a separate embodiment.

The following Examples pertain to certain embodiments:.

Claim 1:
One or more non-transitory computer-readable storage mediums having stored thereon executable computer program instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
allocating (<NUM>) device memory for one or more trust domains, TDs, in a system including one or more processors and a graphics processing unit, GPU;
allocating (<NUM>) a trusted key ID for a TD of the one or more TDs;
creating (<NUM>) Local Memory Translation Table, LMTT, mapping for address translation tables, the address translation tables being stored in a device memory of the GPU;
transitioning (<NUM>) the TD to a secure state, including generating a secure version of the address translation tables, the secure version being an encrypted version of the address translation tables, and generating one or more encryption keys to provide access to the secure version of the address translation tables; and
receiving and processing (<NUM>) a memory access request associated with the TD, wherein processing the memory access request includes:
upon determining that the memory access request is associated with the one or more TDs, accessing (<NUM>) the secure version of the address translation tables using an encryption key of the one or more encryption keys; and
receiving and processing a memory access request that does not originate from the TD; and
upon determining that a memory access request does not originate from the TD, accessing (<NUM>) a non-secure version of the address translation tables for the memory access request.