Address space identifier-based security for data transfer requests

Abstract

A processor [102] configured to execute one or more virtual machines (VMs) [106] includes an input / output memory management unit (IOMMU) [112] configured to process memory-mapped input / output (MMIO) requests [122] and direct memory access (DMA) requests [123] from processor cores [104] of the processor or one or more input / output (I / O) devices. In response to receiving an MMIO request or a DMA request, the IOMMU is configured to determine the VM associated with the request. The IOMMU then checks a security indicator field in an address space identifier (ASID) mask table [114] to determine whether the VM has previously been the target of an attack by a malicious entity. In response to the VM having been the target of an attack, the IOMMU denies the received MMIO request or DMA request.

Description

[Background technology]

[0001] In a confidential computing environment, a processing system (e.g., a server) runs multiple software programs, such as virtual machines (VMs) and virtual machine managers (e.g., hypervisors), owned by different entities. As an example, some confidential computing environments include multiple VMs running within the environment, each owned by a different company. To control such VMs within the confidential computing environment, the confidential computing environment includes a virtual machine manager (e.g., hypervisor) that controls the scheduling of the different VMs for execution and provides an interface between the VMs and the server hardware. For example, the virtual machine manager controls the scheduling of the different VMs so that each VM operates as if it were running on its own dedicated hardware. However, if the virtual machine manager (e.g., hypervisor) is a malicious actor, confidential information of the VMs is at risk of being exposed to unauthorized entities. For example, a malicious virtual machine manager could change the mapping of a page table associated with a VM so that requested data is redirected to a different address or a memory request is blocked, potentially exposing such data to the malicious virtual machine manager or other entities and compromising the security of the confidential computing environment.

[0002] 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]

[0003] [Figure 1]1 is a block diagram of a processing system employing an input-output memory management unit (IOMMU) to manage memory-mapped input / output (MMIO) and direct memory access (DMA) requests based on a security indicator field, according to some embodiments. [Figure 2] FIG. 1 is a block diagram of an exemplary address space identifier (ASID) mask table used to manage MMIO requests, DMA requests, or both based on a security indicator field, in accordance with some embodiments. [Figure 3] FIG. 10 is a signal flow diagram of an example operation for setting MMIO control bits in a security indicator field, according to some embodiments. [Figure 4] FIG. 10 is a signal flow diagram of an example operation for setting DMA control bits in a security indicator field according to some embodiments. [Figure 5] 2 is a block diagram illustrating an example of the IOMMU of FIG. 1 managing MMIO requests for multiple virtual machines based on one or more security indicator fields, according to some embodiments. [Figure 6] 2 is a block diagram illustrating the example IMMOU of FIG. 1 managing DMA requests for multiple virtual machines based on one or more security indicator fields, according to some embodiments. [Figure 7] FIG. 1 is a flow diagram illustrating an example method for managing MMIO access, DMA requests, or both for multiple virtual machines based on one or more security indicator fields, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] In a processing system, multiple virtual machines (VMs) are executed by one or more processors of the processing system. To facilitate execution of the VMs, the processing system (e.g., security circuitry of the processing system) assigns one or more respective memory address spaces to each of the VMs. Such memory address spaces may include virtualized memory portions (e.g., pages) of physical memory within the processing system, physical memory of one or more I / O devices, or both. Furthermore, the memory address space assigned to a VM is associated with an address space identifier (ASID) that includes a unique identifier for the assigned memory address space. Additionally, to facilitate execution of the VMs, the processor of the processing system may include or otherwise be connected to a hypervisor configured to control scheduling of different VMs for execution, provide an interface between the VMs and hardware (e.g., I / O devices) of the processing system, manage page table mappings used to translate virtual addresses in the memory address space to physical addresses, or both.

[0005] When executing a VM, one or more processors of the processing system each include a processor core that accesses memory of an I / O device of the processing system by issuing memory-mapped I / O (MMIO) requests. Additionally, in some embodiments, when executing a VM, one or more I / O devices of the processing system access memory of other I / O devices by issuing MMIO requests (e.g., peer-to-peer requests). Each MMIO request includes data that identifies, for example, a memory address (e.g., a virtual memory address) of the I / O device from which data is read, a memory address (e.g., a virtual memory address) of the I / O device to which data is written, or both. For example, a processor core programs a particular register of an I / O device by issuing an MMIO request to write data to a memory address (e.g., a virtual memory address) associated with the register. By providing information to or retrieving information from the I / O device using a memory address, the processor core interacts with the I / O device using a relatively simple set of access commands and by leveraging at least some of the hardware used to access system memory. Thus, the overall efficiency of the processor core is improved. Furthermore, when executing a VM, one or more I / O devices of the processing system are configured to access memory (e.g., system memory) of the processing system by issuing one or more direct memory access (DMA) requests, such DMA requests including, for example, data identifying a memory address (e.g., a virtual memory address) in memory from which data is to be read, a memory address in memory to which data is to be written, or both.

[0006] To further improve processing efficiency, an input / output memory management unit (IOMMU) of a processing system assists in translating DMA requests by translating virtual addresses to system physical addresses, rather than having a memory controller or central processing unit (CPU) perform such translation of memory addresses for DMA requests. In addition, the IOMMU is configured to process (e.g., fulfill) one or more MMIO requests issued from a processor core or an I / O device. However, in at least some cases, one or more issued MMIO requests, DMA requests, or both, make secure data of the processing system vulnerable to unauthorized access or modification. For example, within a processing system, a hypervisor is configured to maintain page table mappings (e.g., nested page tables that map virtual addresses in VM memory to physical memory addresses) used to translate virtual addresses to system physical addresses. In embodiments, a malicious hypervisor can modify, manipulate, or both, the page table mappings for virtual addresses to selectively misroute, block, or both, MMIO requests, DMA requests, or both provided to the IOMMU. For example, with respect to a DMA request, a malicious hypervisor may be configured to modify a page table mapping for a virtual address identified in a DMA request provided to the IOMMU. The IOMMU may then use the modified mapping to translate the virtual address identified in the DMA request, which may cause the data identified in the DMA request to be rerouted to the modified memory address rather than the intended (e.g., initial) memory address indicated in the DMA request, or may cause the VM associated with the DMA request to read incorrect or stale data from the modified memory address, or both.Thus, data requested by a DMA request for a VM may be subject to unauthorized access or modification by unwanted entities, such as a malicious hypervisor, a malicious VM, or both. With respect to an MMIO request, the malicious hypervisor is configured to modify page table mappings to unmap one or more I / O buffers associated with the MMIO request while still allowing data indicating completion of the MMIO request (e.g., a write completion flag, a buffer write completion flag) to be written. The data indicating completion of the MMIO request indicates to a VM associated with the MMIO request that the MMIO request has completed, even though the I / O buffers have been unmapped and the MMIO request has not actually completed. Thus, the VM associated with the MMIO request reads stale data from the I / O buffers rather than the intended data (e.g., data indicated in the MMIO request), potentially exposing such data to unwanted entities, such as a malicious hypervisor, a malicious VM, or both. In this manner, the malicious hypervisor blocks the MMIO request associated with the VM by unmapping the I / O buffers associated with the MMIO request.

[0007] To prevent these and similar attacks, a processing system using the techniques described herein employs an IOMMU to ensure that one or more VMs associated with MMIO requests, DMA requests, or both have not previously been the target of such attacks. For example, in some embodiments, the IOMMU maintains an ASID mask table (e.g., stored in memory) that includes several entries, each associated with a respective ASID. These entries identify, for example, the ASIDs of memory address space allocated to VMs (e.g., to one or more processes in the VM) running on the processing system. According to an embodiment, each entry in the ASID mask table further identifies a security indicator field for each ASID. Such security indicator field for each ASID includes, for example, data (e.g., bits) that indicate whether the MMIO requests associated with the ASID should be performed, whether the DMA requests associated with the ASID should be performed, or both. For example, in some embodiments, a malicious hypervisor alters page table mappings to selectively misroute or block MMIO or DMA requests provided to the IOMMU. For DMA requests, the changed page table mapping causes the IOMMU to translate the virtual address in the DMA request, resulting in the misrouting of the block of data indicated in the DMA request to the changed address (e.g., due to the changed mapping) rather than the intended (e.g., initial) address. Thus, the misrouting of the block of data to the changed address in the DMA request causes a transfer failure (e.g., a page fault) because the block of data was not directed to the intended address. Furthermore, for MMIO requests, the changed page table mapping causes one or more I / O buffers associated with the MMIO request to be unmapped while still allowing data indicating completion of the MMIO request (e.g., write completion flag, buffer write completion flag) to be written.In response to such data indicating completion of the MMIO request, the VM associated with the MMIO request reads stale data from the I / O buffer because the MMIO request was blocked due to the I / O buffer being unmapped. A transfer failure (e.g., a page fault) occurs because the I / O buffer is unmapped and the VM reads stale (e.g., incorrect) data from the I / O buffer.

[0008] In response to such a transfer failure, the IOMMU determines the MMIO request or DMA request that caused the transfer failure and the VM associated with the MMIO request or DMA request (e.g., the VM that issued the MMIO request or DMA request, the VM that was the target of the MMIO request or DMA request, or both). After determining the associated VM, the IOMMU sets one or more bits in a security indicator field associated with the ASID allocated to the determined VM in the ASID mask table to indicate that the VM was the target of the attack. For example, in response to determining that the VM associated with the MMIO request was the target of the attack, the IOMMU updates bits in a security indicator field associated with the ASID allocated to the VM to indicate that the MMIO request associated with the ASID (e.g., the VM) should not be performed. In another example, in response to determining that the VM associated with the DMA request was the target of the attack, the IOMMU updates bits in a security indicator field associated with the ASID allocated to the VM to indicate that the DMA request associated with the ASID (e.g., the VM) should not be performed.

[0009] After receiving an MMIO request from a processor core, an MMIO request from an I / O device, a DMA request from an I / O device, or any combination thereof, the IOMMU determines the VM associated with the request, for example, by using one or more tables that map virtual machine identifiers (VMIDs), ASIDs, or both to memory addresses identified in the received MMIO and DMA requests. The IOMMU then determines whether a security indicator field associated with the ASID allocated to the determined VM indicates whether the MMIO request, the DMA request, or both associated with the VM (e.g., the VM's ASID) are permitted (e.g., should be performed). For example, the IOMMU checks whether one or more bits of the security indicator field associated with the ASID in an ASID mask table indicate that the MMIO request, the DMA request, or both should be performed. In response to the security indicator field associated with the ASID indicating that the MMIO request, the DMA request, or both should not be performed (e.g., indicating that the VM associated with the MMIO request or the DMA request was the target of an attack), the IOMMU prevents the execution of the MMIO request or the DMA request as described herein, for example, by preventing virtual to physical address translation, not writing data indicating completion of the MMIO request or the DMA request, or both. In response to the security indicator field associated with the ASID indicating that the MMIO request, the DMA request, or both should be performed (e.g., that the VM associated with the MMIO request or the DMA request was not the target of an attack), the IOMMU performs the MMIO request of the DMA request. Thus, using the techniques described herein, the IOMMU prevents the execution of an MMIO request or a DMA request on behalf of a VM if the VM was previously the target of an attack, for example, by a malicious hypervisor. 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 malicious hypervisor to interfere with these operations, thus supporting secure MMIO and DMA access in confidential computing environments.

[0010] FIG. 1 illustrates a processing system 100 employing an input / output memory management unit (IOMMU) to manage memory-mapped input / output (MMIO) and direct memory access (DMA) requests based on a security indicator field, according to some embodiments. Processing system 100 is generally configured to execute a set of instructions (e.g., a computer program) to perform tasks on behalf of an electronic device. For example, in response to receiving a set of instructions, processing system 100 is configured to perform one or more operations indicated in the set of instructions. Accordingly, in different embodiments, processing system 100 is part of any of a variety of electronic devices. For purposes of explanation, it is assumed that processing system 100 is part of an electronic device implementing 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, or the like.

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

[0012] I / O device 120 includes any device configured to process input information, output information, or a combination thereof, on behalf of processing system 100, independent of processor 102. For example, in some embodiments, I / O device 120 is a network interface device that processes input and output information for a network (not shown) connected to processing system 100. In another example, I / O device 120 is a storage controller (e.g., a disk controller, an NVM storage controller), a controller associated with a user interface (e.g., a keyboard), etc., to name just a few.

[0013] To execute the instruction set and corresponding operations, processor 102 includes processor core 104, security circuitry 110, and IOMMU 112. It will be appreciated that in some embodiments, processor 102 includes additional hardware for executing instructions and performing operations based on those instructions, such as additional processor cores, additional processing units (e.g., one or more parallel processing units, vector processing units, scalar processing units), one or more controllers (e.g., memory controllers, input / output controllers), or any combination thereof, to name a few.

[0014] To execute a set of instructions, processor core 104 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 104 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, or any combination thereof, to name a few. According to embodiments, processor core 104 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 104 includes or has access to one or more cache structures for storing data used in the execution of instructions.

[0015] As described above, processing system 100 is generally configured to implement a confidential computing environment, and in particular to execute multiple virtual machines (VMs) (e.g., VM 106), also referred to as guests, and hypervisor 108, also referred to as a host, to manage the execution of the multiple VMs. While the exemplary embodiment shown in FIG. 1 presents processing system 100 executing three VMs (106-1, 106-2, 106-N) representing N VMs, in other embodiments, the processing system is configured to execute any number of VMs 106. In embodiments, because two or more VMs 106, and in at least some cases hypervisor 108, are owned by different entities, processing system 100 implements security features to protect data of a given VM 106 from access by another VM 106 or other software, such as hypervisor 108. For example, processing system 100 implements data security for VM 106 by implementing a secure region 118 of memory 116 that stores encrypted data. In particular, processor 102 is configured to encrypt each designated data for one or more VMs 106 according to a corresponding private encryption key and store the encrypted data in secure area 118. Because the data is encrypted, the data for a first VM 106 is protected from unauthorized access by one or more other VMs 106, hypervisor 108, or both. In at least some embodiments, encryption keys for VMs 106 are managed by security circuit 110, and data encryption and decryption for VMs 106 is performed by a dedicated hardware encryption / decryption module (not shown) in a memory controller (not shown) of processor 102.

[0016] To further help protect the confidential computing environment, processor 102 includes security circuitry 110, which may include hardware-based circuitry, software-based circuitry, or both, generally configured to create, monitor, and maintain a security environment for processor 102. For example, in at least some embodiments, security circuitry 110 is configured to manage the boot process for processor 102, initialize security-related mechanisms for processor 102, monitor processing system 100 for suspicious activity or events, implement appropriate responses, or any combination thereof. According to embodiments, security circuitry 110 may include, for example, a microcontroller, a cryptographic coprocessor (CCP) (e.g., configured to encrypt and decrypt data), local memory and local registers (e.g., configured to store cryptographic keys), memory 116, an I / O controller of processor 102, and an interface configured to interact with configuration registers (e.g., hardware registers) of processor 102, or any combination thereof. In an embodiment, security circuitry 110 includes, for example, environmental management control hardware that performs environmental and security checks to help ensure that processor 102 is operating in accordance with one or more specified security parameters.

[0017] According to an embodiment, the security circuit 110 is configured to define one or more memory address spaces within the processing system 100, e.g., based on memory 116, registers, and / or other storage locations of I / O devices (e.g., I / O device 120). For example, in preparation for the processor 102 to launch the VM 106, the security circuit 110 is configured to define one or more memory address spaces to be assigned to the VM 106. Each memory address space may represent, e.g., at least a virtualized portion (e.g., one or more pages) of the memory 116, registers and other storage locations of the I / O devices, or both. For example, the security circuit 110 is configured to define memory address spaces that represent a virtualized portion (e.g., a page) of the memory 116 and one or more registers of the I / O device 120. Additionally, the security circuit 110 is configured to assign a respective address space identifier (ASID) to each defined memory address space. For example, each such ASID includes data (e.g., several bits) that indicates a unique identifier for the respective memory address space of the system. According to an embodiment, security circuit 110 ensures that two or more VMs 106 are not allocated the same (or overlapping) memory address space. In this manner, each of multiple VMs 106 executed by processor 102 has access to memory 116, registers or other storage locations of I / O devices, or both. According to an embodiment, hypervisor 108 is configured to maintain a mapping of virtual memory addresses of the memory address space to physical memory addresses within memory 116, one or more I / O devices, or both. For example, hypervisor 108 maintains nested page tables 125, which include page tables that indicate the physical memory addresses of one or more virtual memory addresses. After allocating memory address space to a VM 106, security circuit 110 associates the VM 106 with the ASID of the memory address space allocated to the VM.For example, security circuit 110 is configured to update a table (e.g., a memory ownership table that maps VMs to ASIDs, ASIDs to memory address spaces, or both) so that VM 106 is associated with the ASID of the memory address space assigned to the VM.

[0018] To increase processing efficiency, IOMMU 112 is generally configured to perform specified memory access operations on behalf of processor 102, i.e., using hardware-based circuitry, software-based circuitry, or both, in IOMMU 112 to perform memory access operations without requiring management of the memory access operations by processor 102. In particular, IOMMU 112 includes hardware-based circuitry, software-based circuitry, or both configured to perform MMIO operations (e.g., satisfying MMIO requests), DMA operations (e.g., satisfying DMA requests), or both. In an embodiment, a processor core (e.g., processor core 104), when executing one or more VMs 106, generates MMIO requests (e.g., MMIO requests 122) on behalf of VMs 106 to read data from, write data to, or both of I / O devices (e.g., I / O device 120). Furthermore, in some embodiments, an I / O device (e.g., I / O device 120) is configured to generate MMIO requests (e.g., MMIO request 122) on behalf of VM 106 to read data from, write data to, or both of other I / O devices. According to an embodiment, each MMIO request 122 includes a descriptor indicating the memory address (e.g., physical memory address, virtual memory address) of a register or other memory location of the I / O device to be accessed. For example, the memory address of the register or other memory location from which data is read, the memory address of the register or other memory location to which data is 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 VM 106 to read data from, write data to, or both of memory 116. According to an embodiment, each DMA request 123 includes a descriptor indicating the virtual address of the register or other location in memory 116 to be accessed.IOMMU 112 is generally configured to translate virtual addresses indicated by DMA requests 123 into physical addresses of registers or other memory locations, and to interact with I / O devices to perform one or more operations (read operations, write operations, or both) indicated by DMA requests 123. Additionally, a memory management unit (MMU) (not shown for clarity) of processor 102 is configured to translate virtual addresses indicated by MMIO requests 122 into physical addresses of registers or other memory locations.

[0019] Because MMIO requests 122 and DMA requests 123, in at least some cases, execute independently of the operation of processor 102, MMIO requests 122 and DMA requests 123 provide a means for a malicious entity to access sensitive information associated with VMs executing on processor 102. For example, with respect to DMA requests 123, a malicious hypervisor may be configured to cause some of DMA requests 123 issued on behalf of one or more VMs to fail by altering page table mappings (e.g., in nested page tables 125) associated with DMA requests 123 such that data requested in DMA requests 123 is selectively rerouted to an incorrect address (e.g., an address other than that intended by DMA request 123). As an example, when VM 106 issues DMA request 123 indicating a DMA transfer, the malicious hypervisor alters the page table in nested page tables 125 associated with the virtual address indicated in DMA request 123 (e.g., the target address of the DMA transfer). IOMMU 112 then translates the virtual address indicated in DMA request 123 based on the altered page table mapping, such that the requested data is rerouted to the altered address (e.g., an address other than the intended address). Such behavior by a malicious hypervisor may be used to potentially identify sensitive information associated with VM 106. As another example, with respect to MMIO request 122, the malicious hypervisor is configured to block one or more MMIO requests 122, e.g., by altering page table mappings in nested page table 125. To do this, the malicious hypervisor is configured to unmap one or more I / O buffers associated with MMIO request 122 while still allowing data indicating completion of MMIO request 122 (e.g., write completion flag, write to buffer completion flag) to be written.The data indicating completion of the MMIO request indicates to the VM 106 associated with the MMIO request 122 that the MMIO request 122 has completed, even though the I / O buffer has been unmapped and the MMIO request 122 has not actually completed. Thus, the VM 106 associated with the MMIO request 122 reads stale data from the I / O buffer instead of the intended data (e.g., the data indicated in the MMIO request 122), potentially exposing such data to unwanted entities, such as a malicious hypervisor, a malicious VM, or both. In this manner, a malicious hypervisor blocks the MMIO requests 122 associated with one or more VMs 106 by unmapping the I / O buffer associated with the MMIO request 122.

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

[0021] In response to such a transfer failure due to the MMIO of the DMA request, the IOMMU 112 determines the VM 106 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 the data indicated in the MMIO or DMA request) (e.g., based on a descriptor included with the MMIO or DMA request, a memory ownership table that maps VMs 106 to memory address spaces, maps VMs to ASIDs, maps ASIDs to memory address spaces, or both). For example, in some embodiments, the memory 116 includes a mapping table that indicates the set of memory addresses (e.g., VM identifiers) allocated to VMs 106, as disclosed in commonly assigned U.S. patent application entitled "SECURE MEMORY-MAPPED INPUT / OUTPUT," filed on even date herewith, the relevant portions of which relating to the mapping table are incorporated herein by reference. Using such a mapping table, the IOMMU 112 is configured to determine the VM 106 associated with the MMIO or DMA request based on the memory address indicated in the MMIO or DMA request. After determining the VM 106 associated with the MMIO or DMA request, the IOMMU 112 updates the security indicator field associated with the ASID assigned to the VM 106 in the ASID mask table 114. For example, the IOMMU 112 sets one or more bits in the security indicator field associated with the ASID such that the security indicator indicates that the VM 106 was the target of an attack, that the MMIO request 122 associated with the VM 106 should not be performed, that the DMA request 123 associated with the VM 106 should not be performed, or any combination thereof.That is, 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 request or a DMA request associated with VM 106 has occurred, that MMIO request 122 associated with VM 106 should not be performed, that DMA request 123 associated with VM 106 should not be performed, or any combination thereof.

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

[0023] 2 illustrates an exemplary ASID mask table 200 used to manage MMIO requests, DMA requests, or both, according to some embodiments. In an exemplary embodiment, ASID mask table 200, similar to or identical to ASID mask table 114, includes multiple entries 222, each corresponding to a respective ASID (e.g., an ASID allocated to a respective VM 106). For example, ASID mask table 200 includes multiple entries 222, each corresponding to an ASID allocated to a respective VM 106 currently executing on processor 102, a VM 106 expected to execute on processor 102 (e.g., a VM that has undergone a VM provisioning process on processing system 100), or both, to name just a few. While the exemplary embodiment of FIG. 2 presents ASID mask table 200 as having four entries (e.g., 222-1, 222-2, 222-3, 222-N) representing N 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 allocated to a VM 106 currently executing on processor 102, each VM 106 expected to execute on processor 102, or both.

[0024] In an embodiment, each entry 222 in the ASID mask table 200 includes multiple fields, such as an ASID field 224, a security indicator field 226, or both. The ASID field 224 indicates, for example, an ASID corresponding to a memory address space allocated to a VM 106 currently executing on the processor 102, a VM 106 expected to execute on the processor 102, or both. For example, in preparation for the processor 102 to launch a VM 106, the security circuit 110 is configured to define the memory address space to be allocated to the VM 106. The security circuit 110 defines the memory address space based, for example, on registers and other memory locations of the memory 116, I / O devices (e.g., I / O devices 120), or both, and assigns each ASID to the memory address space. Such an ASID includes, for example, a unique identifier for the memory address space. During the provisioning process of the VM 106, the security circuit 110 then assigns the defined memory address space to each VM 106. Security circuit 110 is then configured to update a table (e.g., a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both) so that VMs 106 are associated with the ASIDs of the memory address spaces assigned to VMs 106. In an embodiment, such ASIDs allocated to each VM 106 are reflected in respective ASID fields 224.

[0025] According to an embodiment, 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 the target of an attack, whether the DMA request 123 associated with the ASID should be performed, whether the MMIO request 122 associated with the ASID should 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 indicate, for example, whether the VM 106 associated with the ASID in the entry's ASID field 224 was the target of an attack, whether the DMA request 123 associated with the ASID (e.g., the VM 106 allocated to the ASID) should be performed, or both. The MMIO control bits 230 indicate, for example, whether the VM 106 associated with the ASID in the entry's ASID field 224 was the target of an attack, whether the MMIO request 122 associated with the ASID (e.g., the VM 106 allocated to the ASID) should be performed, or both.

[0026] In an embodiment, one or more of DMA control bits 228, MMIO control bits 230, or both, are initialized to indicate that the corresponding VM was not the target of the attack, that DMA request 123 should be fulfilled, that MMIO request 122 should be fulfilled, or any combination thereof. According to an embodiment, for example, if 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 the malicious hypervisor altering the page mapping associated with the block of data indicated in DMA request 123, IOMMU 112 translates the virtual address based on the altered page table mapping to generate the altered address. Thus, the block of data indicated in DMA request 123 is misdirected to the altered address, resulting in a transfer failure (e.g., a page fault). As another example, in response to a malicious hypervisor altering page table mappings to unmap one or more I / O buffers associated with an MMIO request 122 while still allowing data indicating that the MMIO request 122 has completed (e.g., a completion flag) to be written, the VM 106 associated with the MMIO request 122 will read stale data from the I / O buffers. A transfer failure will occur due to the VM 106 reading the stale data and the I / O buffers being unmapped.In response to determining that a transfer failure has occurred, IOMMU 112 is configured to abort the currently executing MMIO or DMA request, determine the VM 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 the data indicated in the MMIO or DMA request) (e.g., based on a descriptor included with the received MMIO request 122 or DMA request 123, a mapping table indicating the set of memory addresses allocated to VM 106, a memory ownership table that maps VMs to ASIDs, ASIDs to memory address spaces, or both), or both. IOMMU 112 then updates security indicator field 226 in entry 222 corresponding to the ASID assigned to the VM associated with the MMIO or DMA request that caused the transfer failure to indicate that the VM was the target of an attack, that one or more MMIO requests should not be performed, that one or more DMA requests should not be performed, or any combination thereof. For example, IOMMU 112 updates DMA control bits 228 to indicate that one or more DMA requests 123 should not be performed, or updates MMIO control bits 230 to indicate that one or more MMIO requests 122 should not be performed, or both.

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

[0028] 3 , exemplary operations 300 for setting MMIO control bits 230 in security indicator field 226 are presented, according to some embodiments. In an embodiment, exemplary operations 300 include processor core 104 or I / O device 120 issuing an MMIO request 305 to IOMMU 112 that is similar to or identical to MMIO request 122. MMIO request 305 includes data indicating a request from a VM, for example, to read data from an I / O device (e.g., I / O device 120), write data to an I / O device, or both. In response to receiving MMIO request 305, IOMMU 112 checks one or more MMIO control bits 310 from a respective entry 222 in ASID mask table 200 that are similar to or identical to MMIO control bits 230. For example, IOMMU 112 checks one or more MMIO control bits 310 in security indicator field 226 in entry 222 of ASID mask table 200 corresponding to an ASID (e.g., the ASID identified in corresponding ASID field 224) assigned to a VM that issued MMIO request 305, is the target of MMIO request 305, or both. In response to MMIO control bits 310 indicating that the corresponding VM was the target of an attack, that all MMIO requests associated with the ASID (e.g., the VM allocated to the ASID) should not be performed, that one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from a particular I / O device 120) should not be performed, or any combination thereof, IOMMU 112 rejects MMIO request 305, for example, by not writing data (e.g., a completion flag) indicating that MMIO request 305 has completed.Additionally, in response to the MMIO control bit 310 indicating that the corresponding VM was not the target of the attack, that all MMIO requests associated with the ASID (e.g., VMs assigned to the ASID) should be fulfilled, that one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from a particular I / O device 120) should be fulfilled, or any combination thereof, the IOMMU 112 completes the MMIO request 305.

[0029] In embodiments, the processing system issuing the MMIO request 305 includes a malicious hypervisor. In such embodiments, the malicious hypervisor alters the page table mapping (e.g., alters the page table in nested page table 125) associated with the I / O buffer associated with the MMIO request 305 provided to IOMMU 112. For example, the malicious hypervisor alters the page table mapping to unmap the I / O buffer while still allowing data (e.g., a completion flag) indicating that the MMIO request 305 has completed to be written. Because the I / O buffer has been unmapped, the MMIO request 305 is blocked, and the VM associated with the MMIO request 305 reads stale data from the I / O buffer, causing a transfer failure. In response to such a transfer failure, IOMMU 112 determines the VM associated with MMIO request 305 (e.g., the VM that initiated MMIO request 305 or the VM that is the target of the data indicated in MMIO request 305) (e.g., based on a descriptor included with MMIO request 305, a mapping of VMs 106 to memory address spaces, a memory ownership table that maps VMs to ASIDs, ASIDs to memory address spaces, or both, or any combination thereof). In response to determining the VM associated with MMIO request 305, IOMMU 112 performs MMIO control bit update operation 315. MMIO control bit update operation 315 may, for example, include IOMMU 112 first aborting the current MMIO request (e.g., MMIO request 305) or DMA request being performed by IOMMU 112.Next, MMIO control bit update operation 315 includes IOMMU 112 updating MMIO control bits 310 in entry 222 of ASID mask table 200 corresponding to the determined VM (e.g., the ASID associated with the VM identified in ASID field 224 of corresponding entry 222) to indicate that the determined VM was the target of the attack, that all MMIO requests associated with the ASID (e.g., the ASID allocated to the VM) should not be performed, that one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from a particular I / O device) should not 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 allocated to the VM) should not be performed. As another example, IOMMU 112 is configured to determine the type of MMIO request 305 based on one or more memory addresses indicated in the MMIO request 305. For example, IOMMU 112 determines which I / O device 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 the MMIO request should not be performed from the determined I / O device associated with the respective VM (e.g., the ASID assigned to the VM).

[0030] 4, an example operation 400 for setting DMA control bits in security indicator field 226 is presented, according to some embodiments. In an embodiment, example operation 400 includes I / O device 120 issuing a DMA request 405 to IOMMU 112 that is similar to or identical to DMA request 123. DMA request 405 includes data indicating a request from the VM to, for example, 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 that are similar to or identical to DMA control bits 228 from each entry 222 in ASID mask table 200. For example, IOMMU 112 checks one or more DMA control bits 410 in security indicator field 226 in entry 222 of ASID mask table 200 corresponding to an ASID (e.g., the ASID identified in corresponding ASID field 224) assigned to a VM that issued DMA request 405, is the target of DMA request 405, or both. In response to DMA control bits 410 indicating that the corresponding VM was the target of an attack, that all DMA requests associated with the ASID (e.g., the VM allocated to the ASID) should not be performed, that one or more types of DMA requests associated with the ASID (e.g., DMA requests from the root complex of processing system 100, DMA requests from certain I / O devices 120) should not be performed, or any combination thereof, IOMMU 112 denies DMA request 405 by, for example, not translating the virtual memory address indicated in DMA request 405.Additionally, in response to the DMA control bit 410 indicating that the corresponding VM was not the target of the attack, that all DMA requests associated with the ASID (e.g., the VM assigned to the ASID) should be performed, that one or more types of DMA requests associated with the ASID (e.g., a DMA request from the root complex of the processing system 100, a DMA request from a particular I / O device 120) should be performed, or any combination thereof, the IOMMU 112 completes the DMA request 405.

[0031] According to an embodiment, the processing system issuing the DMA request 405 includes a malicious hypervisor. In such an embodiment, the malicious hypervisor alters the page table mapping (e.g., alters the page table in nested page table 125) associated with the data block (e.g., virtual memory address) indicated in the DMA request 405 provided to IOMMU 112. For example, the malicious hypervisor alters the page table mapping to selectively reroute the data block indicated in the DMA request 405 to one or more altered memory addresses (e.g., memory addresses modified from the memory address indicated in the DMA request 405). Because the data block is redirected to the altered memory addresses, a transfer failure (e.g., a page fault) occurs. In response to such a transfer failure caused by the DMA request 405, IOMMU 112 determines which VM executed by processing system 100 is associated with the DMA request 405. That is, IOMMU 112 determines the VM that initiated the DMA request 405 or the VM that is the target of the data indicated in the DMA request 405. In an embodiment, IOMMU 112 is configured to determine which VM is associated with DMA request 405 based on, for example, a descriptor included with 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 DMA control bit update operation 415. DMA control bit update operation 415 includes, for example, IOMMU 112 first aborting the current MMIO or DMA request (e.g., DMA request 405) being performed by IOMMU 112.Next, DMA control bit update operation 415 includes IOMMU 112 updating DMA control bits 410 in entry 222 of ASID mask table 200 corresponding to the determined VM (e.g., the ASID associated with the VM identified in ASID field 224 of corresponding entry 222) to indicate that the determined VM was the target of the attack, that all DMA requests associated with the ASID (e.g., the ASID allocated to the VM) should not be performed, that one or more types of DMA requests associated with the ASID (e.g., DMA requests from the root complex of processing system 100, DMA requests from certain I / O devices) should not 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 allocated to the VM) should not be performed. As another example, IOMMU 112 is configured to determine the 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 DMA request 405 is from or whether 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 the DMA request from the determined I / O device associated with the respective VM (e.g., the ASID assigned to the VM) should not 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 the DMA request from the root complex of processing system 100 associated with the respective VM (e.g., the ASID assigned to the VM) should not be performed.

[0032] As described above, ASID mask table 200 stores an individual entry for each ASID of a VM executing on processor 102. This allows IOMMU 112 to individually grant or deny MMIO requests for different VMs, independent of MMIO requests for other VMs. An exemplary embodiment is shown in Figure 5. In the example of Figure 5, assume that processor 102 is running two different VMs, namely VM 106-1 and VM 106-2. IOMMU 112 receives MMIO request 122 from processor core 104 indicating a request to access a register or other memory location of an I / O device on behalf of VM 106-1. Assume further that ASID mask table 200 includes one or more MMIO control bits 230 (e.g., in security indicator field 226 associated with the ASID associated with VM 106-1) that indicate that VM 106-1 was the target of an attack (e.g., was associated with the MMIO request that caused the transfer failure), that all MMIO requests associated with VM 106-1 should not be performed, that one or more types of MMIO requests associated with VM 106-1 (e.g., MMIO requests from certain I / O devices) should not be allowed, or any combination thereof. Accordingly, based on MMIO control bits 230, IOMMU 112 prevents MMIO request 122 from executing (e.g., by not writing data indicating that MMIO request 122 has completed) and indicates to processor core 104 (via message 515) that MMIO request 122 has been denied.

[0033] With respect to MMIO request 505, it is assumed that ASID mask table 200 includes one or more bits in MMIO control bits 230 (e.g., in security indicator field 226 associated with the ASID associated with VM 106-2) that indicate that VM 106-2 was not the target of the attack (e.g., not associated with the MMIO that caused the transfer failure), that all MMIO requests associated with VM 106-2 should be fulfilled, that one or more types of MMIO requests associated with VM 106-2 (e.g., MMIO requests from a particular I / O device) should be fulfilled, or any combination thereof. Thus, based on MMIO control bits 230, IOMMU 112 determines that MMIO request 505 is permitted (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 permits some MMIO requests and denies other MMIO requests based on, for example, a previous attack on the VM by a malicious hypervisor. This prevents a malicious hypervisor, a malicious VM, or both from accessing sensitive information of a VM running on processing system 100, for example, due to the malicious hypervisor changing page table mappings to unmap I / O buffers associated with an MMIO request.

[0034] Similarly, an exemplary embodiment is shown in Figure 6. In the example of Figure 6, assume that processor 102 is running two different VMs, namely VM 106-1 and VM 106-2. IOMMU 112 receives DMA request 123 from I / O device 120 indicating a request to access memory 116 on behalf of VM 106-1. Further assume that ASID mask table 200 includes one or more DMA control bits 228 (e.g., in security indicator field 226 associated with the ASID associated with VM 106-1) that indicate that VM 106-1 was the target of an attack (e.g., was associated with a DMA request that caused a transfer failure), that all DMA requests associated with VM 106-1 should not be performed, that one or more types of DMA requests associated with VM 106-1 (e.g., DMA requests from the root complex of processing system 100, DMA requests from certain I / O devices) should not be performed, or any combination thereof. Therefore, based on DMA control bit 228, IOMMU 112 prevents execution of DMA request 123 (e.g., by not translating the virtual address indicated in DMA request 123) and indicates to I / O device 120 (via message 615) that DMA request 123 has been denied.

[0035] With respect to DMA request 605, assume that ASID mask table 200 includes one or more bits in DMA control bits 228 (e.g., in security indicator field 226 associated with the ASID associated with VM 106-2) that indicate that VM 106-2 was not the target of the attack (e.g., not associated with the DMA request that caused the transfer failure), that all DMA requests associated with VM 106-2 should be fulfilled, that one or more types of DMA requests associated with VM 106-2 (e.g., a DMA request from the root complex of processing system 100, a DMA request from a particular I / O device) should be fulfilled, or any combination thereof. Thus, based on DMA control bits 228, IOMMU 112 determines that DMA request 605 is permitted (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 permits some DMA requests and denies other DMA requests based on, for example, a previous attack on the VM by a malicious hypervisor. Thus, a malicious hypervisor, a malicious VM, or both are prevented from accessing sensitive information of a VM running on processing system 100, for example, due to the malicious hypervisor changing page table mappings.

[0036] 7, an exemplary method 700 for managing secure MMIO and DMA access in an IMMOU is presented. For illustrative purposes, method 700 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 700 is implemented in processing systems having different configurations. In step 705, security circuit 110 defines a memory address space to be allocated to a VM, e.g., based on memory 116, registers and other memory locations of I / O devices (e.g., I / O device 120), or both. For example, in preparation for processor 102 launching VM 106, security circuit 110 defines a memory address space representing separate virtualized portions (e.g., pages) of memory 116, registers and other memory locations of I / O devices (e.g., I / O device 120), or both. Furthermore, security circuit 110 assigns a respective ASID to the memory address space, which includes a unique identifier for the memory address space. In response to security circuit 110 assigning memory address space to VM 106, security circuit 110 associates VM 106 with the ASID of the memory address space assigned to the VM. For example, security circuit 110 is configured to update a table (e.g., a memory ownership table that maps VMs to ASIDs, ASIDs to memory address spaces, or both) so that VM 106 is associated with the ASID of the memory address space assigned to VM 106.

[0037] In step 710, IOMMU 112 receives MMIO requests 122, e.g., from processor core 104 or I / O device 120, DMA requests 123, e.g., from I / O device 120, or both. MMIO requests 122 and DMA requests 123 each include data indicating the virtual memory address targeted by the request. In step 715, IOMMU 112 determines the VM associated with MMIO request 122 or DMA request 123 (e.g., based on a descriptor included in DMA request 405, a mapping of VMs 106 to memory address spaces, a memory ownership table that maps VMs to ASIDs, ASIDs to memory address spaces, or both, or any combination thereof). That is, IOMMU 112 determines the VM that issued MMIO request 122 or DMA request 123, the VM targeted by MMIO request 122 or DMA request 123, or both. In step 720, IOMMU 112 determines whether security indicator field 226 of entry 222 associated with the ASID assigned to the determined VM in ASID mask table 200 indicates that the VM was the target of an attack, e.g., by a malicious hypervisor, that all MMIO requests associated with the VM should be fulfilled, that all DMA requests associated with the VM should be fulfilled, that one or more types of MMIO requests associated with the VM (e.g., MMIO requests from a particular I / O device) should be fulfilled, that one or more types of DMA requests associated with the VM (e.g., DMA requests from the root complex of processing system 100, DMA requests from a particular I / O device) should be fulfilled, or any combination thereof. For example, IOMMU 112 checks one or more of DMA control bits 228, MMIO control bits 230, or both, in security indicator field 226 of entry 222 associated with the ASID assigned to the determined VM.In response to one or more bits of DMA control bits 228, MMIO control bits 230, or both indicating that the VM was not the target of the attack, that all MMIO requests associated with the VM should be performed, that all DMA requests associated with the VM should be performed, that one or more types of MMIO requests associated with the VM (e.g., MMIO requests from a particular I / O device) should be performed, that one or more types of DMA requests associated with the VM (e.g., DMA requests from the root complex of processing system 100, DMA requests from a particular I / O device) should be performed, or any combination thereof, the system moves to step 725.

[0038] In step 725, IOMMU 112 executes the received MMIO request 122 or DMA request 123 and reports the execution to processor core 104 or I / O device 120, respectively. Referring back to step 720, in response to one or more of DMA control bits 228, MMIO control bits 230, or both indicating that a VM was the target of an attack, that all MMIO requests associated with the VM should not be executed, that all DMA requests associated with the VM should not be executed, that one or more types of MMIO requests associated with the VM (e.g., MMIO requests from a particular I / O device) should not be executed, that one or more types of DMA requests associated with the VM (e.g., DMA requests from the root complex of processing system 100, DMA requests from a particular I / O device) should not be executed, or any combination thereof, the system moves to step 730. In step 730, IOMMU 112 rejects the received MMIO request 122 or DMA request 123 (e.g., by not translating the virtual memory address indicated in the request, by not writing data indicating that the request has been completed), and reports the rejection to processor core 104 or I / O device 120, respectively.

[0039] As disclosed herein, in some embodiments, a method includes, in response to receiving a memory-mapped input / output (MMIO) request or a direct memory access (DMA) request associated with a virtual machine (VM), preventing execution of the received MMIO request or DMA request at an input / output memory management unit (IOMMU) based on a security indicator field associated with an address space identifier (ASID) allocated to the VM indicating that the VM was a target of the attack. In one aspect, the method further includes executing the received MMIO request or DMA request by the IOMMU in response to the security indicator field indicating that the VM was not a target of the attack. In another aspect, the method further includes, in response to a transfer failure associated with the VM, modifying one or more bits of the security indicator field to indicate that the VM was a target of the attack.

[0040] In one aspect, the security indicator field is in an ASID mask table maintained by the IOMMU. In another aspect, the security indicator field includes data indicating that all DMA requests associated with the VM should not be performed. In yet another aspect, the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed. In yet another aspect, the method includes modifying one or more bits in the security indicator field to indicate that the VM was not a target of the attack.

[0041] In some embodiments, a method includes preventing performance of a memory-mapped input / output (MMIO) request or a direct memory access (DMA) request for a first VM at an input / output memory management unit (IOMMU) in response to a security indicator field associated with an address space identifier (ASID) allocated to the VM indicating that the VM was the target of the attack. In one aspect, the method includes performing a received MMIO request or DMA request for the VM at the IOMMU in response to the security indicator field indicating that the VM was not the target of the attack. In another aspect, the method further includes modifying one or more bits of the security indicator field to indicate that the VM was the target of the attack in response to a transfer failure associated with the VM. In yet another aspect, the security indicator field includes data indicating that all DMA requests from a specified input / output (I / O) associated with the VM should not be performed.

[0042] In one aspect, the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed. In another aspect, the security indicator field is in an ASID mask table maintained by the IOMMU. In yet another aspect, the method includes modifying one or more bits of the security indicator field to indicate that the VM was not a target of the attack.

[0043] In some embodiments, the processor includes an input / output memory management unit (IOMMU), where the IOMMU is configured, in response to receiving a memory-mapped input / output (MMIO) request or a direct memory access (DMA) request associated with a virtual machine (VM), to prevent execution of the received MMIO request or DMA request based on a security indicator field associated with an address space identifier (ASID) allocated to the VM indicating that the VM was a target of the attack. In one aspect, the IOMMU is configured, in response to the security indicator field indicating that the VM was not a target of the attack, to execute the received MMIO request or DMA request. In another aspect, the IOMMU is configured, in response to a transfer failure associated with the VM, to modify one or more bits of the security indicator field to indicate that the VM was a target of the attack.

[0044] In one aspect, the security indicator field is in an ASID mask table maintained by the IOMMU. In another aspect, the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed. In yet another aspect, the security indicator field includes data indicating that all DMA requests associated with the VM should not be performed.

[0045] 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.

[0046] A computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0047] 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.

[0048] 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.

[0049] 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 memory mapped input / output (MMIO) request or a direct memory access (DMA) request associated with a virtual machine (VM), preventing execution of the received MMIO request or DMA request at an input / output memory management unit (IOMMU) based on a security indicator field associated with an address space identifier (ASID) assigned to the VM indicating that the VM was a target of an attack. method.

2. and wherein the IOMMU executes the received MMIO or DMA request in response to the security indicator field indicating that the VM was not a target of the attack.

10. The method of claim 1.

3. modifying one or more bits of the security indicator field to indicate that the VM was the target of an attack in response to a transfer failure associated with the VM. The method of claim 1 or 2.

4. the security indicator field is present in an ASID mask table maintained by the IOMMU; 10. The method of claim 1.

5. the security indicator field includes data indicating that all DMA requests associated with the VM should not be performed.

10. The method of claim 1.

6. the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed.

10. The method of claim 1.

7. modifying one or more bits in the security indicator field to indicate that the VM was not the target of the attack.

10. The method of claim 1.

8. 1. A method comprising: Preventing, in an input / output memory management unit (IOMMU), execution of a memory mapped input / output (MMIO) request or a direct memory access (DMA) request to a first virtual machine (VM) in response to a security indicator field associated with an address space identifier (ASID) allocated to the VM indicating that the VM was the target of an attack. method.

9. and executing, in the IOMMU, the MMIO request or the DMA request to the VM in response to the security indicator field indicating that the VM was not a target of an attack.

9. The method of claim 8.

10. modifying one or more bits of the security indicator field to indicate that the VM was the target of an attack in response to a transfer failure associated with the VM.

10. The method of claim 8 or 9.

11. the security indicator field includes data indicating that all DMA requests from a particular input / output (I / O) device associated with the VM should not be performed; 9. The method of claim 8.

12. the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed.

9. The method of claim 8.

13. the security indicator field is present in an ASID mask table maintained by the IOMMU; 9. The method of claim 8.

14. modifying one or more bits of the security indicator field to indicate that the VM was not the target of the attack.

9. The method of claim 8.

15. 1. A processor, comprising: an input / output memory management unit (IOMMU); The IOMMU is configured, in response to receiving a memory-mapped input / output (MMIO) request or a direct memory access (DMA) request associated with a virtual machine (VM), to prevent execution of the received MMIO request or DMA request based on a security indicator field associated with an address space identifier (ASID) assigned to the VM indicating that the VM was the target of an attack; Processor.

16. The IOMMU is and performing the received MMIO or DMA request in response to the security indicator field indicating that the VM was not a target of an attack.

16. The processor of claim 15.

17. The IOMMU is and modifying one or more bits of the security indicator field to indicate that the VM was the target of an attack in response to a transfer failure associated with the VM.

17. The processor of claim 15 or 16.

18. the security indicator field is present in an ASID mask table maintained by the IOMMU; 16. The processor of claim 15.

19. the security indicator field includes data indicating that all MMIO requests associated with the VM should not be performed.

16. The processor of claim 15.

20. the security indicator field includes data indicating that all DMA requests associated with the VM should not be performed.

16. The processor of claim 15.

Images