Secure Direct Memory Access

Abstract

The processor [101] supports managing direct memory access (DMA) accesses in a secure manner in an input / output memory management unit (IOMMU). The IOMMU is configured to ensure that for a given DMA request [111] issued by an I / O device [108] and associated with a particular running VM [106], the device is bound to the VM according to a specified security registration process and the request targets a region of memory [120] allocated to the VM. Thus, the IOMMU prevents malicious entities from accessing sensitive information of the VM via DMA requests.

Description

[Background technology]

[0001] In classified computing environments, processing systems (e.g., servers) run multiple software programs, such as virtual machines and virtual machine managers (e.g., hypervisors), where different software programs are owned by different entities. For example, in some classified computing environments, different virtual machines run by the environment are owned by different companies. The virtual machine manager (e.g., hypervisor) controls the scheduling of different virtual machines for execution and provides an interface between the virtual machines and the server hardware, so that each virtual machine (VM) can operate as if it were running on its own dedicated hardware.

[0002] Because different VMs are often owned by different entities, some confidential computing systems support security features that prevent one VM from accessing data or other information associated with another VM. However, in some cases, a VM's confidential information is accessible through input / output devices that interact with the VM.

[0003] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0004] [Figure 1] 1 is a block diagram of a processing system that uses an input / output memory management unit (IOMMU) to manage secure direct memory access (DMA) to memory, according to some embodiments. [Figure 2]2 is a block diagram of an example mapping table used by the IOMMU of FIG. 1 to manage secure DMA requests, according to some embodiments. [Figure 3] 2 is a block diagram illustrating an example of the IOMMU of FIG. 1 that prevents execution of a DMA request associated with a virtual machine when the DMA request is issued by an unbound I / O device, according to some embodiments. [Figure 4] 2 is a block diagram illustrating an example of the IOMMU of FIG. 1 that prevents execution of a DMA request associated with a virtual machine if the request targets memory outside of a specified range, according to some embodiments. [Figure 5] 2 is a block diagram illustrating an example of the IOMMU of FIG. 1 managing DMA access for multiple virtual machines, according to some embodiments. [Figure 6] FIG. 1 is a flow diagram of a method for managing secure DMA access in an IOMMU, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1-6 illustrate techniques for managing DMA access in a secure manner in an IOMMU of a processing system, according to some embodiments. The IOMMU is configured to ensure that, for a given DMA request issued by an I / O device and associated with a particular running VM, the device is bound to the VM according to a specified security registration process and the request targets a region of memory allocated to the VM. Thus, the IOMMU prevents malicious entities from accessing sensitive information of the VM via DMA requests.

[0006] By way of further example, in some processing systems, I / O devices are permitted to issue DMA requests, with each DMA request identifying a region of memory from which data is to be read, a region of memory to which data is to be written, or a combination thereof. To increase processing efficiency, the IOMMU of the processing system translates addresses for DMA requests, translating virtual addresses to system physical addresses rather than performing the address translation in the processing system's memory controller or central processing unit (CPU). However, in at least some cases, DMA requests make secure data in the processing system vulnerable to unauthorized access or modification. For example, a malicious entity can use a DMA request to read data from a region of memory allocated to a running VM, thereby accessing sensitive information. As another example, a malicious entity can use a DMA request to write data to a region of memory allocated to a running VM, requesting the VM to take corrective action that exposes the VM's behavior to unauthorized inspection.

[0007] To prevent these and similar attacks by malicious entities, a processing system uses the techniques described herein to employ an IOMMU to ensure that each DMA request associated with a VM is issued by an I / O device trusted by the VM and that each DMA request targets a region of memory allocated to the VM. For example, in some embodiments, a security module (e.g., a security coprocessor) of the processing system implements a designated device binding process (e.g., a Trusted Execution Environment (TEE) Device Interface Secure Protocol (TDISP) process) that binds an I / O device to a VM. The binding process implements designated processes, such as an authentication process, that allow the VM to “trust” the I / O device, i.e., assume that the operation of the I / O device is secure and unlikely to result in the disclosure of sensitive VM information. A bound VM (i.e., that has undergone the binding process) may be referred to herein as a Trusted VM (TVM). Additionally, the security module assigns to each running TVM a corresponding region of memory in which the TVM is exclusively permitted to store data, and builds a mapping table entry that associates the TVM with the device and the corresponding region of memory.

[0008] In response to receiving a DMA request from an I / O device, the IOMMU performs device validation by using a mapping table to ensure that the I / O device is bound to the TVM. If I / O device validation is successful, the IOMMU determines, based on the mapping table, whether the DMA request targets a region of memory assigned to the TVM. If not, the IOMMU prevents execution of the DMA request as described herein. If the region of memory targeted by the DMA request is assigned to the VM, the IOMMU executes the DMA request. Thus, using the techniques described herein, the IOMMU prevents execution of the DMA request on behalf of the VM if the requesting I / O device is not bound to the VM or if the DMA request targets a region of memory not assigned to the VM. Thus, the IOMMU prevents unauthorized access to or modification of sensitive information associated with the VM. Furthermore, because these security operations are performed by the IOMMU itself, it is difficult for a hypervisor or other entity to interfere with these operations, thus supporting secure DMA access in sensitive computing environments. These security operations allow the hypervisor and other administrative entities to be outside the TVM's trusted compute boundary (TCB). Thus, the TVM does not need to trust the hypervisor and other administrative entities, but can instead rely on the IOMMU-based protection mechanisms described herein to prevent unauthorized access or modification of trusted VM memory.

[0009] 1 illustrates a processing system 100 that implements a programmable SMT protected mode in accordance with some embodiments. Processing system 100 is generally configured to execute a set of instructions (e.g., a computer program) for performing tasks on behalf of an electronic device. Accordingly, in different embodiments, processing system 100 is part of any of a variety of electronic devices. For purposes of explanation, it will be assumed that processing system 100 is part of an electronic device that implements a secure computing environment, such as a server. However, in other embodiments, processing system 100 is part of a desktop computer, a laptop computer, a tablet, a game console, etc.

[0010] To implement the secure computing environment and to execute the set of instructions and corresponding operations, processing system 100 includes processor 101, memory 103, and one or more input / output (I / O) devices, such as I / O device(s) 108. In some embodiments, processor 101 is a general-purpose processor, such as a central processing unit (CPU), that includes hardware structures configured to retrieve and execute a set of instructions. Memory 103 includes one or more memory devices configured to store and retrieve data based on commands (e.g., store and load commands) received from processor 101. Thus, in different embodiments, memory 103 is random access memory (RAM), non-volatile memory (NVM), hard disk memory, etc., or any combination thereof.

[0011] I / O device 108 is any device that can process input information, output information, or a combination thereof, on behalf of processing system 100, independent of processor 101. For example, in some embodiments, I / O device 108 is a network interface device that processes input and output information for a network (not shown) connected to processing system 100. In other embodiments, I / O device 108 is a storage controller (e.g., a disk controller or a non-volatile memory (NVM) storage controller), a controller associated with a user interface (e.g., a keyboard), etc.

[0012] To execute the set of instructions and corresponding operations, processor 101 includes processor core 102, security module 104, and input / output memory management unit 110. It should be understood that in some embodiments, processor 101 includes additional hardware for executing the instructions and performing operations based on those instructions, such as additional processor cores, additional processing units (e.g., one or more graphics processing units), one or more controllers (e.g., memory controllers and input / output controllers), etc.

[0013] Processor core 102 includes one or more instruction pipelines that include multiple stages for executing instructions in a pipelined manner. Thus, for example, in some embodiments, the instruction pipeline of processor core 102 includes a fetch stage, a decode stage, a dispatch stage, one or more execution stages (with one or more corresponding execution units), a retire stage, etc. Processor core 102 also includes or has access to memory structures and other hardware (not explicitly shown in FIG. 1 ) that support the execution of instructions. For example, in some embodiments, processor core 102 includes or has access to one or more cache structures for storing data used in the execution of instructions.

[0014] Security module 104 is a set of hardware structures generally configured to create, monitor, and maintain a security environment for processor 101. For example, in at least some embodiments, security module 104 is configured to manage the boot process of processor 101, initialize security-related mechanisms of processor 101, monitor processing system 100 for suspicious activity or events, and implement appropriate responses. In some embodiments, security module 104 includes a microcontroller, a cryptographic coprocessor (CCP) for encrypting and decrypting data, local memory and local registers for storing cryptographic keys, and an interface for interacting with memory 103, an I / O controller of processor 101, and configuration registers of processor 101. In some embodiments, security module 104 includes environmental management control hardware that performs environmental and security checks to ensure that processor 101 is operating in accordance with specified security parameters.

[0015] In some embodiments, security module 104 manages the device binding process, and I / O devices are bound to the TVM by going through a specified security registration process. For example, in some embodiments, TVM 106 attempts to bind I / O device 108 by sending a bind request to security module 104. In response, security module 104 initiates the specified security registration process by requesting authentication information (e.g., a device certificate) from I / O device 108 and verifying the authentication information (e.g., by comparing the authentication information or key information generated based on the authentication information with one or more security keys). If the authentication information received from I / O device 108 is verified, security module 104 indicates to TVM 106, and to other components of processor 101 as described further herein, that I / O device 108 is bound to TVM 106.

[0016] It should be appreciated that in some embodiments, an I / O device can be bound to multiple virtual machines by undergoing a designated security registration process for that TVM. For example, in some embodiments, each virtual machine can interact with the physical I / O device using a different virtual function (VF), thus virtualizing the I / O device as a different virtual I / O device for each TVM. In some embodiments, security module 104 binds an I / O device to a VM by binding the corresponding VF to a TVM, thus allowing a single physical I / O device to be bound to multiple TVMs (as long as the physical I / O device undergoes the security registration process for each TVM).

[0017] In some embodiments, an I / O device has its own translation lookaside buffer (TLB), sometimes referred to as an address translation cache (ATC), and requests address translations from the IOMMU using the address translation service (ATS). The I / O device is assigned to the TVM. In response to the I / O device requesting the ATS, the IOMMU performs security checks, including checking that the I / O device is bound to the TVM and that the ATS request targets a region of memory assigned to the TVM. If either of these checks fails, the IOMMU rejects the ATS request. If both checks pass, the IOMMU translates the address and returns the translated address to the I / O device, which caches the translated address in the ATC. The I / O device then issues a DMA request using the translated address. In response, the IOMMU uses a mapping table to perform security checks on the DMA request.

[0018] As described above, processing system 100 is generally configured to implement a confidential computing environment, specifically to execute multiple virtual machines (VMs), also referred to as guests (e.g., TVM 106, VM 113), and hypervisor 107, also referred to as a host, to manage the execution of the multiple VMs. In some embodiments, at least one of the VMs is a TVM (e.g., TVM 106 is a trusted VM), and at least one other of the VMs is an untrusted VM (e.g., VM 113 is an untrusted VM). Because different VMs, and in at least some cases hypervisor 107, are owned by different entities, processing system 100 implements security features to protect data in a given TVM from access by other software, such as another VM or hypervisor 107, or I / O devices assigned to the untrusted VM. For example, processing system 100 implements data security for the TVM by implementing secure area 120 of memory 103 that stores encrypted data. In particular, processor 101 is configured to encrypt designated data of each TVM according to a corresponding private encryption key and store the encrypted data in secure area 120. Because the data is encrypted, the data of one TVM is protected from unauthorized access by other VMs (both TVMs and untrusted VMs) as well as hypervisor 107. In at least some embodiments, encryption keys for the TVMs are managed by security module 104, and data encryption and decryption for the TVMs is performed by a dedicated hardware encryption / decryption module (not shown) in a memory controller (not shown) of processor 101.

[0019] To increase processing efficiency, IOMMU 110 is generally configured to perform address translation and memory protection on behalf of processor 101, i.e., to perform address translation and memory protection operations using dedicated hardware in IOMMU 110. In particular, IOMMU 110 includes dedicated hardware for performing memory address translation and memory protection for direct memory access (DMA) operations, and I / O devices (such as I / O device 108) generate DMA requests (e.g., DMA request 111) to read data from memory 103, write data to memory 103, or a combination thereof. In some embodiments, each DMA request includes a descriptor indicating the virtual address of the data being accessed, i.e., the virtual address of the data to be read, the virtual address to which the data is to be written, or both. These virtual addresses indicate the region of memory 103 that is the target of the DMA request. IOMMU 110 is generally configured to translate virtual addresses indicated by DMA requests into physical addresses in memory 103 and to interact with memory 103 to perform one or more operations (read operations, write operations, or a combination thereof) indicated by the DMA requests.

[0020] Because DMA requests, in at least some cases, are executed independently of the operation of processor 101, DMA requests provide a means for a malicious entity to access sensitive information associated with a TVM executing on processor 101. For example, a malicious I / O device (or an I / O device controlled by a malicious entity) could issue a DMA request targeted to secure region 120 of memory 103, thereby exposing sensitive data in TVM 106 to unauthorized access or triggering an action by TVM 106 (e.g., replacing transferred sensitive data), which in turn could expose the sensitive information to the malicious entity.

[0021] To address these potential vulnerabilities, security module 104 maintains a mapping table 109 that indicates, for each TVM, the I / O devices bound to the TVM and the region of memory 103 allocated to the TVM. While mapping table 109 is shown as being stored in IOMMU 110, it will be understood that in at least some embodiments, mapping table 109 is stored in memory 103 and IOMMU 110 includes one or more caches that store a subset of the entries in mapping table 109, thereby improving performance.

[0022] In response to receiving a DMA request, IOMMU 110 determines a TVM associated with the request (e.g., based on a descriptor included with the DMA request). For example, in some embodiments, each DMA request includes a VM identifier (e.g., VMID) that indicates the TVM for which the DMA request was issued. In some embodiments, the DMA request includes a requestor identifier that indicates the I / O device that issued the DMA request. IOMMU 110 determines, based on mapping table 109, whether the requesting I / O device is bound to the indicated TVM. If not, IOMMU 110 prevents execution of the DMA request. For example, in some embodiments, IOMMU 110 prevents execution of the DMA request by not initiating an address translation process for the DMA request, so that the virtual address indicated by the DMA request is not translated to a physical address. This prevents the DMA request from being properly executed and protects sensitive information associated with the TVM.

[0023] In response to identifying that the requesting I / O device (i.e., the I / O device that issued the DMA request) is bound to the TVM indicated in the DMA request, IOMMU 110 determines whether the DMA request targets a portion of memory 103 that is within the region of memory allocated to the TVM, as indicated by mapping table 109. Illustratively, in some embodiments, the DMA request indicates virtual addresses to be read from, written to, or a combination thereof. IOMMU 110 compares the virtual addresses indicated by the DMA request to determine whether all virtual addresses are within the region of memory allocated to the corresponding TVM, as indicated by mapping table 109. If any of the virtual addresses are outside the allocated region of the TVM, IOMMU 110 prevents execution of the DMA request, as described above. If the virtual address indicated by the DMA request is within the allocated region of the TVM of memory 103, IOMMU 110 executes the DMA request. Thus, IOMMU 110 ensures that a DMA request is satisfied only if 1) the requesting device is bound to the corresponding TVM through a specified security registration process, and 2) the DMA request targets a portion of the VM's allocated memory 103. Thus, IOMMU 110 prevents malicious entities from accessing sensitive VM information via DMA requests.

[0024] In some embodiments, mapping table 109 stores physical addresses rather than virtual addresses, and the IOMMU first translates the virtual address indicated by the DMA request into a physical address (or set of physical addresses), and then determines whether the physical address (or set of physical addresses) is within the region of memory allocated to the corresponding TVM, as indicated by mapping table 109.

[0025] It should be understood that in some embodiments, the operations of IOMMU 110 occur in a different order than described in the example above. For example, in some embodiments, IOMMU 110 first checks whether the DMA request targets a portion of memory 103 allocated to the TVM associated with the request, and if so, IOMMU 110 checks whether the requesting device is bound to the TVM. In other embodiments, IOMMU 110 checks both conditions (whether the requesting device is bound to the TVM and whether the DMA request targets a portion of memory 103 allocated to the TVM) simultaneously or in parallel.

[0026] 2 illustrates an example of mapping table 109, according to some embodiments. In the illustrated example, mapping table 109 includes multiple entries (e.g., entry 220, entry 221), each of which is assigned to a different TVM, such as a TVM currently executing on processor 101, a TVM that has undergone a VM provisioning process on processing system 100 (and thus is expected to execute on processing system 100 in response to a VMRUN command), or any combination thereof. While mapping table 109 is shown in FIG. 1 as a unified structure, it should be understood that in some embodiments, one or more of the fields of the mapping table are stored in different tables or other structures.

[0027] Each entry in mapping table 109 includes multiple fields, including a VM identifier field 225, a bind device field 226, an allocated memory field 227, an address mapping field 228, and an encryption key field 229. VM identifier field 225 stores a virtual machine identifier (VMID) assigned (e.g., by security module 104) to the VM associated with the corresponding entry. That is, the VM identifier field of an entry stores a value called VMID that indicates the VM corresponding to that entry.

[0028] An entry's bind device field 226 stores a value or set of values ​​that indicates a different device identifier (device ID) for each I / O device bound to the corresponding TVM by security module 104. In some embodiments, in response to an I / O device successfully completing a specified security process for binding, security module 104 updates the corresponding entry's bind device field 226 to indicate 1) the device ID of the bound I / O device and 2) the VMID of the TVM to which the I / O device is bound. In some embodiments, when security module 104 modifies mapping table 109, security module 104 instructs IOMMU 110 to invalidate IOMMU caches and flush DMA channels.

[0029] Allocated memory field 227 indicates the portion of memory 103 allocated to the corresponding VM. In some embodiments, when a VM begins execution (e.g., via a VMRUN command), security module 104 determines the portion of memory allocated to the VM, and in particular ensures that two VMs are not allocated to the same (or overlapping) portion of memory 103. Security module 104 modifies allocated memory field 227 of the corresponding entry in mapping table 109 to indicate the allocated portion of memory 103 (e.g., by storing a set of memory addresses indicating the allocated portion).

[0030] Address mapping field 228 stores a set of virtual-to-physical address mappings for TVMs corresponding to entries in mapping table 109. In at least some embodiments, when executing a DMA request, IOMMU 110 uses address mapping field 228 to determine the physical address in memory 103 accessed by the request. For example, in some embodiments, address mapping field 228 stores a set of address mapping pages, and each DMA request includes a descriptor that identifies the virtual address of the data to be read, the location where the data is to be written, or a combination thereof. When executing a DMA request, IOMMU 110 uses address mapping field 228 to perform a page walk based on the virtual address included in the DMA descriptor, thereby translating the virtual address into a set of physical addresses. IOMMU 110 then uses the physical addresses to interact with memory 103, thereby executing the DMA request. By including address mapping field 228 in mapping table 109 along with the corresponding bind device field 226 and allocated memory field 227, the IOMMU can quickly determine whether a given DMA request is allowed to execute, and if so, can quickly initiate the address translation process to execute the DMA request.

[0031] In other embodiments, the mappings from virtual addresses to physical addresses are not stored in mapping table 109 itself, but instead in a set of guest and host page table structures. IOMMU 110 uses these structures to translate virtual addresses to physical addresses. The physical addresses are then used by IOMMU 110 to determine whether the corresponding DMA request targets the region of memory indicated by allocated memory field 227.

[0032] Encryption key field 229 stores a trusted VM encryption key identifier assigned to the corresponding TVM by security module 104. In some embodiments, IOMMU 110 tags each successful DMA request (i.e., each DMA request that passes security checks and is allowed to execute) with the corresponding encryption key identifier. The encryption key identifier is used by the memory controller to select an encryption key for encrypting or decrypting data in secure region 120.

[0033] 1 as a unified structure, it should be understood that in some embodiments, one or more of the fields of the mapping table are stored in different tables. For example, in some embodiments, mapping table 109 represents two different table structures indexed using different information. One table stores bind device information reflected by VM identifier field 225 and bind device field 226, and another table stores allocated memory information reflected by VM identifier field 225 and allocated memory field 227. IOMMU 110 indexes the first table using the device identifier, and the second table is indexed using the physical address associated with the DMA request.

[0034] 3 shows an example of an IOMMU 110 using mapping table 109 to prevent execution of a DMA request 111, according to some embodiments. In the illustrated example, IOMMU 110 receives DMA request 111 from I / O device 108. DMA request 111 includes a descriptor prepared by I / O device 108 indicating that DMA request 111 is associated with TVM 106 (e.g., by including the VMID of TVM 106 in the descriptor). That is, I / O device 108 indicates a request to read data, write data, or transfer data (read and write) on behalf of TVM 106 via fields in DMA request 111. I / O device 108 also provides its own device ID in DMA request 111 to indicate that the request was generated by I / O device 108.

[0035] In response to receiving DMA request 111, IOMMU 110 accesses mapping table 109, and in particular the entry in mapping table 109 that corresponds to TVM 106. For example, in some embodiments, IOMMU 110 uses the VMID indicated by DMA request 111 to locate the entry in mapping table 109 having the corresponding VMID in VM identifier field 225. IOMMU 110 then compares the device ID in DMA request 111 with the device identifier stored in bind device field 226 of the entry in mapping table 109. In the example of FIG. 3, assume that the device ID of I / O device 108 is not stored in bind device field 226, indicating that I / O device 108 is not bound to TVM 106 by security module 104. In response to determining that the device ID of I / O device 108 is not stored in bind device field 226, IOMMU 110 prevents execution of DMA request 111. For example, in some embodiments, IOMMU 110 prevents execution of DMA request 111 by preventing the use of address mapping field 228 to translate the virtual address of DMA request 111 to a physical address. Additionally, IOMMU 110 provides message 342 to I / O device 108 indicating that DMA request 111 has been denied. In some embodiments, IOMMU 110 provides message 342 (or a similar message) to TVM 106. In some embodiments, IOMMU 110 notifies security module 104 that DMA request 111 has been denied and that there has been a potential attempt at a security violation by I / O device 108. This allows security module 104 to take corrective action, such as notifying a system administrator of the potential security violation.

[0036] 4 shows another example of an IOMMU 110 using mapping table 109 to prevent execution of a DMA request 111, according to some embodiments. In the illustrated example, similar to FIG. 3, IOMMU 110 receives a DMA request 111 from I / O device 108. DMA request 111 includes a descriptor prepared by I / O device 108 indicating the portion of memory 103 targeted by the DMA request. That is, I / O device 108 indicates, via fields in DMA request 111, on behalf of TVM 106, the memory addresses targeted by the request to read data, write data, or transfer data (read and write).

[0037] In response to receiving DMA request 111, IOMMU 110 accesses mapping table 109, and in particular the entry in mapping table 109 that corresponds to TVM 106. IOMMU 110 then compares the portion of memory indicated by DMA request 111 with the portion of memory indicated by allocated memory field 227 of the entry in mapping table 109. In the example of FIG. 3, the portion of memory indicated by DMA request 111 is assumed to be at least partially outside the portion of memory stored in allocated memory field 227. That is, DMA request 111 targets, at least partially, a portion of memory 103 that is not allocated to TVM 106. In response, IOMMU 110 prevents execution of DMA request 111 and notifies security module 104 that DMA request 111 has been denied by sending message 342.

[0038] As mentioned above, in some embodiments, the information represented by mapping table 109 is stored in multiple different tables that are indexed differently. For example, in some embodiments, a first table (called a source verification table) stores a VM identifier field 225 and a corresponding bound device field 226 for each TVM, and a second table (called a memory ownership table) stores an allocated memory field 227 and a corresponding VM identifier field 225. IOMMU 110 receives DMA requests from I / O devices, where the DMA request includes a device identifier for the I / O device and a virtual address that is the target of the DMA request. IOMMU 110 accesses the source verification table to determine whether the I / O device is bound to a TVM, and if not, IOMMU 110 does not execute the request.

[0039] When an I / O device is bound to a TVM, IOMMU 110 translates the virtual address to a physical address using a set of page tables. IOMMU 110 uses the physical address to index a memory ownership table and compares the VM identifier obtained from the memory ownership table with the VM indicated by the source verification table. If the VM identifiers do not match, IOMMU 110 does not perform the DMA request. If the VM identifiers match, IOMMU 110 performs the DMA request.

[0040] As described above, mapping table 109 stores an individual entry for each VM running on processor 101. This allows IOMMU 110 to individually grant or deny DMA requests for different VMs, independent of DMA requests for other VMs. An example according to some embodiments is shown in FIG. 5. In the example of FIG. 5, assume that processor 101 is running two different VMs: TVM 106 and VM 550. IOMMU 110 receives DMA request 111 from I / O device 108, indicating a request to access memory on behalf of TVM 106. Further assume that mapping table 109 indicates that I / O device 108 is not bound to TVM 106, that DMA request 111 targets a portion of memory 103 not allocated to TVM 106, or both. Therefore, IOMMU 110 prevents DMA request 111 from executing and indicates (via message 342) that DMA request 111 has been denied.

[0041] For DMA request 551, assume that mapping table 109 indicates that I / O device 549 is bound to VM 550. Further, assume that mapping table 109 indicates that DMA request 551 targets a portion of memory 103 that is not allocated to VM 550. Therefore, the IOMMU determines that DMA request 551 is granted (as indicated by message 555) and therefore performs DMA request 551. Thus, in the example of FIG. 5 , IOMMU 110 selectively grants some DMA requests and denies other DMA requests, thus preventing a malicious actor from stopping or slowing down the execution of multiple VMs in processing system 100 by issuing inappropriate DMA requests.

[0042] FIG. 6 illustrates a flow diagram of a method 600 for managing secure DMA access in an IOMMU, according to some embodiments. For illustrative purposes, method 600 is described with reference to an exemplary embodiment in processing system 100 of FIG. 1 , although it should be understood that in other embodiments, method 600 is implemented in processing systems having different configurations. At block 602, security module 104 binds one or more I / O devices to TVM 106 according to a specified security process, such as a Trusted Execution Environment (TEE) Device Interface Secure Protocol (TDISP) process. For example, in some embodiments, processing system 100 includes a communications fabric (not shown) that conforms to the Peripheral Component Interconnect Express (PCIe) communications protocol. In particular, I / O devices, such as I / O device 108, are configured to communicate with processor 101 and IOMMU 110 according to the PCIe communications protocol. In some embodiments, the PCIe communication protocol establishes a TDISP security registration process for binding I / O devices to VMs, and security module 104 binds I / O devices to running VMs using the TDISP security registration process. Additionally, in block 602, security module 104 allocates memory regions (also called portions) to each running VM. Security module 104 programs mapping table 109 to store an indication of the I / O devices bound to each VM and the memory regions allocated to each VM.

[0043] At block 604, the IOMMU 110 receives a DMA request 111 from an I / O device 108. The DMA request 111 includes an identifier for a VM associated with the request and address information indicating the portion of memory 103 that the request is directed to. At block 606, the IOMMU 110 determines whether the VM associated with the DMA request 111 is bound to the I / O device 108. If not, method flow moves to block 608, where the IOMMU 110 prevents execution of the DMA request 111. Method flow then returns to block 604.

[0044] If, at block 606, the IOMMU 110 determines that the VM associated with the DMA request 111 is bound to the I / O device 108, method flow proceeds to block 610, where the IOMMU 110 determines whether the DMA request 111 targets a portion of the memory 103 allocated to the corresponding VM. If not, method flow moves to block 608, where the IOMMU 110 prevents execution of the DMA request 111. If the DMA request 111 targets a portion of the memory 103 allocated to the corresponding VM, method flow moves to block 612, where the IOMMU 110 executes the DMA request 111. Method flow then returns to block 604.

[0045] In some embodiments, a method includes: in response to receiving, from a first device, a first direct memory access (DMA) request associated with a first virtual machine (VM), identifying whether the first VM is bound to the first device by a designated security registration process; and preventing execution of the first DMA request in response to identifying, in an input / output memory management unit (IOMMU) of the processor, that the first device is not bound to the first VM. In one aspect, the method includes in response to receiving, from a second device, a second DMA request associated with the first VM, identifying whether the first VM is bound to the second device by a designated security registration process; and performing the second DMA request in response to identifying, in the IOMMU, that the second device is bound to the first VM. In another aspect, the method includes in response to receiving the first DMA request, determining that the first DMA request targets a first region of memory outside a region of memory allocated to the first VM, preventing execution of the first DMA request. In yet another aspect, the method includes determining a region of memory allocated to the first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses. In yet another aspect, the method includes identifying a cryptographic key associated with the first VM based on the mapping table.

[0046] In one aspect, the method includes generating a mapping table in a security coprocessor. In another aspect, the designated security enrollment process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) enrollment process.

[0047] In some embodiments, a method includes: in response to receiving, from a first device, a first direct memory access (DMA) request associated with a first virtual machine (VM), identifying whether the first DMA request targets a region of memory allocated to the first VM; and in response to identifying, at an input / output memory management unit (IOMMU), that the first DMA request targets a portion of memory outside the region of memory allocated to the first VM, preventing execution of the first DMA request. In one aspect, the method includes in response to receiving, from a second device, a second DMA request associated with the first VM, identifying whether the second DMA request targets a region of memory allocated to the first VM; and in response to identifying, at the IOMMU, that the second DMA request targets a region of memory allocated to the first VM, executing the second DMA request. In another aspect, the method includes, in response to receiving the first DMA request, preventing execution of the first DMA request in response to determining that the first VM is not bound to the first device by a specified security registration process.

[0048] In one aspect, the method includes executing a security registration process for the first VM in a security coprocessor of a processor configured to execute the first VM. In another aspect, the method includes determining a region of memory allocated to the first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses. In yet another aspect, the method includes, in response to receiving a second DMA request associated with the second VM from a second device, identifying whether the second DMA request targets a region of memory allocated to the second VM, and, in response to identifying, in an IOMMU, that the second DMA request targets a portion of memory outside the region of memory allocated to the second VM, preventing execution of the second DMA request.

[0049] In some embodiments, the processor includes an input / output memory management unit (IOMMU), wherein the IOMMU is configured to: in response to receiving a first direct memory access (DMA) request associated with a first virtual machine (VM) from a first device, identify whether the first VM is bound to the first device by a designated security registration process, and prevent execution of the first DMA request in response to identifying that the first device is not bound to the first VM. In one aspect, the IOMMU is configured to: in response to receiving a second DMA request associated with the first VM from a second device, identify whether the first VM is bound to the second device by a designated security registration process, and perform the second DMA request in response to identifying that the second device is bound to the first VM. In another aspect, the IOMMU is configured to: in response to receiving the first DMA request, determine that the first DMA request targets a first region of memory outside a region of memory allocated to the first VM, prevent execution of the first DMA request.

[0050] In one aspect, the IOMMU is configured to determine a region of memory allocated to a first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses. In another aspect, the IOMMU is configured to: in response to receiving a second DMA request associated with a second virtual machine (VM) from a second device, identify whether the second VM is bound to the second device by a designated security registration process, and perform the second DMA request in response to identifying that the second device is bound to the first VM. In yet another aspect, the IOMMU is configured to perform the second DMA request in response to determining that the second DMA request targets a second region of memory within the region of memory allocated to the second VM. In yet another aspect, the designated security registration process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) registration process.

[0051] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s). The executable instructions stored on the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0052] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.

[0053] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

Claims

1. 1. A method comprising: In response to receiving a first direct memory access (DMA) request associated with a first virtual machine (VM) from a first device, identifying whether the first VM is bound to the first device by a designated security registration process; and preventing execution of the first DMA request in response to identifying, in an input / output memory management unit (IOMMU) of the processor, that the first device is not bound to the first VM. method.

2. In response to receiving a second DMA request associated with the first VM from a second device, identifying whether the first VM is bound to the second device by the specified security registration process; and performing the second DMA request in response to identifying, in the IOMMU, that the second device is bound to the first VM.

10. The method of claim 1.

3. In response to receiving the first DMA request, in response to determining that the first DMA request is for a first region of memory outside a region of memory allocated to the first VM, preventing execution of the first DMA request.

10. The method of claim 1.

4. determining the region of memory allocated to the first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses; The method of claim 3.

5. identifying an encryption key associated with the first VM based on the mapping table. The method of claim 4.

6. generating said mapping table in a security co-processor; The method of claim 4.

7. the designated security enrollment process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) enrollment process; The method of any one of claims 1 to 6.

8. 1. A method comprising: In response to receiving a first direct memory access (DMA) request associated with a first virtual machine (VM) from a first device, identifying whether the first DMA request targets a region of memory allocated to the first VM; and preventing execution of the first DMA request in response to identifying, in an input / output memory management unit (IOMMU), that the first DMA request is directed to a portion of memory outside the region of memory allocated to the first VM. method.

9. In response to receiving a second DMA request from a second device associated with the first VM, identifying whether the second DMA request targets a region of the memory allocated to the first VM; and executing the second DMA request in response to identifying, in the IOMMU, that the second DMA request targets the region of the memory allocated to the first VM.

9. The method of claim 8.

10. In response to receiving the first DMA request, in response to determining that the first VM is not bound to the first device by a designated security registration process, preventing execution of the first DMA request.

10. The method of claim 9.

11. executing, in a security co-processor of a processor configured to execute the first VM, the security registration process for the first VM; The method of claim 10.

12. determining the region of memory allocated to the first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses; 9. The method of claim 8.

13. In response to receiving a second DMA request associated with a second virtual machine (VM) from a second device, identifying whether the second DMA request targets a region of memory allocated to the second VM; and preventing execution of the second DMA request in response to identifying, in the IOMMU, that the second DMA request is for a portion of memory outside the region of memory allocated to the second VM. The method of any one of claims 8 to 12.

14. 1. A processor, comprising: an input / output memory management unit (IOMMU); The IOMMU is In response to receiving a first direct memory access (DMA) request associated with a first virtual machine (VM) from a first device, identifying whether the first VM is bound to the first device by a designated security registration process; responsive to identifying the first device as not bound to the first VM, preventing performance of the first DMA request; configured to: Processor.

15. The IOMMU is In response to receiving a second DMA request associated with the first VM from a second device, identifying whether the first VM is bound to the second device by the specified security registration process; performing the second DMA request in response to identifying the second device as bound to the first VM; and configured to: The processor of claim 14.

16. The IOMMU is configured, in response to receiving the first DMA request, to determine that the first DMA request is for a first region of memory outside a region of memory allocated to the first VM, to prevent execution of the first DMA request. The processor of claim 14.

17. The IOMMU is configured to determine the region of memory allocated to the first VM based on a mapping table that maps virtual addresses associated with the first VM to physical addresses.

17. The processor of claim 16.

18. The IOMMU is In response to receiving a second DMA request associated with a second virtual machine (VM) from a second device, identifying whether the second VM is bound to the second device by the specified security registration process; performing the second DMA request in response to identifying the second device as bound to the first VM; and configured to: The processor of claim 14.

19. The IOMMU is and configured to perform the second DMA request in response to determining that the second DMA request is for a second region of memory within the region of memory allocated to the second VM.

20. The processor of claim 18.

20. the designated security enrollment process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) enrollment process; The processor of any one of claims 14 to 19.

Images