Address space identifier-based security of 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 a memory-mapped input-output (MMIO) request (122) and a direct memory access (DMA) request (123) from a processor core (104) of the processor or one or more input / output (I / O) devices. In response to receiving an MMIO or DMA request, the IOMMU is configured to determine a VM associated with the request. The IOMMU then checks a security indicator field of an address space identifier (ASID) mask table (114) to determine whether the VM was previously a target of a malicious entity attack. In response to the VM being previously the target of the attack, the IOMMU rejects the received MMIO or DMA request.

Description

Background Technology

[0001] In a confidential computing environment, a processing system (e.g., a server) executes multiple software programs owned by different entities, such as virtual machines (VMs) and virtual machine managers (e.g., hypervisors). 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 a confidential computing environment, the environment includes a virtual machine manager (e.g., a hypervisor) that controls the scheduling of 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 different VMs such that each VM operates as if it were running on its own dedicated hardware. However, if the virtual machine manager (e.g., the hypervisor) is a malicious actor, the confidential information of the VMs is at risk of being exposed to unauthorized entities. For example, a malicious virtual machine manager might modify the mapping of page tables associated with a VM, causing requested data to be redirected to another address or memory requests to be blocked, potentially exposing such data to a malicious virtual machine manager or other entities and making the confidential computing environment less secure. Attached Figure Description

[0002] This disclosure can be better understood by referring to the accompanying drawings, and many of its features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to denote similar or identical items.

[0003] Figure 1 This is a block diagram of a processing system based on some implementation schemes, which employs an Input-Output Memory Management Unit (IOMMU) to manage memory-mapped input / output (MMIO) requests and direct memory access (DMA) requests based on a security indicator field.

[0004] Figure 2 This is a block diagram of an exemplary address space identifier (ASID) mask table for managing MMIO requests, DMA requests, or both based on a security indicator field, according to some implementation schemes.

[0005] Figure 3 This is a signal flow diagram of an exemplary operation for setting MMIO control bits in a security indicator field, according to some implementation schemes.

[0006] Figure 4 This is a signal flow diagram of an exemplary operation for setting DMA control bits in a security indicator field, according to some implementation schemes.

[0007] Figure 5 This diagram illustrates how, according to some implementation schemes, MMIO requests to multiple virtual machines are managed based on one or more security indicator fields. Figure 1 A block diagram of an example of IOMMU.

[0008] Figure 6 This diagram illustrates how DMA requests to multiple virtual machines are managed based on one or more security indicator fields, according to some implementation schemes. Figure 1 A block diagram of an example of IMMOU.

[0009] Figure 7 This is a flowchart illustrating an exemplary method for managing MMIO access, DMA requests, or both to multiple virtual machines based on one or more security indicator fields, according to some implementation schemes. Detailed Implementation

[0010] In a processing system, multiple virtual machines (VMs) are executed by one or more processors of the processing system. To facilitate the execution of the VMs, the processing system (e.g., security circuitry of the processing system) allocates one or more corresponding memory address spaces to each of the VMs. Such memory address spaces include virtualized memory portions (e.g., pages) of the physical memory in the processing system, the physical memory of one or more I / O devices, or both. Further, the memory address space allocated to a VM is associated with an Address Space Identifier (ASID), which includes a unique identifier for the allocated memory address space. Additionally, to facilitate the execution of the VMs, the processors of the processing system include, or are otherwise connected to, a hypervisor configured to control the scheduling of different VMs for execution and to provide an interface between the VMs and the hardware of the processing system (e.g., I / O devices), manage the mapping of page tables used to translate virtual addresses in the memory address space into physical addresses, or both.

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

[0012] To further improve processing efficiency, the input-output memory management unit (IOMMU) of the processing system assists in the translation of DMA requests by translating virtual addresses to system physical addresses, rather than the memory controller or central processing unit (CPU) performing such translation of the memory addresses of the DMA requests. Additionally, the IOMMU is configured to process (e.g., execute) one or more MMIO requests originating from the processor core or I / O devices. However, in at least some cases, one or more originating MMIO requests, DMA requests, or both make the security data of the processing system vulnerable to unauthorized access or modification. For example, within the processing system, the hypervisor is configured to maintain page table mappings for translating virtual addresses to system physical addresses (e.g., nested page tables mapping virtual addresses of VM memory to physical memory addresses). In embodiments, a malicious hypervisor can modify, manipulate, or modify and manipulate the page table mappings of virtual addresses to selectively misroute, block, or misroute and block MMIO requests, DMA requests, or both provided to the IOMMU. For example, with respect to DMA requests, a malicious hypervisor is configured to modify the page table mappings used for the virtual addresses identified in the DMA requests provided to the IOMMU. The IOMMU then uses the modified mapping to translate the virtual address identified in the DMA request. This causes the data identified in the DMA request to be rerouted to a changed memory address instead of the expected (e.g., initial) memory address indicated in the DMA request. This results in the VM associated with the DMA request reading incorrect or stale data, or both, from the changed memory address. Therefore, data requested by the DMA request for the VM is potentially exposed to unauthorized access or modification by unwanted entities, such as a malicious hypervisor, a malicious VM, or both. Regarding MMIO requests, a malicious hypervisor is configured to modify the page table mapping to unmap one or more I / O buffers associated with the MMIO request, while still allowing the writing of data indicating the completion of the MMIO request (e.g., a complete write flag, a write buffer complete flag). The data indicating the completion of the MMIO request signals the completion of the MMIO request to the VM associated with the MMIO request, even if the I / O buffers are unmapped and the MMIO request is not actually completed. Therefore, the VM associated with an MMIO request reads stale data from the I / O buffer instead of the expected data (e.g., the data indicated in the MMIO request), potentially exposing such data to unwanted entities such as malicious hypervisors, malicious VMs, or both. In this way, a malicious hypervisor blocks MMIO requests associated with the VM by unmapping the I / O buffer associated with the MMIO request.

[0013] To prevent these and similar attacks, processing systems using the techniques described herein employ an IOMMU to ensure that one or more VMs associated with an MMIO request, DMA request, or both were not previously targeted by such attacks. For example, in some embodiments, the IOMMU maintains an ASID mask table (e.g., stored in memory) comprising multiple entries, each associated with a corresponding ASID. These entries, for example, identify the ASID of the memory address space assigned to a VM executing on the processing system (e.g., one or more processes assigned to the VM). According to embodiments, each entry in the ASID mask table further identifies a security indicator field for the corresponding ASID. Such a security indicator field for a corresponding ASID includes, for example, data (e.g., bits) indicating whether an MMIO request associated with the ASID will be executed, a DMA request associated with the ASID will be executed, 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. Regarding DMA requests, due to a changed page table mapping, the IOMMU translates the virtual address in the DMA request, causing the block data indicated in the DMA request to be incorrectly routed to the changed address (e.g., due to the changed mapping) instead of the expected (e.g., initial) address. By incorrectly routing the data block to the changed address in the DMA request in this way, a transfer failure (e.g., page fault) occurs because the data block is not routed to the expected address. Further, regarding MMIO requests, due to a changed page table mapping, one or more I / O buffers associated with the MMIO request are unmapped, while still allowing the writing of data indicating the completion of the MMIO request (e.g., a complete write flag, a write buffer complete flag). In response to this data indicating the completion of the MMIO request, when the MMIO request is blocked due to the unmapping of the I / O buffer, the VM associated with the MMIO request reads stale data from the I / O buffer. Because the I / O buffer is unmapped and the VM reads stale (e.g., incorrect) data from the I / O buffer, a transfer failure (e.g., page fault) occurs.

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

[0015] Upon receiving an MMIO request from the 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 by, for example, using one or more tables that map a Virtual Machine Identifier (VMID), ASID, 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 assigned to the determined VM indicates whether the MMIO request, DMA request, or both associated with the VM (e.g., the VM's ASID) is permitted (e.g., will be executed). For example, the IOMMU checks whether one or more bits of the security indicator field associated with the ASID in the ASID mask table indicate that the MMIO request, DMA request, or both will be executed. In response to a security indicator field associated with the ASID indicating that an MMIO request, DMA request, or both (e.g., indicating that the VM associated with the MMIO or DMA request is the target of an attack) will not be executed, the IOMMU, as described herein, prevents the execution of an MMIO or DMA request, for example, by preventing virtual memory address-to-physical address translation, not writing data indicating the completion of the MMIO or DMA request, or both. In response to a security indicator field associated with the ASID indicating that an MMIO request, DMA request, or both (e.g., the VM associated with the MMIO or DMA request is not the target of an attack) will be executed, the IOMMU executes the MMIO or DMA request. Therefore, using the techniques described herein, the IOMMU prevents the execution of MMIO or DMA requests on behalf of the VM when 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 confidential information associated with the VM. Furthermore, because these security operations are performed by the IOMMU itself, it is difficult for malicious hypervisors to interfere with these operations, thereby supporting secure MMIO and DMA access in confidential computing environments.

[0016] Figure 1The illustration depicts a processing system 100 according to some embodiments, which employs an Input / Output Memory Management Unit (IOMMU) to manage memory-mapped input / output (MMIO) requests and direct memory access (DMA) requests based on a security indicator field. The processing system 100 is typically 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 an instruction set, the processing system 100 is configured to perform one or more operations indicated in that instruction set. Therefore, in different embodiments, the processing system 100 is part of any of a variety of electronic devices. For purposes of description, it is assumed that the processing system 100 is part of an electronic device (such as a server) implementing a confidential computing environment. However, in other embodiments, the processing system 100 is part of a desktop computer, laptop computer, tablet computer, game console, etc.

[0017] To enable a confidential computing environment and to execute instruction sets 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 120). In some embodiments, processor 102 is a general-purpose processor, such as a central processing unit (CPU), which includes hardware-based circuitry, software-based circuitry, or both, configured to retrieve and execute instruction sets. Memory 116 includes one or more memory devices configured to store and retrieve data based on commands received from processor 102 (e.g., store and load commands). Accordingly, 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 storage, etc., or any combination thereof.

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

[0019] To execute the instruction set and corresponding operations, processor 102 includes processor core 104, security circuitry 110, and IOMMU 112. It should be understood 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 just a few.

[0020] To execute an instruction set, processor core 104 includes one or more instruction pipelines, which include multiple stages for pipelined execution of instructions. 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), an exit stage, or any combination thereof, to name just a few. According to embodiments, processor core 104 also includes, or has access to, memory structures and other hardware supporting instruction execution. Figure 1 (Not explicitly illustrated). For example, in some implementations, processor core 104 includes or can access one or more cache structures to store data for executing instructions.

[0021] As noted above, the processing system 100 is typically configured to implement a confidential computing environment, and specifically configured to execute multiple virtual machines (VMs) (e.g., VM 106) (also referred to as guests) and a hypervisor 108 (also referred to as the host) to manage the execution of the multiple VMs. Although Figure 1The exemplary embodiment illustrated presents a processing system 100 executing three VMs (106-1, 106-2, 106-N) out of N VMs; however, in other embodiments, the processing system is configured to execute any number of VMs 106. In this embodiment, because two or more VMs 106, and in at least some cases the hypervisor 108, are owned by different entities, the processing system 100 implements security features to protect the data of a given VM 106 from access by other software, such as another VM 106 or the hypervisor 108. For example, the processing system 100 achieves VM 106 data security by implementing a secure region 118 in a memory 116 that stores, for example, encrypted data. Specifically, the processor 102 is configured to encrypt corresponding specified data of one or more VMs 106 according to a corresponding private cryptographic key, and store the resulting encrypted data in the secure region 118. Because the data is encrypted, the data of the first VM 106 is protected from unauthorized access by one or more other VMs 106, the hypervisor 108, or both. In at least some implementations, the cryptographic key for VM 106 is managed by security circuitry 110, and data encryption and decryption for VM 106 are performed by a dedicated hardware encryption / decryption module (not shown) at the memory controller (not shown) of processor 102.

[0022] To further aid in protecting the confidential computing environment, processor 102 includes security circuitry 110, which includes hardware-based circuitry, software-based circuitry, or both, typically configured to create, monitor, and maintain a secure environment for processor 102. For example, in at least some embodiments, security circuitry 110 is configured to manage the boot process of processor 102, initialize security-related mechanisms of processor 102, monitor suspicious activity or events of processing system 100, and implement appropriate responses, or any combination thereof. According to embodiments, security circuitry 110 includes, 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), an interface configured to interact with memory 116, an I / O controller for processor 102, and configuration registers (e.g., hardware registers) for processor 102, or any combination thereof. In embodiments, security circuitry 110 includes, for example, environment management control hardware that performs environmental and security checks to help ensure that processor 102 operates according to one or more specified security parameters.

[0023] According to the implementation, security circuit 110 is configured to define one or more memory address spaces in processing system 100 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 to boot VM 106, security circuit 110 is configured to define one or more memory address spaces to be assigned to VM 106. Each memory address space represents, for example, at least a virtualized portion of memory 116 (e.g., one or more pages), registers and other storage locations of I / O devices, or both. For example, security circuit 110 is configured to define memory address spaces representing virtualized portions of memory 116 (e.g., pages) and one or more registers of I / O device 120. Additionally, security circuit 110 is configured to assign a corresponding address space identifier (ASID) to each defined memory address space. For example, each of such ASIDs includes data (e.g., multiple bits) indicating a unique identifier of the corresponding memory address space of the system. According to the implementation, security circuit 110 ensures that two or more VMs 106 are not assigned the same (or overlapping) memory address spaces. In this way, multiple VMs 106 executed by processor 102 can each access memory 116, registers of I / O devices, or other memory locations, or both. According to an embodiment, hypervisor 108 is configured to maintain a mapping of virtual memory addresses in the memory address space to physical memory addresses within memory 116, one or more I / O devices, or both. For example, hypervisor 108 maintains a nested page table 125, which includes page tables indicating physical memory addresses of one or more virtual memory addresses. After memory address space is allocated to VMs 106, security circuitry 110 associates VMs 106 with the ASID of the memory address space allocated to the VMs. For example, security circuitry 110 is configured to update tables (e.g., memory ownership tables mapping VMs to ASIDs, mapping ASIDs to memory address spaces, or both) such that VMs 106 are associated with the ASID of the memory address space allocated to the VMs.

[0024] To improve processing efficiency, IOMMU 112 is typically configured to perform specified memory access operations on behalf of processor 102. That is, memory access operations are performed using hardware-based circuitry, software-based circuitry, or both of IOMMU 112, without requiring processor 102 to manage the memory access operations. Specifically, 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) generates MMIO requests (e.g., MMIO request 122) on behalf of one or more VMs 106 when executing them, to read data from an I / O device (e.g., I / O device 120), write data to an I / O device, or both. 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 other I / O devices, write data to other I / O devices, or both. According to embodiments, each MMIO request 122 includes a descriptor indicating a 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 a register or other memory location from which data is to be read, the memory address of a register or other memory location from which 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 VM 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 a virtual address of a register or other memory location of memory 116 to be accessed. IOMMU 112 is typically configured to translate the virtual address indicated by DMA request 123 into a physical address of a register or other memory location, and to interact with I / O devices to perform one or more operations (read operation, write operation, or both) indicated by DMA request 123. Further, the memory management unit (MMU) of processor 102 (not shown for clarity) is configured to translate the virtual address indicated by MMIO request 122 into a physical address of a register or other memory location.

[0025] Because MMIO request 122 and DMA request 123 are executed, at least in some cases, independently of the operation of processor 102, they provide a malicious entity with a means to access confidential information associated with the VMs executing at processor 102. For example, with respect to DMA request 123, a malicious hypervisor could be configured to cause partial failure of DMA request 123 issued on behalf of one or more VMs by altering the page table mapping associated with DMA request 123 (e.g., in nested page table 125) such that data requested in DMA request 123 is selectively rerouted to an incorrect address (e.g., an address other than that expected by DMA request 123). As an example, if VM 106 issues DMA request 123 instructing a DMA transfer, the malicious hypervisor alters the page table in nested page table 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 changed page table mapping, causing the requested data to be rerouted to the changed address (e.g., an address other than the expected address). This behavior of the hypervisor is used to potentially identify confidential information associated with VM 106. As another example, regarding MMIO request 122, the hypervisor is configured to modify, for example, the page table mapping in nested page table 125 to block one or more MMIO requests 122. To do this, the hypervisor is configured to unmap one or more I / O buffers associated with MMIO request 122 while still allowing data indicating the completion of MMIO request 122 (e.g., a complete write flag, a write buffer complete flag) to be written. The data indicating the completion of the MMIO request sends a notification to VM 106 associated with MMIO request 122 indicating that MMIO request 122 is complete, even if the I / O buffer is unmapped and MMIO request 122 is not actually completed. Therefore, the VM 106 associated with MMIO request 122 reads stale data from the I / O buffer instead of the expected data (e.g., the data indicated in MMIO request 122), potentially exposing such data to unwanted entities such as a malicious hypervisor, a malicious VM, or both. In this way, a malicious hypervisor blocks MMIO request 122 associated with one or more VMs 106 by unmapping the I / O buffer associated with MMIO request 122.

[0026] To address these potential vulnerabilities, IOMMU 112 maintains an ASID mask table 114 that indicates one or more ASIDs associated with (e.g., assigned to) each VM 106. In other words, to address potential vulnerabilities, processing system 100 includes an ASID mask table 114 stored, for example, in memory 116, maintained by IOMMU 112. ASID mask table 114 includes one or more entries, each associated with an ASID assigned to a corresponding VM 106. For example, each entry includes a field identifying the ASID assigned to the corresponding VM and a security indicator field associated with the ASID. The security indicator field includes data (e.g., multiple bits) indicating, for example, whether the VM 106 associated with the ASID is a target for attack, such as a malicious hypervisor, whether an MMIO request 122 associated with the VM 106 will be allowed, whether a DMA request 123 associated with the VM 106 will be allowed, or any combination thereof. For example, the security indicator field includes a first bit indicating whether MMIO request 122 associated with VM 106 is allowed and a second bit indicating whether DMA request 123 associated with VM 106 is allowed. To set such data in the security indicator field, 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 nested page table 125 for the virtual address associated with DMA request 123 provided to IOMMU 112, data blocks are misdirected to the altered address. Due to this misdirection, a transfer failure (e.g., a page fault) occurs when data is not transferred to the correct address (e.g., the originally indicated address). As another example, in response to a malicious hypervisor altering the page table mapping in nested page table 125 to unmap one or more I / O buffers associated with MMIO request 122 while still allowing data indicating the completion of MMIO request 122 (e.g., a completion flag), MMIO request 122 is blocked, and the VM 106 associated with MMIO request 122 will read stale data from the I / O buffers because no data has been written to these buffers. Because MMIO request 122 is blocked, a transfer failure (e.g., a page fault) will occur due to the unmapping of I / O buffers and the reading of stale data.

[0027] In response to such a transfer failure due to an MMIO request for a DMA request, IOMMU 112 determines (e.g., based on a descriptor included with the MMIO request or DMA request, a mapping of VM 106 to a memory address space, a memory ownership table mapping VMs to ASIDs, ASIDs to memory address spaces, or both) 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 data indicated in the MMIO or DMA request). For example, in some embodiments, memory 116 includes a mapping table indicating a set of memory addresses (e.g., VM identifiers) allocated to VM 106, as disclosed in a co-owned and related U.S. patent application entitled "Secure Memory-Mapped Input / Output," filed on the same day as this application, the relevant portions of which relating to the mapping table are incorporated herein by reference. Using such a mapping table, 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, IOMMU 112 updates the security indicator field associated with the ASID assigned to VM 106 in ASID mask table 114. For example, IOMMU 112 sets one or more bits in the security indicator field associated with the ASID such that the security indicator indicates that VM 106 is the target of an attack, that the MMIO request 122 associated with VM 106 will not be executed, that the DMA request 123 associated with VM 106 will not be executed, or any combination thereof. In other words, IOMMU 112 sets a bit in the security indicator field associated with ASID such that the security indicator field indicates that a transfer failure caused by an MMIO or DMA request associated with VM 106 has occurred, that MMIO request 122 associated with VM 106 will not be executed, that DMA request 123 associated with VM 106 will not be executed, or any combination thereof.

[0028] Furthermore, IOMMU 112 is configured to execute (e.g., run) received MMIO and DMA requests based on ASID mask table 114. For example, in response to receiving an MMIO or DMA request, IOMMU 112 is configured to determine 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). As an example, using a mapping table indicating a set of memory addresses assigned to VM 106, 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, IOMMU 112 then checks ASID mask table 114. For example, IOMMU 112 checks one or more bits of the security indicator field associated with the ASID assigned to VM 106 in ASID mask table 114. In response to one or more bits in the security indicator field associated with the ASID assigned to VM 106 indicating that MMIO request 122 will not be executed, DMA request 123 will not be executed, or both, IOMMU 112 rejects the received MMIO or DMA request respectively and does not execute the MMIO or DMA request (e.g., does not translate the address indicated in the DMA request, does not write data indicating the completion of the MMIO or DMA request). Further, in response to bits in the security indicator field associated with the ASID assigned to VM 106 indicating that MMIO request 122 will be executed, DMA request 123 will be executed, or both, IOMMU 112 executes (e.g., runs) the received MMIO or DMA request respectively. In this way, IOMMU 112 helps ensure that MMIO or DMA requests are satisfied only if 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 VM 106 has not caused a transfer failure). Therefore, IOMMU 112 helps prevent malicious hypervisors and malicious VMs from accessing confidential VM information via MMIO or DMA requests.

[0029] Figure 2An exemplary ASID mask table 200 for managing MMIO requests, DMA requests, or both, according to some embodiments, is illustrated. In an exemplary embodiment, ASID mask table 200, similar to or the same as ASID mask table 114, includes a plurality of entries 222, each entry 222 corresponding to a corresponding ASID (e.g., an ASID assigned to a corresponding VM 106). For example, ASID mask table 200 includes a plurality of entries 222, each entry corresponding to an ASID assigned to a corresponding VM 106 currently executing at processor 102, a VM 106 expected to execute at processor 102 (e.g., a VM that has already undergone a VM provisioning process at processing system 100), or both (to name just a few). Figure 2 The exemplary implementation presents the ASID mask table 200 as having four entries (e.g., 222-1, 222-2, 222-3, 222-N) representing N entries 222; however, in other implementations, the ASID mask table 200 may include any number of entries. As an example, the ASID mask table 200 includes entries 222 for assigning to each ASID of a VM 106 currently executing at processor 102, each VM 106 expected to execute at processor 102, or both.

[0030] In the implementation, each entry 222 of 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 an ASID corresponding to a memory address space assigned to, for example, a VM 106 currently executing at processor 102, a VM 106 expected to execute at processor 102, or both. For example, in preparation for processor 102 to start VM 106, security circuitry 110 is configured to define a memory address space to be assigned to VM 106. Security circuitry 110 defines the memory address space 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 corresponding ASID to the memory address space. For example, such an ASID includes a unique identifier for the memory address space. During the provisioning process of VM 106, security circuitry 110 then assigns the defined memory address space to the corresponding VM 106. Security circuit 110 then updates a table (e.g., a memory ownership table mapping VMs to ASIDs, mapping ASIDs to memory address spaces, or both) such that VM 106 is associated with the ASID of the memory address space assigned to VM 106. In an embodiment, such an ASID assigned to the corresponding VM 106 is reflected in the corresponding ASID field 224.

[0031] According to the implementation scheme, the security indicator field 226 of entry 222 indicates whether the VM associated with the ASID identified in the ASID field 224 of entry 222 is the target of an attack, whether the DMA request 123 associated with the ASID will be executed, whether the MMIO request 122 associated with the ASID will be executed, or any combination thereof. For this purpose, each security indicator field 226 includes one or more DMA control bits 228 and one or more MMIO control bits 230. For example, such a DMA control bit 228 indicates whether the VM 106 associated with the ASID in the ASID field 224 of the entry is the target of an attack, whether the DMA request 123 associated with the ASID (e.g., the VM 106 assigned to the ASID) will be executed, or both. The MMIO control bit 230, for example, indicates whether the VM 106 associated with the ASID in the ASID field 224 of the entry is the target of an attack, whether the MMIO request 122 associated with the ASID (e.g., the VM 106 assigned to the ASID) will be executed, or both.

[0032] In the implementation, one or more bits of DMA control bit 228, MMIO control bit 230, or both are initialized to indicate that the corresponding VM is not the target of an attack, DMA request 123 will be executed, MMIO request 122 will be executed, or any combination thereof. According to the implementation, one or more transfer failures (e.g., page faults) will occur when, for example, a malicious hypervisor selectively reroutes, blocks, or reroutes and blocks one or more MMIO requests 122, DMA requests 123, or both provided to IOMMU 112. For example, in response to a malicious hypervisor changing the page mapping associated with the data block indicated in DMA request 123, IOMMU 112 translates the virtual address based on the changed page table mapping to produce the changed address. Therefore, the data block indicated in DMA request 123 will be incorrectly redirected to the changed address, and a transfer failure (e.g., page fault) will occur. As another example, in response to a malicious hypervisor altering the page table mapping to unmap one or more I / O buffers associated with MMIO request 122 while still allowing writes of data indicating the completion of MMIO request 122 (e.g., a completion flag), VM 106 associated with MMIO request 122 will read stale data from the I / O buffer. Because VM 106 reads stale data and the I / O buffer is unmapped, a transfer failure will occur. In response to determining that a transfer failure has occurred, IOMMU 112 is configured to abort the currently executing MMIO or DMA request by determining (e.g., based on a descriptor included with the received MMIO request 122 or DMA request 123, a mapping table indicating a set of memory addresses allocated to VM 106, a memory ownership table mapping VMs to ASIDs, mapping ASIDs to memory address spaces, or both, or any combination thereof) 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), or both. IOMMU 112 then updates the security indicator field 226 in entry 222 corresponding to the ASID assigned to the VM (which is associated with the MMIO or DMA request that caused the transfer failure) to indicate that the VM is the target of an attack, one or more MMIO requests will not be executed, one or more DMA requests will not be executed, or any combination thereof. For example, IOMMU 112 updates DMA control bit 228 to indicate that one or more DMA requests 123 will not be executed, updates MMIO control bit 230 to indicate that one or more MMIO requests 122 will not be executed, or both.

[0033] According to the implementation scheme, IOMMU 112 is configured to update one or more DMA control bits 228 to indicate that one or more types of DMA requests 123 will not be executed. 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 entry 222) will be blocked, DMA requests 123 from the root complex of processing system 100 (e.g., associated with the ASID identified in entry 222) will be blocked, DMA requests 123 from one or more specific I / O devices (e.g., I / O device 120) (e.g., associated with the ASID identified in entry 222) will be blocked, or any combination thereof. For example, based on one or more memory addresses identified by the DMA request 123 that caused the transfer failure, IOMMU 112 is configured to update DMA control bit 228 to indicate that all DMA requests 123 will be blocked, DMA requests 123 from the root complex of processing system 100 will be blocked, DMA requests 123 from one or more specific I / O devices (e.g., I / O device 120) will be blocked, 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 will not be executed. For example, IOMMU 112 is configured to update MMIO control bit 230 to indicate that all MMIO requests 122 (e.g., associated with the ASID identified in entry 222) will be blocked, MMIO requests 122 from one or more specific I / O devices (e.g., I / O device 120) (e.g., associated with the ASID identified in entry 222) will be blocked, or both. For example, based on one or more memory addresses identified by the MMIO request 122 that caused the transfer failure, the IOMMU 112 is configured to update the MMIO control bit 230 to indicate that all MMIO requests 122 will be blocked, MMIO requests 122 from one or more specific I / O devices (e.g., I / O device 120) will be blocked, or both.

[0034] Now for reference Figure 3According to some implementations, exemplary operation 300 is presented for setting MMIO control bit 230 in security indicator field 226. In an implementation, exemplary operation 300 includes processor core 104 or I / O device 120 issuing an MMIO request 305 to IOMMU 112 that is similar to or the same as MMIO request 122. MMIO request 305 includes, for example, data indicating a request from a VM, such as reading data from an I / O device (e.g., I / O device 120), writing 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 that are similar to or the same as MMIO control bit 230 from the corresponding entry 222 in ASID mask table 200. For example, IOMMU 112 checks one or more MMIO control bits 310 in the security indicator field 226 of the entry 222 of the ASID mask table 200 corresponding to the ASID of the VM that issued the MMIO request 305, the VM that is the target of the MMIO request 305, or both (e.g., the ASID identified in the corresponding ASID field 224). In response to the MMIO control bit 310 indicating that the corresponding VM is the target of an attack, that all MMIO requests associated with the ASID (e.g., the VM assigned to the ASID) will not be executed, that one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from certain I / O devices 120) will not be executed, or any combination thereof, IOMMU 112 rejects the MMIO request 305 by, for example, not writing data indicating that the MMIO request 305 is complete (e.g., a completion flag). Additionally, in response to MMIO control bit 310 indicating that the corresponding VM is not the target of an attack, all MMIO requests associated with the ASID (e.g., the VM assigned to the ASID) will be executed, one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from certain I / O devices 120) will be executed, or any combination thereof, IOMMU 112 completes MMIO request 305.

[0035] In one implementation, the processing system issuing MMIO request 305 includes a malicious hypervisor. In such an implementation, the malicious hypervisor alters the page table mapping associated with an I / O buffer (e.g., altering a page table in nested page table 125) that is 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 the writing of data indicating the completion of MMIO request 305 (e.g., a completion flag). Because the I / O buffer is unmapped, MMIO request 305 is blocked, and the VM associated with MMIO request 305 reads stale data from the I / O buffer, resulting in a transfer failure. In response to such a transfer failure, IOMMU 112 determines (e.g., based on the descriptor included with MMIO request 305, the mapping of VM 106 to the memory address space, a memory ownership table mapping VMs to ASIDs, mapping ASIDs to the memory address space, or both, or any combination thereof) 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). In response to determining the VM associated with MMIO request 305, IOMMU 112 performs an update MMIO control bit operation 315. The update MMIO control bit operation 315 may, for example, first include IOMMU 112 aborting the current MMIO request (e.g., MMIO request 305) or a DMA request performed by IOMMU 112. Next, the MMIO control bit update operation 315 includes IOMMU 112 updating the MMIO control bit 310 in entry 222 of the ASID mask table 200 corresponding to the identified VM (e.g., the ASID associated with the VM identified in the ASID field 224 of the corresponding entry 222) to indicate that the identified VM is the target of the attack, all MMIO requests associated with the ASID (e.g., the ASID assigned to the VM) will not be executed, one or more types of MMIO requests associated with the ASID (e.g., MMIO requests from certain I / O devices) will not be executed, or any combination thereof. For example, IOMMU 112 updates one or more bits of MMIO control bit 310 to indicate that all MMIO requests associated with the identified VM (e.g., the ASID assigned to the VM) will not be executed. As another example, IOMMU 112 is configured to determine the type of 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 originates from.In response to determining which I / O device the MMIO request originated from, IOMMU 112 updates one or more bits of MMIO control bit 310 to indicate that the MMIO request from the determined I / O device associated with the corresponding VM (e.g., the ASID assigned to the VM) will not be executed.

[0036] Now for reference Figure 4 According to some embodiments, an exemplary operation 400 for setting DMA control bits in security indicator field 226 is presented. In an embodiment, exemplary operation 400 includes I / O device 120 issuing a DMA request 405 to IOMMU 112 that is similar to or the same as DMA request 123. DMA request 405 includes, for example, data indicating a request from a VM, such as reading data from memory (e.g., memory 116) of processing system 100, writing data to 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 the same as DMA control bit 228 from the corresponding entry 222 in ASID mask table 200. For example, IOMMU 112 checks one or more DMA control bits 410 in the security indicator field 226 of entry 222 of ASID mask table 200 that correspond to the ASID of the VM that issued the DMA request 405, the VM that is the target of the DMA request 405, or both (e.g., the ASID identified in the corresponding ASID field 224). In response to the DMA control bit 410 indicating that the corresponding VM is the target of an attack, that all DMA requests associated with the ASID (e.g., the VM assigned to the ASID) will not be executed, 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) will not be executed, or any combination thereof, IOMMU 112 rejects the DMA request 405 by, for example, not translating the virtual memory address indicated in the DMA request 405. Additionally, in response to DMA control bit 410 indicating that the corresponding VM is not the target of the attack, all DMA requests associated with ASID (e.g., the VM assigned to ASID) will be executed, one or more types of DMA requests associated with ASID (e.g., DMA requests from the root complex of processing system 100, DMA requests from certain I / O devices 120) will be executed, or any combination thereof, IOMMU 112 completes DMA request 405.

[0037] According to an implementation, the processing system issuing DMA request 405 includes a malicious hypervisor. In such an implementation, the malicious hypervisor alters the page table mapping associated with the data block (e.g., a virtual memory address) indicated in the DMA request 405 provided to the IOMMU 112 (e.g., changing the page table in nested page table 125). For example, the malicious hypervisor alters the page table mapping to selectively reroute the data block indicated in DMA request 405 to one or more changed memory addresses (e.g., memory addresses modified from the memory address indicated in DMA request 405). Because the data block is redirected to the changed memory address, a transfer failure (e.g., a page fault) occurs. In response to such a transfer failure caused by DMA request 405, IOMMU 112 determines which VM executed by processing system 100 is associated with DMA request 405. That is, IOMMU 112 determines the VM that initiated DMA request 405 or the VM that is the target of the data indicated in DMA request 405. In the implementation, 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 VM 106 to memory address space, a memory ownership table mapping VMs to ASIDs, a memory ownership table mapping ASIDs to memory address space, or any combination thereof. After determining which VM is associated with DMA request 405, IOMMU 112 performs an update DMA control bit operation 415. For example, update DMA control bit operation 415 first includes IOMMU 112 aborting the current MMIO request or DMA request (e.g., DMA request 405) performed by IOMMU 112. Next, the DMA control bit update operation 415 includes IOMMU 112 updating the DMA control bit 410 in entry 222 of the ASID mask table 200 corresponding to the identified VM (e.g., the ASID associated with the VM identified in the ASID field 224 of the corresponding entry 222) to indicate that the identified VM is the target of the attack, all DMA requests associated with the ASID (e.g., the ASID assigned to the VM) will not be executed, 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) will not be executed, or any combination thereof. For example, IOMMU 112 updates one or more bits of DMA control bit 410 to indicate that all DMA requests associated with the identified VM (e.g., the ASID assigned to the VM) will not be executed. 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 405 originates from, or whether DMA request 405 originates from the root complex of processing system 100. In response to determining which I / O device the DMA request originates from, IOMMU 112 updates one or more bits of DMA control bit 410 to indicate that the DMA request from the determined I / O device associated with the corresponding VM (e.g., the ASID assigned to the VM) will not be executed. Similarly, in response to determining that the DMA request originates from the root complex of processing system 100, IOMMU 112 updates one or more bits of DMA control bit 410 to indicate that the DMA request from the root complex of processing system 100 associated with the corresponding VM (e.g., the ASID assigned to the VM) will not be executed.

[0038] As noted above, the ASID mask table 200 stores a separate entry for each ASID of the VM executing at processor 102. This allows the IOMMU 112 to individually allow or deny MMIO requests for different VMs, regardless of MMIO requests for other VMs. Figure 5 An exemplary implementation is illustrated below. Figure 5 In an exemplary implementation, it is assumed that processor 102 is executing two different VMs: VM 106-1 and VM 106-2. IOMMU 112 receives MMIO request 122 from processor core 104, which indicates a request to access registers or other storage locations of I / O devices on behalf of VM 106-1. Further, it is assumed that ASID mask table 200 includes one or more MMIO control bits 230 (e.g., in security indicator field 226 associated with the ASID of VM 106-1) indicating that VM 106-1 is the target of an attack (e.g., associated with an MMIO request that caused a transfer failure), that all MMIO requests associated with VM 106-1 will not be executed, that one or more types of MMIO requests associated with VM 106-1 (e.g., MMIO requests from certain I / O devices) will be prohibited, or any combination thereof. Accordingly, based on MMIO control bit 230, IOMMU 112 prevents the execution of MMIO request 122 (e.g., by not writing data indicating that MMIO request 122 has been completed) and indicates to processor core 104 (via message 515) that MMIO request 122 has been rejected.

[0039] Regarding MMIO request 505, assume that ASID mask table 200 includes one or more bits of MMIO control bit 230 (e.g., in security indicator field 226 associated with the ASID of VM 106-2) that indicate that VM 106-2 is not the target of an attack (e.g., not associated with the MMIO that caused the transfer failure), that all MMIO requests associated with VM 106-2 will be executed, that one or more types of MMIO requests associated with VM 106-2 (e.g., MMIO requests from certain I / O devices) will be executed, or any combination thereof. Accordingly, based on MMIO control bit 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 Figure 5 In the example, IOMMU 112 selectively allows some MMIO requests and denies others based on, for example, a previous attack by a malicious hypervisor on the VM. Therefore, because, for example, a malicious hypervisor alters the page table mapping to unmap the I / O buffers associated with MMIO requests, the malicious hypervisor, a malicious VM, or both are prevented from accessing confidential information of the VM running on processing system 100.

[0040] Similarly, in Figure 6 An exemplary implementation is illustrated below. Figure 6 In an exemplary implementation, it is assumed that processor 102 is executing two different VMs: VM 106-1 and VM 106-2. IOMMU 112 receives a DMA request 123 from I / O device 120, which indicates a request to access memory 116 on behalf of VM 106-1. Further, it is assumed that ASID mask table 200 includes one or more DMA control bits 228 (e.g., in a security indicator field 226 associated with the ASID of VM 106-1) indicating that VM 106-1 is the target of an attack (e.g., associated with a DMA request that caused a transfer failure), that all DMA requests associated with VM 106-1 will not be executed, 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) will not be executed, or any combination thereof. Accordingly, based on DMA control bit 228, IOMMU 112 prevents the 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 rejected.

[0041] Regarding DMA request 605, assume that ASID mask table 200 includes one or more bits of DMA control bit 228 (e.g., in security indicator field 226 associated with the ASID of VM 106-2) that indicate that VM 106-2 is not the target of an attack (e.g., not associated with a DMA request that caused the transfer failure), that all DMA requests associated with VM 106-2 will be executed, that one or more types of DMA requests associated with VM 106-2 (e.g., DMA requests from the root complex of processing system 100, DMA requests from certain I / O devices) will be executed, or any combination thereof. Accordingly, based on DMA control bit 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 Figure 6 In the example, IOMMU 112 selectively allows some DMA requests and denies others based on, for example, a previous attack by a malicious hypervisor on the VM. Therefore, because, for example, the malicious hypervisor alters the page table mapping, the malicious hypervisor, the malicious VM, or both are prevented from accessing confidential information of the VM running on the processing system 100.

[0042] Now for reference Figure 7 This paper presents an exemplary method 700 for managing secure MMIO and DMA access at the IMMOU. For purposes of description, reference is made to... Figure 1 The method 700 is described using an exemplary specific implementation at processing system 100, but it should be understood that in other implementations, method 700 is implemented at processing systems with different configurations. At step 705, security circuitry 110 defines a memory address space to be allocated to the 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, when preparing processor 102 to start VM 106, security circuitry 110 defines a memory address space representing different virtualized portions of memory 116 (e.g., pages), registers and other storage locations of I / O devices (e.g., I / O device 120), or both. Further, security circuitry 110 assigns a corresponding ASID, including a unique identifier for the memory address space, to 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 circuit 110 is configured to update tables (e.g., a memory ownership table that maps VMs to ASIDs, maps ASIDs to memory address spaces, or both) such that VM 106 is associated with the ASID of the memory address space assigned to VM 106.

[0043] At step 710, IOMMU 112 receives MMIO request 122 from, for example, processor core 104 or I / O device 120, and DMA request 123 from, for example, I / O device 120, or both. MMIO request 122 and DMA request 123 each include data indicating a virtual memory address 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 DMA request 405, a mapping of VM 106 to a memory address space, mapping VMs to ASIDs, mapping ASIDs to a memory address space, or a memory ownership table of 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. At step 720, IOMMU 112 determines whether the security indicator field 226 of the entry 222 associated with the ASID assigned to the identified VM in ASID mask table 200 indicates that the VM is the target of an attack (e.g., a malicious hypervisor), all MMIO requests associated with the VM will be executed, all DMA requests associated with the VM will be executed, one or more types of MMIO requests associated with the VM (e.g., MMIO requests from certain I / O devices) will be executed, 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 certain I / O devices) will be executed, or any combination thereof. For example, IOMMU 112 checks one or more bits of DMA control bit 228, MMIO control bit 230, or both in the security indicator field 226 of the entry 222 associated with the identified VM's ASID. In response to one or more bits of DMA control bit 228, MMIO control bit 230, or both indicating that the VM is not the target of the attack, all MMIO requests associated with the VM will be executed, all DMA requests associated with the VM will be executed, one or more types of MMIO requests associated with the VM (e.g., MMIO requests from certain I / O devices) will be executed, 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 certain I / O devices) will be executed, or any combination thereof, the system moves to step 725.

[0044] At 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 again to step 720, in response to DMA control bit 228, MMIO control bit 230, or one or more of both indicating that the VM is the target of the attack, all MMIO requests associated with the VM will not be executed, all DMA requests associated with the VM will not be executed, one or more types of MMIO requests associated with the VM (e.g., MMIO requests from certain I / O devices) will not be executed, 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 certain I / O devices) will not be executed, or any combination thereof, the system moves to step 730. At 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 the data indicating that the request is complete), and reports the rejection to processor core 104 or I / O device 120 respectively.

[0045] As disclosed herein, in some embodiments, a method includes: in response to receiving a memory-mapped input / output (MMIO) request or direct memory access (DMA) request associated with a virtual machine (VM), indicating at the input-output memory management unit (IOMMU) that the VM is the target of an attack based on a security indicator field associated with an address space identifier (ASID) assigned to the VM, thereby preventing the execution of the received MMIO request or DMA request. In one aspect, the method includes: in response to the security indicator field indicating that the VM is not the target of an attack, having the IOMMU execute the received MMIO request or DMA request. In another aspect, the method 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 is the target of an attack.

[0046] In one aspect, the security indicator field is within 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 will not be executed. In yet another aspect, the security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed. In yet another aspect, the method includes modifying one or more bits in the security indicator field to indicate that the VM is not the target of the attack.

[0047] In some implementations, a method includes preventing the execution of memory-mapped input / output (MMIO) requests or direct memory access (DMA) requests against the VM at an input-output memory management unit (IOMMU) in response to a security indicator field associated with an address space identifier (ASID) assigned to a first virtual machine (VM) indicating that the VM is the target of an attack. In one aspect, the method includes executing an MMIO request or DMA request against the VM at the IOMMU in response to a security indicator field indicating that the VM is not the target of an attack. In another aspect, the method includes modifying one or more bits of the security indicator field to indicate that the VM is the target of an 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) device associated with the VM will not be executed.

[0048] In one aspect, the security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed. In another aspect, the security indicator field resides within 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 is not the target of an attack.

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

[0050] In one respect, the security indicator field is within an ASID mask table maintained by the IOMMU. In another respect, the security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed. In yet another respect, the security indicator field includes data indicating that all DMA requests associated with the VM will not be executed.

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

[0052] Computer-readable storage media can include any non-transitory storage medium or a 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 can include, but are not limited to, optical media (e.g., optical discs (CDs), digital versatile optical discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or microelectromechanical systems (MEMS) based storage media. Computer-readable storage media can be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard disk drive), removably attached to a computing system (e.g., an optical disc or a flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0053] In some implementations, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing the software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate 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, disk or optical disk storage devices, solid-state storage devices such as flash memory, cache memory, random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or another instruction format that is interpreted or otherwise executed by one or more processors.

[0054] It should be noted that not all activities or elements described above in the general description are essential. A particular activity or part of the apparatus may not be essential, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, these concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of this disclosure as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0055] The benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may lead to or make any benefit, advantage, or solution appear or become more significant should not be construed as key, essential, or fundamental features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be apparent to those skilled in the art who benefit from the teachings herein. No limitation is intended on the details of the constructions or designs shown herein, except as described in the following claims. Therefore, it will be apparent that the specific embodiments disclosed above can be changed or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is set forth in the following claims.

Claims

1. A method, the 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), the input-output memory management unit (IOMMU) indicates that the VM is the target of an attack based on a security indicator field associated with the address space identifier (ASID) assigned to the VM, preventing the execution of the received MMIO request or DMA request.

2. The method according to claim 1, further comprising: In response to the security indicator field indicating that the VM is not the target of an attack, the IOMMU executes the received MMIO request or DMA request.

3. The method according to claim 1 or claim 2, wherein the method further comprises: In response to a transmission failure associated with the VM, one or more bits of the security indicator field are modified to indicate that the VM is the target of an attack.

4. The method according to any one of claims 1 to 3, wherein, The security indicator field is located in the ASID mask table maintained by the IOMMU.

5. The method according to any one of claims 1 to 4, wherein, The security indicator field includes data indicating that all DMA requests associated with the VM will not be executed.

6. The method according to any one of claims 1 to 5, wherein, The security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed.

7. The method according to any one of claims 1 to 6, the method further comprising: Modify one or more bits in the security indicator field to indicate that the VM is not the target of the attack.

8. A method, the method comprising: In response to a security indicator field associated with the address space identifier (ASID) assigned to the first virtual machine (VM) indicating that the VM is the target of an attack, the execution of memory-mapped input / output (MMIO) requests or direct memory access (DMA) requests against the VM is prevented at the input-output memory management unit (IOMMU).

9. The method according to claim 8, further comprising: In response to the security indicator field indicating that the VM is not the target of an attack, the MMIO request or the DMA request for the VM is executed at the IOMMU.

10. The method according to claim 8 or claim 9, wherein the method further comprises: In response to a transmission failure associated with the VM, one or more bits of the security indicator field are modified to indicate that the VM is the target of an attack.

11. The method according to any one of claims 8 to 10, wherein, The security indicator field includes data indicating that all DMA requests from a specified input / output (I / O) device associated with the VM will not be executed.

12. The method according to any one of claims 8 to 11, wherein, The security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed.

13. The method according to any one of claims 8 to 12, wherein, The security indicator field is located in the ASID mask table maintained by the IOMMU.

14. The method according to any one of claims 8 to 13, the method further comprising: Modify one or more bits of the security indicator field to indicate that the VM is not the target of the attack.

15. A processor, the processor comprising: Input-output memory management unit (IOMMU), the IOMMU being configured to: In response to receiving a memory-mapped input / output (MMIO) request or direct memory access (DMA) request associated with a virtual machine (VM), the received MMIO request or DMA request is prevented from being executed based on a security indicator field associated with the address space identifier (ASID) assigned to the VM indicating that the VM is the target of an attack.

16. The processor of claim 15, wherein, The IOMMU is configured as follows: In response to the security indicator field indicating that the VM is not the target of an attack, the received MMIO request or DMA request is executed.

17. The processor according to claim 15 or claim 16, wherein, The IOMMU is configured as follows: In response to a transmission failure associated with the VM, one or more bits of the security indicator field are modified to indicate that the VM is the target of an attack.

18. The processor according to any one of claims 15 to 17, wherein, The security indicator field is located in the ASID mask table maintained by the IOMMU.

19. The processor according to any one of claims 15 to 18, wherein, The security indicator field includes data indicating that all MMIO requests associated with the VM will not be executed.

20. The processor according to any one of claims 15 to 19, wherein, The security indicator field includes data indicating that all DMA requests associated with the VM will not be executed.

Images