104), when executing one or more VMs 106, generate MMIO requests (e.g., MMIO request 122) on behalf of the VMs 106 to read data from I/O devices (e.g., I/O device 120), write data to I/O devices, or both. Further, in some embodiments, I/O devices (e.g., I/O device 120) are configured to generate MMIO requests (e.g., MMIO request 122) on behalf of the VMs 106 to read data from other I/O devices, write data to other I/O devices, or both. According to embodiments, each MMIO request 122 includes a descriptor indicating the memory addresses (e.g., physical memory addresses, virtual memory addresses) of a register or other storage location of the I/O device to be accessed. For example, the memory address of a register or other storage location from which data is to be read, the memory address of a register or other storage location where data is to be written, or both. Additionally, one or more I/O devices (e.g., I/O device 120) associated with one or more VMs 106, generate DMA requests (e.g., DMA request 123) on behalf of the VMs 106 to read data from memory 116, write data to memory 116, or both. According to embodiments, each DMA request 123 includes a descriptor indicating the virtual addresses of a register or other storage location of memory 116 to be accessed. IOMMU 112 is generally configured to translate the virtual addresses indicated by a DMA request 123 to physical addresses of the registers or other storage locations, and to interact with the I/O devices to carry out the one or more operations (read operations, write operations, or both) indicated by DMA request 123. Further, a memory management unit (MMU) (not shown for clarity) of processor 102 is configured to translate the virtual addresses indicated by a MMIO request 122 to physical addresses of the registers or other storage locations.

Because MMIO requests 122 and DMA requests 123 are, at least in some cases, executed independently of the operations of processor 102, MMIO requests 122 and DMA requests 123 provide an avenue for a malicious entity to access confidential information associated with VMs executing at processor 102. For example, regarding DMA requests 123, a malicious hypervisor could be configured to cause portions of DMA requests 123 issued on behalf of one or more VMs to fail by changing page table mappings (e.g., in nested page tables 125) related to the DMA requests 123 such that data requested in the DMA request 123 is selectively rerouted to an incorrect address (e.g., an address other than the address intended by the DMA request 123). As an example, if a VM 106 issues a DMA request 123 indicating a DMA transfer, the malicious hypervisor changes page tables in nested page tables 125 associated with the virtual address indicated in the DMA request 123 (e.g., the target address for the DMA transfer). IOMMU 112 then translates the virtual address indicated in the DMA request 123 based on the changed page table mapping such that the requested data is rerouted to a changed address (e.g., an address other than the intended address). Such behaviors by a malicious hypervisor are used to potentially identify confidential information associated with VM 106. As another example, regarding MMIO requests 122, a malicious hypervisor is configured to modify page table mappings in, for example, nested page tables 125 to block one or more MMIO requests 122. To this end, the malicious hypervisor is configured to unmap one or more I/O buffers relating to an MMIO request 122 while still allowing data indicating the completion of the MMIO request 122 (e.g., a completion write flag, write-to-buffer completion flag) to be written. The data indicating the completion of the MMIO request indicates to the VM 106 associated with the MMIO request 122 that the MMIO request 122 was completed even though the I/O buffers were unmapped and the MMIO request 122 was not actually completed. As such, the VM 106 associated with the MMIO request 122 reads stale data from the I/O buffers rather than the intended data (e.g., the data indicated in the MMIO request 122), potentially exposing such data to unwanted entities such as the malicious hypervisor, malicious VMs, or both. In this way, the malicious hypervisor blocks MMIO requests 122 associated with one or more VMs 106 by unmapping the I/O buffers associated with the MMIO request 122.

To address these potential vulnerabilities, IOMMU 112 maintains ASID mask table 114 that indicates, for each VM 106, one or more ASIDs associated with (e.g., allocated to) the VM 106. That is to say, to address potential vulnerabilities, processing system 100 includes ASID mask table 114 stored in, for example, memory 116, that is maintained by IOMMU 112. The ASID mask table 114 includes one or more entries each associated with an ASID assigned to a respective VM 106. Each entry, for example, includes a field identifying an ASID assigned to a respective VM and a security indicator field associated with the ASID. The security indicator field includes, for example, data (e.g., a number of bits) indicating whether a VM 106 associated with the ASID was a target of an attack by, for example, a malicious hypervisor, whether MMIO requests 122 associated with the VM 106 are to be allowed, whether DMA requests 123 associated with the VM 106 are to be allowed, or any combination thereof. For example, the security indicator field includes a first bit indicating whether MMIO requests 122 associated with the VM 106 are to be allowed and a second bit indicating whether DMA requests 123 associated with the VM 106 are to be allowed. To set such data in a security indicator field, IOMMU 112 first detects a transfer failure (e.g., page fault). For example, in response to a malicious hypervisor changing the page table mapping in nested pages tables 125 for a virtual address associated with a DMA request 123 provided to IOMMU 112, a block of data will be misdirected to the changed address. Due to such a misdirection, a transfer failure (e.g., page fault) will occur as the data was not transferred to the correct address (e.g., originally indicated address). As another example, in response to a malicious hypervisor changing page table mappings in nested page tables 125 to unmap one or more I/O buffers associated with a MMIO request 122 while still allowing data (e.g., completion flag) indicating the MMIO request 122 was completed, the MMIO request 122 is blocked and the VM 106 associated with the MMIO request 122 will read stale data from the I/O buffers as no data was written to them. Because the MMIO request 122 was blocked, a transfer failure (e.g., page fault) will occur due to the I/O buffers being unmapped and stale data being read.

In response to such transfer failures due to an MMIO of DMA request, IOMMU 112 determines (e.g., based on a descriptor included with the MMIO request or DMA request, a mapping of VMs 106 to memory address spaces, a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both) the VM 106 that is associated with the MMIO or DMA request (e.g., the VM that initiated the MMIO or DMA request or the VM 106 that is the target of data indicated in the MMIO or DMA request). For example, in some embodiments, memory 116 includes a mapping table indicating sets of assigned memory addresses to VMs 106 (e.g., VM identifiers) as disclosed in the commonly owned and related U.S. Patent Application entitled “SECURE MEMORY-MAPPED INPUT/OUTPUT” and filed on the same day as the present application, the relevant portions of which pertaining to the mapping table being incorporated by reference herein. Using such a mapping table, IOMMU 112 is configured to determine a VM 106 associated with an MMIO or DMA request based on the memory addresses indicated in the MMIO or DMA request. After determining the VM 106 that is associated with the MMIO or DMA request, IOMMU 112 updates the security indicator field associated with the ASID assigned to the VM 106 in ASID mask table 114. For example, IOMMU 112 sets one or more bits in a security indicator field associated with the ASID such that the security indicators indicate that the VM 106 was a target of an attack, MMIO requests 122 associated with the VM 106 are not to be performed, DMA requests 123 associated with the VM 106 are not to be performed, or any combination thereof. That is to say, IOMMU 112 sets bits in the security indicator field associated with the ASID such that the security indicator field indicates that a transfer failure caused by an MMIO or DMA request associated with the VM 106 occurred, MMIO requests 122 associated with the VM 106 are not to be performed, DMA requests 123 associated with the VM 106 are not to be performed, or any combination thereof.

Further, IOMMU 112 is configured to perform (e.g., execute) received MMIO requests and DMA requests based on ASID masking table 114. For example, in response to receiving an MMIO request or DMA request, IOMMU 112 is configured to determine the VM 106 that is associated with the MMIO or DMA request (e.g., the VM that initiated the MMIO or DMA request or the VM 106 that is the target of data indicated in the MMIO or DMA request). As an example, using a mapping table indicating sets of assigned memory addresses to VMs 106, IOMMU 112 is configured to determine a VM 106 associated with an MMIO or DMA request based on the memory addresses indicated in the MMIO or DMA request. After determining the VM 106 associated with the MMIO or DMA request, IOMMU 112 then checks ASID mask table 114. For example, IOMMU 112 checks one or more bits of a security indicator field associated with the ASID assigned to the VM 106 in ASID mask table 114. In response to one or more bits of a security indicator field associated with the ASID assigned to the VM 106 indicating MMIO requests 122 are not to be performed, DMA requests 123 are not to be performed, or both, IOMMU 112 denies the received MMIO or DMA request, respectively, and does not execute the MMIO or DMA request (e.g., does not translate the addresses indicated in a DMA request, does not write data indicating the completion of an MMIO or DMA request). Further, in response to bits of a security indicator field associated with an ASID assigned to the VM 106 indicating MMIO requests 122 are to be performed, DMA requests 123 are to be performed, or both, IOMMU 112 performs (e.g., executes) the received MMIO or DMA request, respectively. In this way, IOMMU 112 helps ensure that an MMIO or DMA request is only satisfied if the VM 106 associated with the MMIO or DMA request has not been attacked by a malicious hypervisor (e.g., no transfer failures were caused by MMIO or DMA requests associated with the VM 106). As such, IOMMU 112 helps prevent the malicious hypervisor and malicious VMs from accessing confidential VM information via an MMIO or DMA request.

FIG. 2 illustrates an example ASID mask table 200 used to manage MMIO requests, DMA requests, or both, in accordance with some embodiments. In the example embodiment, ASID mask table 200, similar to or the same as ASID mask table 114, includes a plurality of entries 222 with each entry 222 corresponding to a respective ASID (e.g., ASID assigned to a respective VM 106). For example, ASID mask table 200 includes a plurality of entries 222 with each entry corresponding to an ASID assigned to a respective VM 106 that is currently executing at processor 102, a VM 106 expected to be executed at processor 102 (e.g., a VM that has undergone a VM provisioning process at the processing system 100), or both, to name a couple. Though the example embodiment of FIG. 2 presents ASID mask table 200 as having four entries (e.g., 222-1, 222-2, 222-3, 222-N) representing an N number of entries 222, in other embodiments ASID mask table 200 may include any number of entries. As an example, ASID mask table 200 includes an entry 222 for each ASID assigned to a VM 106 that is currently executing at processor 102, each VM 106 expected to be executed at processor 102, or both.

In embodiments, each entry 222 of ASID mask table 200 includes a plurality of fields, for example, an ASID field 224, security indicator field 226, or both. An ASID field 224 indicates an ASID corresponding to the memory address spaces allocated to, for example, a VM 106 that is currently executing at processor 102, a VM 106 expected to be executed at processor 102, or both. For example, in preparation for processor 102 launching a VM 106, security circuitry 110 is configured to define a memory address space to allocate to the VM 106. Security circuitry 110 defines the memory address spaces based on, for example, memory 116, registers and other storage locations of I/O devices (e.g., I/O device 120), or both and assigns a respective ASID to the memory address space. Such an ASID, for example, includes a unique identifier for the memory address space. During a provisioning process of a VM 106, security circuitry 110 then allocates the defined memory address space to the respective VM 106. Security circuitry 110 then updates a table (e.g., a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both) such that a VM 106 is associated with the ASID of the memory address space allocated to the VM 106. In embodiments, such ASIDs assigned to respective VMs 106 are reflected in respective ASID fields 224.

According to embodiments, the security indicator field 226 of an entry 222 indicates whether the VM associated with the ASID identified in the ASID field 224 of the entry 222 was a target of an attack, whether DMA requests 123 associated with the ASID are to be performed, whether MMIO requests 122 associated with the ASID are to be performed, or any combination thereof. To this end, each security indicator field 226 includes one or more DMA control bits 228 and one or more MMIO control bits 230. Such DMA control bits 228, for example, indicate whether the VM 106 associated with the ASID in the ASID field 224 of the entry was the target of an attack, whether DMA requests 123 associated with the ASID (e.g., VM 106 assigned to the ASID) are to be performed, or both. MMIO control bits 230, for example, indicate whether the VM 106 associated with the ASID in the ASID field 224 of the entry was the target of an attack, whether MMIO requests 122 associated with the ASID (e.g., VM 106 assigned to the ASID) are to be performed, or both.

In embodiments, one or more bits of DMA control bits 228, MMIO control bits 230, or both are initialized to indicate that a corresponding VM was not a target of an attack, DMA requests 123 are to be performed, MMIO requests 122 are to be performed, or any combination thereof. According to embodiments, when, for example, a malicious hypervisor selectively reroutes, blocks, or both one or more MMIO requests 122, DMA requests 123, or both provided to IOMMU 112, one or more transfer failures (e.g., page faults) will occur. For example, in response to a malicious hypervisor changing the page mapping associated with a block of data indicated in a DMA request 123, IOMMU 112 translates virtual addresses based on the changed page table mapping to produce a changed address. As such, the block of data indicated in the DMA request 123 will be misdirected to the changed address and a transfer failure (e.g., page fault) will occur. As another example, in response to a malicious hypervisor changing a page table mapping to unmap one or more I/O buffers associated with an MMIO request 122 while still allowing data (e.g., a completion flag) indicating the MMIO request 122 was completed to be written, a VM 106 associated with the MMIO request 122 will read stale data from the I/O buffers. Due to the VM 106 reading stale data and the I/O buffers being unmapped, a transfer failure will occur. In response to determining a transfer failure has occurred, IOMMU 112 is configured to abort the MMIO or DMA request currently being performed, determine (e.g., based on a descriptor included with the received MMIO request 122 or DMA request 123, a mapping table indicating sets of assigned memory addresses to VMs 106, a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both, or any combination thereof) the VM that is associated with the MMIO or DMA request that caused the transfer failure (e.g., the VM that initiated the MMIO or DMA request or the VM that is the target of data indicated in the MMIO or DMA request), or both. IOMMU 112 then updates a security indicator field 226 in the entry 222 corresponding to the ASID allocated to the VM associated with the MMIO or DMA request that caused the transfer failure to indicate that the VM was a target of an attack, one or more MMIO requests are not to be performed, one or more DMA requests are not to be performed, or any combination thereof. For example, IOMMU 112 updates DMA control bits 228 to indicate one or more DMA requests 123 are not to be performed, MMIO control bits 230 to indicate one or more MMIO requests 122 are not to be performed, or both.

According to embodiments, IOMMU 112 is configured to update one or more DMA control bits 228 to indicate one or more types of DMA requests 123 are not to be performed. For example, IOMMU 112 is configured to update DMA control bits 228 to indicate that all DMA requests 123 (e.g., associated with the ASID identified in the entry 222) are to be blocked, DMA requests 123 (e.g., associated with the ASID identified in the entry 222) from a root complex of processing system 100 are to be blocked, DMA requests 123 (e.g., associated with the ASID identified in the entry 222) from one or more specific I/O devices (e.g., I/O device 120) are to be blocked, or any combination thereof. For example, based on one or more memory addresses identified by a DMA request 123 that causes a transfer failure, IOMMU 112 is configured to update DMA control bits 228 to indicate that all DMA requests 123 are to be blocked, DMA requests 123 from a root complex of processing system 100 are to be blocked, DMA requests 123 from one or more specific I/O devices (e.g., I/O device 120) are to be blocked, or any combination thereof. In embodiments, IOMMU 112 is configured to update one or more MMIO control bits 230 to indicate one or more types of MMIO requests 122 are not to be performed. For example, IOMMU 112 is configured to update MMIO control bits 230 to indicate that all MMIO requests 122 (e.g., associated with the ASID identified in the entry 222) are to be blocked, MMIO requests 122 (e.g., associated with the ASID identified in the entry 222) from one or more specific I/O devices (e.g., I/O device 120) are to be blocked, or both. For example, based on one or more memory addresses identified by an MMIO request 122 that causes a transfer failure, IOMMU 112 is configured to update MMIO control bits 230 to indicate that all MMIO requests 122 are to be blocked, MMIO requests 122 from one or more specific I/O devices (e.g., I/O device 120) are to be blocked, or both.

Referring now to FIG. 3, an example operation 300 for setting MMIO control bits 230 in a security indicator field 226 is presented, in accordance with some embodiments. In embodiments, example operation 300 includes a processor core 104 or I/O device 120 issuing an MMIO request 305, similar to or the same as MMIO request 122, to IOMMU 112. MMIO request 305, for example, includes data indicating a request, from a VM, to read data from I/O devices (e.g., I/O device 120), write data to I/O devices, or both. In response to receiving MMIO request 305, IOMMU 112 checks one or more MMIO control bits 310, similar to or the same as MMIO control bits 230, from respective entries 222 in ASID mask table 200. For example, IOMMU 112 checks one or more MMIO control bits 310 in a security indicator field 226 in an entry 222 of ASID mask table 200 corresponding to the ASID (e.g., the ASID identified in the corresponding ASID field 224) allocated to the VM that issued the MMIO request 305, the VM that is a target of the MMIO request 305, or both. In response to the MMIO control bits 310 indicating that a corresponding VM was a target of an attack, that all MMIO requests associated with the ASID (e.g., the VM assigned to the ASID) are not to be performed, one or more types of MMIO requests (e.g., MMIO requests from certain I/O devices 120) associated with the ASID are not to be performed, or any combination thereof, IOMMU 112 denies the MMIO request 305 by, for example, not writing data (e.g., a completion flag) indicating the MMIO request 305 was completed. Additionally, in response to the MMIO control bits 310 indicating that a corresponding VM was not a target of an attack, that all MMIO requests associated with the ASID (e.g., the VM assigned to the ASID) are to be performed, one or more types of MMIO requests (e.g., MMIO requests from certain I/O devices 120) associated with the ASID are to be performed, or any combination thereof, IOMMU 112 completes the MMIO request 305.

In embodiments, the processing system issuing MMIO request 305 includes a malicious hypervisor. In such embodiments, the malicious hypervisor changes the page table mapping (e.g., changes page tables in nested page tables 125) associated with the I/O buffers associated with the MMIO request 305 provided to IOMMU 112. For example, the malicious hypervisor changes the page table mapping to unmap the I/O buffers while still allowing data (e.g., a completion flag) indicating the MMIO request 305 was completed to be written. Because the I/O buffers were unmapped, the MMIO request 305 is blocked and the VM associated with the MMIO request 305 reads stale data from the I/O buffers, causing a transfer failure to occur. In response to such a transfer failure, IOMMU 112 determines (e.g., based on a descriptor included with the MMIO request 305, a mapping of VMs 106 to memory address spaces, a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both, or any combination thereof) the VM that is associated with MMIO request 305 (e.g., the VM that initiated MMIO request 305 or the VM that is the target of data indicated in MMIO request 305). In response to determining the VM associated with MMIO request 305, IOMMU 112 performs update MMIO control bits operation 315. Update MMIO control bits operation 315, for example, first includes IOMMU 112 aborting the current MMIO request (e.g., MMIO request 305) or DMA request being performed by IOMMU 112. Next, update MMIO control bits operation 315 includes IOMMU 112 updating the MMIO control bits 310 in entries 222 of ASID mask table 200 corresponding to the determined VM (e.g., the ASID associated with the VM identified in the ASID field 224 of the corresponding entry 222) to indicate that the determined VM was a target of an attack, all MMIO requests associated with the ASID (e.g., the ASID assigned to the VM) are not to be performed, one or more types of MMIO requests (e.g., MMIO requests from certain I/O devices) associated with the ASID are not to be performed, or any combination thereof. For example, IOMMU 112 updates one or more bits of MMIO control bits 310 to indicate that all MMIO requests associated with the determined VM (e.g., the ASID assigned to the VM) are not to be performed. As another example, IOMMU 112 is configured to determine a type of the MMIO request 305 based on one or more memory addresses indicated in MMIO request 305. For example, IOMMU 112 determines which I/O device the MMIO request 305 is from. In response to determining which I/O device the MMIO request is from, IOMMU 112 updates one or more bits of MMIO control bits 310 to indicate that MMIO requests from the determined I/O device associated with a respective VM (e.g., the ASID allocated to the VM) are not to be performed.

Referring now to FIG. 4, an example operation 400 for setting DMA control bits in a security indicator field 226 is presented, in accordance with some embodiments. In embodiments, example operation 400 includes an I/O device 120 issuing a DMA request 405, similar to or the same as DMA request 123, to IOMMU 112. DMA request 405, for example, includes data indicating a request, from a VM, to read data from a memory (e.g., memory 116) of processing system 100, write data to a memory (e.g., memory 116) of processing system 100, or both. In response to receiving DMA request 405, IOMMU 112 checks one or more DMA control bits 410, similar to or the same as DMA control bits 228, from respective entries 222 in ASID mask table 200. For example, IOMMU 112 checks one or more DMA control bits 410 in a security indicator field 226 in an entry 222 of ASID mask table 200 corresponding to the ASID (e.g., the ASID identified in the corresponding ASID field 224) allocated to the VM that issued the DMA request 405, the VM that is a target of the DMA request 405, or both. In response to the DMA control bits 410 indicating that a corresponding VM was a target of an attack, that all DMA requests associated with the ASID (e.g., the VM assigned to the ASID) are not to be performed, one or more types of DMA requests (e.g., DMA requests from a root complex of processing system 100, DMA requests from certain I/O devices 120) associated with the ASID are not to be performed, or any combination thereof, IOMMU 112 denies the DMA request 405 by, for example, not translating the virtual memory addresses indicated in DMA request 405. Additionally, in response to the DMA control bits 410 indicating that a corresponding VM was not a target of an attack, that all DMA requests associated with the ASID (e.g., the VM assigned to the ASID) are to be performed, one or more types of DMA requests (e.g., DMA requests from a root complex of processing system 100, DMA requests from certain I/O devices 120) associated with the ASID are to be performed, or any combination thereof, IOMMU 112 completes the DMA request 405.

According to embodiments, the processing system issuing DMA request 405 includes a malicious hypervisor. In such embodiments, the malicious hypervisor changes the page table mapping (e.g., changes page tables in nested page tables 125) associated with the data blocks (e.g., virtual memory addresses) indicated in DMA request 405 provided to IOMMU 112. For example, the malicious hypervisor changes the page table mapping to selectively reroute data blocks indicated in DMA request 405 to one or more changed memory addresses (e.g., memory addresses modified from the memory addresses indicated in DMA request 405). Because the data blocks were redirected to the changed memory addresses, a transfer failure (e.g., page fault) occurs. In response to such a transfer failure caused by DMA request 405, IOMMU 112 determines which VM being executed by processing system 100 is associated with DMA request 405. That is to say, IOMMU 112 determines the VM that initiated DMA request 405 or the VM that is the target of data indicated in DMA request 405. In embodiments, IOMMU 112 is configured to determine which VM is associated with DMA request 405 based on, for example, a descriptor included with the DMA request 405, a mapping of VMs 106 to memory address spaces, a memory ownership table mapping VMs to ASIDs, a memory ownership table mapping ASIDs to memory address spaces, or any combination thereof. After determining which VM is associated with DMA request 405, IOMMU 112 performs update DMA control bits operation 415. Update DMA control bits operation 415, for example, first includes IOMMU 112 aborting the current MMIO request or DMA request (e.g., DMA request 405) being performed by IOMMU 112. Next, update DMA control bits operation 415 includes IOMMU 112 updating the DMA control bits 410 in entries 222 of ASID mask table 200 corresponding to the determined VM (e.g., the ASID associated with the VM identifying in the ASID field 224 of the corresponding entry 222) to indicate that the determined VM was a target of an attack, all DMA requests associated with the ASID (e.g., the ASID assigned to the VM) are not to be performed, one or more types of DMA requests (e.g., DMA requests from a root complex of processing system 100, DMA requests from certain I/O devices) associated with the ASID are not to be performed, or any combination thereof. For example, IOMMU 112 updates one or more bits of DMA control bits 410 to indicate that all DMA requests associated with the determined VM (e.g., the ASID assigned to the VM) are not to be performed. As another example, IOMMU 112 is configured to determine a type of DMA request 405 based on one or more memory addresses indicated in DMA request 405. For example, IOMMU 112 determines which I/O device the DMA request 405 is from or if the DMA request 405 is from a root complex of processing system 100. In response to determining which I/O device the DMA request is from, IOMMU 112 updates one or more bits of DMA control bits 410 to indicate that DMA requests from the determined I/O device associated with a respective VM (e.g., the ASID allocated to the VM) are not to be performed. Similarly, in response to determining that the DMA request is from a root complex of processing system 100, IOMMU 112 updates one or more bits of DMA control bits 410 to indicate that DMA requests from the root complex of processing system 100 associated with a respective VM (e.g., the ASID allocated to the VM) are not to be performed.

As noted above, ASID mask table 200 stores individual entries for each ASID of VMs that are executing at the processor 102. This allows the IOMMU 112 to allow or deny MMIO requests for different VMs on an individual basis, independent of the MMIO requests for other VMs. An example embodiment is illustrated at FIG. 5. In the example embodiment of FIG. 5, it is assumed that processor 102 is executing two different VMs: VM 106-1 and VM 106-2. The IOMMU 112 receives MMIO request 122 from processor core 104, indicating a request to access a register or other storage location of an I/O device on behalf of VM 106-1. It is further assumed that ASID mask table 200 includes one or more MMIO control bits 230 (e.g., in a security indicator field 226 associated with an ASID that is associated with VM 106-1) indicating that VM 106-1 was a target of an attack (e.g., was associated with an MMIO request that caused a transfer failure), all MMIO requests associated with VM 106-1 are not to be performed, one or more types of MMIO requests (e.g., MMIO requests from certain I/O devices) associated with VM 106-1 are not to be allowed, or any combination thereof. Accordingly, based on MMIO control bits 230, the IOMMU 112 prevents execution of MMIO request 122 (e.g., by not writing data indicating MMIO request 122 was completed) and indicates to processor core 104 (via message 515) that MMIO request 122 has been denied.

With respect to MMIO request 505, it is assumed that the ASID mask table 200 includes one or more bits of MMIO control bits 230 (e.g., in a security indicator field 226 associated with an ASID that is associated with VM 106-2) indicating that VM 106-2 was not the target of an attack (e.g., is not associated with an MMIO that caused a transfer failure), all MMIO requests associated with VM 106-2 are to be performed, one or more types of MMIO requests (e.g., MMIO requests from certain I/O devices) associated with VM 106-2 are to be performed, or any combination thereof. Accordingly, based on MMIO control bits 230, IOMMU 112 determines that MMIO request 505 is allowed (as indicated by message 510 to processor core 104), and therefore executes MMIO request 505. Thus, in the example of FIG. 5, IOMMU 112 selectively allows some MMIO requests and denies others based on previous attacks on VMs by, for example, a malicious hypervisor. As such, the malicious hypervisor, a malicious VM, or both are prevented from accessing confidential information of the VMs running on processing system 100 due to, for example, a malicious hypervisor changing page table mappings to unmap I/O buffers associated with MMIO requests.

Similarly, an example embodiment is illustrated at FIG. 6. In the example embodiment of FIG. 6, it is assumed that processor 102 is executing two different VMs: VM 106-1 and VM 106-2. The IOMMU 112 receives DMA request 123 from I/O device 120, indicating a request to access memory 116 on behalf of VM 106-1. It is further assumed that ASID mask table 200 includes one or more DMA control bits 228 (e.g., in a security indicator field 226 associated with an ASID that is associated with VM 106-1) indicating that VM 106-1 was a target of an attack (e.g., was associated with a DMA request that caused a transfer failure), all DMA requests associated with VM 106-1 are not to be performed, one or more types of DMA requests (e.g., DMA requests from a root complex of processing system 100, DMA requests from certain I/O devices) associated with VM 106-1 are not to be performed, or any combination thereof. Accordingly, based on DMA control bits 228, the IOMMU 112 prevents execution of DMA request 123 (e.g., by not translating the virtual address indicted in DMA request 123) and indicates to I/O device 120 (via message 615) that DMA request 123 has been denied.

With respect to DMA request 605, it is assumed that the ASID mask table 200 includes one or more bits of DMA control bits 228 (e.g., in a security indicator field 226 associated with an ASID that is associated with VM 106-2) indicating that VM 106-2 was not the target of an attack (e.g., is not associated with a DMA request that caused a transfer failure), all DMA requests associated with VM 106-2 are to be performed, one or more types of DMA requests (e.g., DMA requests from a root complex of processing system 100, DMA requests from certain I/O devices) associated with VM 106-2 are to be performed, or any combination thereof. Accordingly, based on DMA control bits 228, IOMMU 112 determines that DMA request 605 is allowed (as indicated by message 610 to I/O device 120), and therefore executes DMA request 605. Thus, in the example of FIG. 6, IOMMU 112 selectively allows some DMA requests and denies others based on previous attacks on VMs by, for example, a malicious hypervisor. As such, the malicious hypervisor, malicious VMs, or both are prevented from accessing confidential information of the VMs running on processing system 100 due to, for example, a malicious hypervisor changing page table mappings.

Referring now to FIG. 7, an example method 700 for managing secure MMIO and DMA access at an IMMOU is presented. For purposes of description, the method 700 is described with respect to an example implementation at the processing system 100 of FIG. 1, but it will be appreciated that in other embodiments the method 700 is implemented at processing systems having different configurations. At step 705, security circuitry 110 defines a memory address space to allocate to a VM based on, for example, memory 116, registers and other storage locations of I/O devices (e.g., I/O device 120), or both. For example, in preparation for processor 102 launching VM 106, security circuitry 110 defines a memory address space representing distinct virtualized portions (e.g., pages) of memory 116, registers and other storage locations of I/O devices (e.g., I/O device 120), or both. Further, security circuitry 110 assigns a respective ASID to the memory address space that includes a unique identifier for the memory address space. In response to security circuitry 110 allocating a memory address space to VM 106, security circuitry 110 associates VM 106 with the ASID of the memory address space allocated to the VM. For example, security circuitry 110 is configured to update a table (e.g., a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both) such that VM 106 is associated with the ASID of the memory address space allocated to VM 106.

At step 710, IOMMU 112 receives MMIO request 122 from, for example, processor core 104 or I/O device 120, DMA request 123 from, for example, I/O device 120, or both. MMIO request 122 and DMA request 123 each include data indicating the virtual memory addresses targeted by the request. At step 715, IOMMU 112 determines the VM associated with MMIO request 122 or DMA request 123 (e.g., based on a descriptor included with the DMA request