Secure memory mapping input / output

Abstract

A processor [101] manages memory map input / output (MMIO) accesses in a secure manner at an input / output memory management unit (IOMMU) [110]. The processor is configured to ensure, for a given MMIO request [111] issued by the processor core and associated with a particular executing VM [106], that request is targeted for an MMIO address that has been assigned to the VM by a secure module (e.g., a secure coprocessor [104]). Thus, the processor prevents malicious entities from requesting access to confidential information of the VM via the MMIO.

Description

Background Technology

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

[0002] Because different VMs are often owned by different entities, some confidential computing systems support security features that prevent one VM from accessing data or other information associated with another VM. However, in some cases, the confidential information of a VM can be accessed directly via the input / output devices that interact with that VM, or by observing the behavior of the VM in response to the activities performed by those input / output devices. Attached Figure Description

[0003] This disclosure can be better understood by referring to the accompanying drawings, and its many 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.

[0004] Figure 1 This is a block diagram of a processing system that uses an Input / Output Memory Management Unit (IOMMU) to manage Secure Memory Mapped Input / Output (MMIO) according to some implementation schemes.

[0005] Figure 2 It is based on some implementation plans. Figure 1 The IOMMU uses a block diagram of an example mapping table to manage secure MMIO requests.

[0006] Figure 3 This illustrates, according to some implementation schemes, how to prevent the execution of MMIO requests associated with a virtual machine when the MMIO request targets a memory address outside a specified range. Figure 1 A block diagram of an example of IOMMU.

[0007] Figure 4 This illustrates how to manage MMIO access to multiple virtual machines according to some implementation schemes. Figure 1 A block diagram of an example of IOMMU.

[0008] Figure 5 This is a flowchart illustrating a method for managing secure MMIO access at the IOMMU, based on some implementation schemes. Detailed Implementation

[0009] Figures 1 to 5 This paper illustrates techniques for securely managing MMIO access at the processing system, according to some implementation schemes. A processor, including an Input / Output Memory Management Unit (IOMMU), is configured to ensure that for a given MMIO request issued by the processor core and associated with a specific execution VM, the request targets an MMIO address already assigned to that VM by a security module (e.g., a security coprocessor). Therefore, the processor prevents malicious entities from accessing confidential information of the VM via MMIO requests.

[0010] To further illustrate this point by example, in some processing systems, the processor core accesses I / O devices by issuing MMIO requests, where each MMIO request identifies a memory address from which data is to be read, a memory address from which data is to be written, or a combination thereof. For example, in some cases, the processor core programs a register by issuing an MMIO request to write data to a memory address associated with a specific register of the I / O device. By using memory addresses to provide information to or retrieve information from I / O devices, the processor core can improve its overall efficiency using a relatively simple set of access commands and by leveraging at least some of the hardware used for accessing system memory. To improve processing efficiency, the processing system's IOMMU assists in executing MMIO requests. However, in at least some cases, MMIO requests make the processing system's secure data vulnerable to unauthorized access or modification. For example, a malicious entity could use MMIO requests to program registers or other portions of an I / O device assigned to the execution VM, thereby gaining access to confidential information. For example, a malicious entity could use MMIO requests to write data to the registers of the I / O device assigned to the execution VM, thereby requiring the VM to take remedial action that exposes the VM's behavior to unauthorized checks.

[0011] To prevent these and similar attacks by malicious entities, processing systems using the techniques described herein employ secure hardware to ensure that each MMIO request associated with a VM targets memory already assigned to that VM. For example, in some implementations, a security module of the processing system (e.g., a security coprocessor) implements a designated device binding process (e.g., a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) process) to bind I / O devices to the VM. The binding process implements designated procedures, such as an authentication process, that allow the VM to "trust" the I / O devices, i.e., assuming that the operation of the I / O devices is secure and unlikely to lead to the exposure of confidential VM information. Furthermore, the security module assigns a corresponding memory address space to each executing VM, which corresponds to both a region of system memory and a set of memory-mapped I / O devices within which the VM is exclusively permitted to write or read data.

[0012] In response to receiving an MMIO request from the processor core, the IOMMU determines the VM associated with the request, such as by determining the VM identifier (VMID) from the MMIO request itself. The IOMMU then determines whether the MMIO request targets a memory address assigned to the VM by a security module. If not, the IOMMU blocks the execution of the MMIO request as described herein, such as by preventing memory address-to-physical address translation. If the memory address targeted by the MMIO request is assigned to a VM, the IOMMU executes the MMIO request. Therefore, using the techniques described herein, when an MMIO request targets a memory address not assigned to a VM, the IOMMU prevents the execution of the MMIO request on behalf of that VM. 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 hypervisors or other entities to interfere with those operations, thereby supporting secure MMIO access in confidential computing environments.

[0013] Figure 1 A processing system 100 according to some embodiments is illustrated. 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. 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.

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

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

[0016] To execute instruction sets and corresponding operations, processor 101 includes processor core 102, security module 104, and input / output memory management unit. It should be understood that in some embodiments, processor 101 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 graphics processing units), one or more controllers (e.g., memory controllers and input / output controllers), etc.

[0017] Processor core 102 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 102 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, etc. Processor core 102 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 102 includes or has access to one or more cache structures to store data for executing instructions.

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

[0019] In some implementations, security module 104 manages the device binding process, where an I / O device is bound to a VM by undergoing a specified security registration process. For example, in some implementations, VM 106 seeks to bind I / O device 108 by sending a binding request to security module 104. In response, security module 104 initiates a specified security registration process, such as by requesting authentication information (e.g., a device certificate) from I / O device 108 and verifying that authentication information (e.g., by comparing the authentication information or key information generated based on the authentication information with one or more security keys). If the authentication information received from I / O device 108 is verified, security module 104 instructs VM 106 and other components of processor 101, as further described herein, that I / O device 108 is bound to VM 106.

[0020] It should be understood that in some implementations, an I / O device can be bound to multiple virtual machines by undergoing a specified security registration process for that VM. For example, in some implementations, each virtual machine uses a different virtual function (VF) to interact with the physical I / O device, thereby allowing the I / O device to be virtualized as a different virtual I / O device for each VM. In some implementations, security module 104 binds the I / O device to the VM by binding the corresponding VF to the VM, thereby allowing a single physical I / O device to be bound to multiple VMs (provided that the physical I / O device undergoes a security registration process for each VM).

[0021] As noted above, processing system 100 is typically configured to implement a confidential computing environment and is specifically configured to execute multiple virtual machines (VMs) (e.g., VM 106) (also referred to as guests) and a hypervisor 107 (also referred to as the host) to manage the execution of the multiple VMs. Since the different VMs and, in at least some cases, the hypervisor 107 are owned by different entities, processing system 100 implements security features to protect the data of a given VM from access by other software (such as another VM or hypervisor 107). For example, processing system 100 achieves VM data security by implementing a secure area 120 in memory 103 for storing encrypted data. Specifically, processor 101 is configured to encrypt designated data for each VM according to a corresponding private cryptographic key and store the encrypted data in secure area 120. Because the data is encrypted, the data of a VM is protected from unauthorized access by other VMs and hypervisor 107. In at least some embodiments, the cryptographic key for the VM is managed by security module 104, and the encryption and decryption of the data for the VM is performed by a dedicated hardware encryption / decryption module (not shown) at the memory controller (not shown) of processor 101.

[0022] To improve processing efficiency, IOMMU 110 is typically configured to perform specified memory access operations on behalf of processor 101. This means that dedicated hardware of IOMMU 110 is used to perform memory access operations, and processor 101 does not need to manage the memory access operations. Specifically, IOMMU 110 includes dedicated hardware for performing MMIO operations, where a processor core (such as processor core 102) generates MMIO requests (e.g., MMIO request 111) while executing a VM to read data from an I / O device (e.g., I / O device 108), write data to an I / O device, or a combination thereof. In some implementations, each MMIO request indicates a virtual address of a register or other memory location of the I / O device to be accessed—that is, a virtual address of a register or other memory location from which data is to be read, a virtual address of a register or other memory location to which data is to be written, or both. IOMMU 110 is typically configured to interact with I / O devices to perform one or more operations (read operations, write operations, or combinations thereof) indicated by the MMIO requests.

[0023] Because MMIO requests are executed independently of the operation of processor 101 in at least some cases, they provide a means for malicious entities to access confidential information associated with the VM executing at processor 101. For example, a malicious entity (or an I / O device controlled by a malicious entity) could issue an MMIO request targeting registers or storage locations that have not yet been assigned to VM 106 while VM 106 is executing, thereby exposing confidential data of VM 106 to unauthorized access, or triggering behavior of VM 106 (e.g., to manage I / O devices programmed via a malicious MMIO request), which could then potentially expose confidential information to the malicious entity.

[0024] To address these potential vulnerabilities, the IOMMU 110 maintains a mapping table 109, which indicates a set of memory addresses assigned to each VM, including memory addresses associated with registers or other memory locations. Although in Figure 1 In the example, mapping table 109 is illustrated as part of IOMMU 110; however, in some embodiments, mapping table 109 is stored in a secure region 120 of memory 103, and IOMMU 110 reads portions of mapping table 109 from this secure region as needed to perform operations further described herein. Furthermore, in some embodiments, IOMMU 110 caches portions of mapping table 109 to improve performance.

[0025] Mapping table 109 stores information such as I / O device root port number (e.g., PCIe root port number), data stream identifier (e.g., PCIe IDE stream ID), and MMIO address range, which is used by processor 101 to determine whether to allow MMIO request 111, as further described below. These determinations are performed by the security hardware of processor 101, and specifically by the security hardware located at processor core 102 (specifying MMIO security 117) and the security hardware located at IOMMU 110 (specifying MMIO security 118). For the purposes described below, it is assumed that the security operation associated with the MMIO request is performed by MMIO security 118 at IOMMU 110. However, it should be understood that in other embodiments, one or more of the security operations described are performed by MMIO security 117 at processor 101.

[0026] For illustration, in some embodiments, when execution of a VM is initiated, security module 104 determines a set of memory addresses to be assigned to the VM, the set of memory addresses including both memory addresses associated with memory 103 and memory addresses associated with registers and other storage locations of I / O devices (such as I / O device 108). Security module 104 ensures that two VMs are not assigned to the same (or overlapping) portions of the set of memory addresses. Security module 104 indicates the assigned memory addresses to IOMMU 110, which stores information indicating the assigned portion (e.g., by storing the set of memory addresses indicating the assigned portion) at mapping table 109. In some embodiments, security module 104 also determines port numbers (e.g., PCIe port numbers of VMs assigned to one or more I / O devices) and stores these port numbers at mapping table 109.

[0027] Furthermore, in some implementations, processor 101 is configured to communicate with I / O devices (such as I / O device 108) via multiple encrypted data streams (such as PCIe Integrity and Data Encryption (IDE) data streams). Each of these encrypted data streams is assigned a corresponding stream identifier according to the communication protocol governing the communication between processor 101 and the I / O device (e.g., the PCIe protocol). Security module 104 determines the encrypted stream identifier assigned to each VM for communication with the corresponding I / O device and stores this encrypted stream identifier at mapping table 109.

[0028] In response to receiving an MMIO request, MMIO security 118 determines (e.g., based on fields of the MMIO request) the VM associated with the request. For example, in some embodiments, each MMIO request includes a VM identifier (e.g., VMID) indicating that the VM initiating the MMIO request has been issued. MMIO security 118 determines whether the MMIO request targets a memory address within a set of memory addresses assigned to a VM, as indicated by mapping table 109.

[0029] For illustration, in some implementations, an MMIO request indicates a virtual address to be read, written, or a combination thereof. MMIO security 118 compares the virtual address indicated by the MMIO request and determines whether the virtual address is within the set assigned to the corresponding VM, as indicated by mapping table 109. If the virtual address falls outside the set of addresses assigned to the VM, or if the mapping of the virtual address is invalid, MMIO security 118 prevents the execution of the MMIO request, such as by stopping or not initiating the translation from virtual address to physical address set. If the virtual address indicated by the MMIO request is within the set of memory addresses assigned to the VM (and any other security checks pass), MMIO security 118 executes the MMIO request. In some implementations, IOMMU 110 (or other circuitry) translates the virtual address targeted by the MMIO request into a physical address and compares that physical address with the set of physical addresses assigned to the corresponding VM. Therefore, MMIO security 118 ensures that an MMIO request is satisfied only if it targets a memory address (virtual or physical) assigned to the VM and the virtual-to-physical address mapping is valid. Thus, IOMMU 110 prevents malicious entities from accessing confidential VM information via MMIO requests.

[0030] In some implementations, MMIO security 118 performs additional security checks and processing on each MMIO request. For example, in some implementations, each MMIO request indicates the port number (e.g., a PCIe port number) that the request targets. MMIO security 118 compares the port number of the MMIO request with the port number assigned to the VM, as indicated by mapping table 109. If the port number indicated by the MMIO request is not assigned to the VM (e.g., due to a change in the address mapping of the root port), MMIO security 118 blocks the execution of the MMIO request. If the port number indicated by the MMIO request is assigned to the VM, and any other security checks pass, MMIO security 118 executes the MMIO request.

[0031] In some implementations, in response to determining that all security checks have passed and that an MMIO request will be executed, MMIO security 118 selects one of a plurality of encrypted data streams (e.g., PCIe IDE data streams) based on a data stream identifier stored in mapping table 109. MMIO security 118 instructs IOMMU 110 to use the selected encrypted data stream to execute the MMIO request. Therefore, the selection of the encrypted data stream used to execute the MMIO request is made by the security hardware of processor 101 rather than by the hypervisor or VM, thereby protecting the VM's security information from exploitation via the MMIO request.

[0032] Figure 2 An example of a mapping table 109 according to some implementation schemes is illustrated. In the depicted example, mapping table 109 includes multiple entries (e.g., entry 220, entry 221), each of which is assigned to a different VM, such as a VM currently executing at processor 101, a VM that has already undergone a VM provisioning process at processing system 100 (and is therefore expected to execute at processing system 100 in response to a VMRUN command), or any combination thereof.

[0033] Each entry in mapping table 109 includes multiple fields, including a VM identifier field 225, a bound device field 226, an assigned address field 227, and an address mapping field 228. The VM identifier field 225 stores (e.g., by security module 104) a virtual machine identifier (VMID) assigned to the VM associated with the corresponding entry. In other words, the VM identifier field of an entry stores a value called VMID, which indicates the VM corresponding to that entry.

[0034] The Binding Device field 226 of an entry stores a value or set of values ​​indicating identification information for each I / O device that has been bound by the security module 104 to the corresponding VM. For example, in some embodiments, the Binding Device field stores a root port number, such as a PCIe root port number, indicating the port of the processor 101 associated with the corresponding VM (i.e., the port the request is expected to use to reach the device with the target MMIO address). In some embodiments, the Binding Device field 226 also stores a stream identifier (e.g., a PCIe StreamID) that identifies an encrypted data stream between the root port and the corresponding I / O device. In some embodiments, in response to the I / O device successfully completing the specified security procedure for binding, the security module 104 sends a message to the IOMMU 110 indicating: 1) the identification information (e.g., root number) of the I / O device that has been bound; and 2) the VMID of the VM that has been bound to the I / O device. In response, the IOMMU 110 updates the Binding Device field 226 of the corresponding entry to reflect the indicated information.

[0035] The assignment address field 227 indicates a set of memory addresses to be assigned to the corresponding VM, including addresses associated with registers or other storage locations of I / O devices (e.g., I / O device 108). In some embodiments, when execution of the VM is initiated (e.g., via a VMRUN command), the security module 104 determines the set of memory addresses to be assigned to the VM. The security module 104 indicates the assigned set of memory addresses to the IOMMU 110, which stores information indicating the assigned set (e.g., by storing the set of memory addresses indicating the assigned portion) at the assignment address field 227 of the corresponding entry in the mapping table 109. The address mapping field 228 stores a set of address maps for the VMs corresponding to the entries in the mapping table 109.

[0036] Figure 3 An example is illustrated of an IOMMU 110 using mapping table 109 to prevent the execution of MMIO request 111 according to some implementations. In the illustrated example, IOMMU 110 receives MMIO request 111 from processor core 102. MMIO request 111 includes a request (e.g., MOV instruction) to load data from a memory (MMIO) address into a processor register (MMIO read) or to store data by copying data from a processor register to an MMIO address (MMIO write). That is, processor core 102 indicates the memory address targeted by the request via fields of MMIO request 111 to read, write, or transfer (read and write) data on behalf of VM 106.

[0037] In response to receiving MMIO request 111, MMIO security 118 accesses mapping table 109, specifically mapping the entry in table 109 corresponding to VM 106. Then, MMIO security 118 compares the memory address indicated by MMIO request 111 with the memory address indicated by the assignment address field 227 of the entry in mapping table 109. Figure 3In the example, assume that the memory address indicated by MMIO request 111 falls outside the set of memory addresses stored in the assignment address field 227. That is, MMIO request 111 targets a memory address that has not yet been assigned to VM 106. In response to determining that MMIO request 111 targets a memory address outside of assignment address field 227, MMIO security 118 blocks execution of MMIO request 111 and notifies processor core 102 that MMIO request 111 has been rejected by sending message 342. In some implementations, MMIO security 118 also determines whether the address indicated by MMIO request 111 has a valid mapping based on address mapping field 228. If not, MMIO security 118 blocks execution of MMIO request 111. In some implementations, MMIO security 118 also checks for each MMIO request whether the port number associated with the request matches a port number assigned to the VM, as indicated by mapping table 109. If the port number does not match the port number assigned to the VM, MMIO security 118 rejects (e.g., aborts) the MMIO request.

[0038] As noted above, mapping table 109 stores individual entries for each VM executed at processor 101. This allows IOMMU 110 to individually allow or deny MMIO requests for different VMs, regardless of MMIO requests for other VMs. Figure 4 Examples based on some implementation schemes are shown below. For Figure 4 For example, suppose processor 101 is executing two different VMs: VM 106 and VM 450. IOMMU 110 receives MMIO request 111 from processor core 102, which indicates a request to access registers or other memory locations of I / O devices on behalf of VM 106. Further suppose that mapping table 109 indicates that MMIO request 111 targets a memory address that has not yet been assigned to VM 106. Therefore, MMIO security 118 prevents execution of MMIO request 111 and (via message 342) indicates that MMIO request 111 has been rejected.

[0039] Regarding MMIO request 451, it is assumed that mapping table 109 indicates that MMIO request 451 targets a memory address that has already been assigned to VM 550. Therefore, MMIO security 118 determines that MMIO request 451 is permitted (as indicated by message 455), and thus IOMMU 110 executes MMIO request 451. In some implementations, MMIO security 118 selects an encrypted data stream to execute MMIO request 111 based on the stream identifier stored in mapping table 109. Therefore, in Figure 4In the example, MMIO security 118 selectively allows some MMIO requests and denies others, thereby preventing malicious actors from stopping or slowing down the execution of multiple VMs at processing system 100 by issuing incorrect MMIO requests.

[0040] Figure 5 A flowchart illustrating method 500 for managing secure MMIO access at the IOMMU according to some implementation schemes is provided. For descriptive purposes, see references. Figure 1 Method 500 is described using an example implementation at processing system 100, but it should be understood that in other implementations, method 500 is implemented at processing systems with different configurations. At block 502, security module 104 binds one or more I / O devices to VM 106 according to a specified security procedure, such as a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) procedure. For example, in some implementations, processing system 100 includes a communication architecture (not shown) conforming to the Peripheral Component Rapid Interconnect (PCIe) communication protocol. Specifically, I / O devices (such as I / O device 108) are configured to communicate with processor 101 and IOMMU 110 according to the PCIe communication protocol. In some implementations, the PCIe communication protocol establishes a TDISP security registration procedure for binding I / O devices to VMs, and security module 104 uses the TDISP security registration procedure to bind I / O devices to execution VMs. Furthermore, at block 502, security module 104 assigns a set of memory addresses to the corresponding execution VMs. Security module 104 programs mapping table 109 to store indications of I / O devices bound to each VM, such as by storing a set of port numbers (e.g., PCIe port numbers) and memory addresses assigned to each VM. In some embodiments, security module 104 also determines the encrypted communication streams (e.g., PCIe IDE streams) assigned to each VM and stores the stream identifiers of the assigned communication streams at mapping table 109.

[0041] At box 504, IOMMU 110 receives MMIO request 111 from I / O device 108. MMIO request 111 includes an identifier of the VM associated with the request and address information indicating the memory address targeted by the request. At box 506, MMIO security 118 determines whether MMIO request 111 is targeted at a memory address assigned to the corresponding VM. If not, the method flow moves to box 508, and IOMMU 110 prevents execution of MMIO request 111. The method flow then returns to box 504.

[0042] If at box 506, MMIO security 118 determines that MMIO request 111 does indeed target a memory address assigned to the corresponding VM, the method flow moves to box 509, and MMIO security 118 determines whether the port number indicated by MMIO request 111 matches the port number assigned to the corresponding VM, as indicated by mapping table 109. For example, in some implementations, the port targeted by the MMIO request (e.g., a PCIe port) is selected based on the physical MMIO address. That is, each port is associated with a range of physical addresses. MMIO security checks whether the port number selected based on the physical address matches the port number identified in the mapping table entry corresponding to the same physical address. If not, the method flow moves to box 508, and IOMMU 110 blocks the execution of MMIO request 111. The method flow then returns to box 504. In some implementations, the port number is not specifically assigned to the VM. For example, in some implementations, a single PCIe port supports MMIO requests belonging to multiple VMs, all of which target different MMIO address ranges on the I / O device (e.g., MMIOs belong to different virtual functions).

[0043] If, at box 509, MMIO security 118 determines that the port number indicated by the MMIO request matches the port number assigned to the corresponding VM, the method flow moves to box 510, and MMIO security 118 selects an encrypted data stream based on mapping table 109. MMIO security 118 instructs the IOMMU to execute MMIO request 111 using the selected encrypted data stream. The method flow then returns to box 504.

[0044] As disclosed herein, in some embodiments, a method includes: in response to receiving a first memory-mapped input / output (MMIO) request associated with a first virtual machine (VM), identifying whether the first MMIO request targets at least one memory address in a set of memory addresses assigned to the first VM; and blocking execution of the first MMIO request in response to identifying that the first MMIO request targets a memory address outside the set of memory addresses assigned to the first VM. In one aspect, the method includes: in response to receiving a second MMIO request associated with the first VM from a second device, identifying whether the second MMIO request targets the set of memory addresses assigned to the first VM; and executing the second MMIO request at an input / output memory management unit (IOMMU) in response to identifying that the second MMIO request targets the set of memory addresses assigned to the first VM. In another aspect, the method includes: receiving the set of memory addresses assigned to the first VM from a security coprocessor configured to execute the first VM.

[0045] In one aspect, the method includes: blocking execution of the first MMIO request in response to identifying that the first MMIO request targets a port number of the set not assigned to a memory address. In another aspect, the method includes: in response to receiving a second MMIO request associated with a second VM from a second device, identifying whether the second MMIO request targets at least one memory address in the set of memory addresses assigned to the second VM; and blocking execution of the second MMIO request in response to identifying that the second MMIO request targets a memory address outside the set of memory addresses assigned to the second VM. In yet another aspect, the first MMIO request targets an input / output device. In yet another aspect, the method includes: selecting an encrypted data stream to execute the first MMIO request in response to identifying that the first MMIO request targets a memory address assigned to the first VM.

[0046] In some implementations, a method includes: blocking the execution of a first MMIO request for a first virtual machine (VM) that targets at least one memory address outside a first set of memory addresses assigned to the first VM. In one aspect, the method includes: executing a second MMIO request at an input / output memory management unit (IOMMU) in response to a second MMIO request for the first VM that targets at least one memory address within the first set of memory addresses assigned to the first VM. In yet another aspect, the method includes: blocking the execution of a third MMIO request for a second virtual machine (VM) that targets at least one memory address outside a second set of memory addresses assigned to the second VM.

[0047] In one aspect, the method includes: blocking execution of the first MMIO request in response to the first MMIO request targeting a communication port not assigned to the first VM. In another aspect, the method includes: receiving the first set of memory addresses assigned to the first VM from a security coprocessor configured to execute the first VM. In yet another aspect, the method includes: determining the first set of memory addresses assigned to the first VM based on a mapping table that maps addresses associated with the first VM. In yet another aspect, the mapping table is cached at the IOMMU.

[0048] In some implementations, a method includes: an input / output memory management unit (IOMMU); and security hardware configured to: in response to receiving a first memory-mapped input / output (MMIO) request associated with a first virtual machine (VM), identify whether the first MMIO request targets at least one memory address in a set of memory addresses assigned to the first VM; and block execution of the first MMIO request in response to identifying that the first MMIO request targets a memory address outside the set of memory addresses assigned to the first VM. In one aspect, the security hardware is configured to: in response to receiving a second MMIO request associated with the first VM from a second device, identify whether the second MMIO request targets the set of memory addresses assigned to the first VM; and execute the second MMIO request in response to identifying that the second MMIO request targets the set of memory addresses assigned to the first VM. In another aspect, the security hardware is configured to: receive the set of memory addresses assigned to the first VM from a security coprocessor of the processor.

[0049] In one aspect, the security hardware is configured to: block execution of the first MMIO request in response to identifying that the first MMIO request targets a port number in the set not assigned to a memory address. In another aspect, the security hardware is configured to: in response to receiving a second MMIO request associated with a second VM from a second device, identify whether the second MMIO request targets at least one memory address in the set of memory addresses assigned to the second VM; and block execution of the second MMIO request in response to identifying that the second MMIO request targets a memory address outside the set of memory addresses assigned to the second VM. In yet another aspect, the security hardware is configured to: select an encrypted data stream to execute the first MMIO request in response to identifying that the first MMIO request targets a memory address assigned to the first VM.

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

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

[0052] 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 more significant any benefit, advantage, or solution 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 altered or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the following claims.

Claims

1. A method, the method comprising: In response to receiving a first memory-mapped input / output (MMIO) request associated with a first virtual machine (VM), it is identified whether the first MMIO request targets at least one memory address in a set of memory addresses assigned to the first VM; as well as In response to identifying that the first MMIO request targets a memory address outside the set of memory addresses assigned to the first VM, the execution of the first MMIO request is blocked.

2. The method according to claim 1, further comprising: In response to receiving a second MMIO request associated with the first VM from the second device, it is identified whether the second MMIO request targets the set of memory addresses assigned to the first VM; as well as The second MMIO request is executed at the Input / Output Memory Management Unit (IOMMU) in response to the identification that the second MMIO request targets the set of memory addresses assigned to the first VM.

3. The method according to claim 1 or claim 2, further comprising: The set of memory addresses assigned to the first VM is received from the security coprocessor of the processor configured to execute the first VM.

4. The method according to any one of claims 1 to 3, further comprising: In response to identifying that the first MMIO request targets a port number of the set that has not been assigned a memory address, the execution of the first MMIO request is blocked.

5. The method according to any one of claims 1 to 4, further comprising: In response to receiving a second MMIO request associated with a second VM from a second device, it is identified whether the second MMIO request targets at least one memory address in a set of memory addresses assigned to the second VM; as well as In response to identifying that the second MMIO request targets a memory address outside the set of memory addresses assigned to the second VM, execution of the second MMIO request is blocked.

6. The method according to any one of claims 1 to 5, wherein the first MMIO request is targeted at an input / output device.

7. The method according to any one of claims 1 to 6, further comprising: In response to identifying that the first MMIO request targets a memory address assigned to the first VM, an encrypted data stream is selected to execute the first MMIO request.

8. A method, the method comprising: In response to a first MMIO request for a first virtual machine (VM) targeting at least one memory address outside the first set of memory addresses assigned to the first VM, the execution of the first MMIO request is blocked.

9. The method according to claim 8, further comprising: In response to a second MMIO request for the first VM, the second MMIO request is executed at the Input / Output Memory Management Unit (IOMMU) with at least one memory address in the first set of memory addresses assigned to the first VM as the target.

10. The method according to claim 9, further comprising: In response to a third MMIO request for a second virtual machine (VM) targeting at least one memory address outside the second set of memory addresses assigned to the second VM, the execution of the third MMIO request is blocked.

11. The method according to any one of claims 8 to 10, the method further comprising: In response to the first MMIO request targeting the first virtual machine (VM) being targeted at a communication port not assigned to the first VM, the execution of the first MMIO request is blocked.

12. The method according to any one of claims 8 to 11, further comprising: The first set of memory addresses assigned to the first VM is received from the security coprocessor of the processor configured to execute the first VM.

13. The method according to any one of claims 8 to 12, further comprising: The first set of first memory addresses to be assigned to the first VM is determined based on a mapping table that maps addresses associated with the first VM.

14. The method of claim 13, wherein the mapping table is cached at the IOMMU.

15. A processor, the processor comprising: Input / output memory management unit (IOMMU); and Security hardware, the security hardware being configured as follows: In response to receiving a first memory-mapped input / output (MMIO) request associated with a first virtual machine (VM), the system identifies whether the first MMIO request targets at least one memory address in the set of memory addresses assigned to the first VM, and blocks the execution of the first MMIO request in response to identifying that the first MMIO request targets a memory address outside the set of memory addresses assigned to the first VM.

16. The processor of claim 15, wherein the security hardware is configured to: In response to receiving a second MMIO request associated with the first VM from the second device, it is identified whether the second MMIO request targets the set of memory addresses assigned to the first VM; and The second MMIO request is executed in response to the identification that the second MMIO request targets the set of memory addresses assigned to the first VM.

17. The processor of claim 15 or claim 16, wherein the security hardware is configured to: The set of memory addresses assigned to the first VM is received from the processor's security coprocessor.

18. The processor according to any one of claims 15 to 17, wherein the security hardware is configured to: In response to identifying that the first MMIO request targets a port number of the set that has not been assigned a memory address, the execution of the first MMIO request is blocked.

19. The processor according to any one of claims 15 to 18, wherein the security hardware is configured to: In response to receiving a second MMIO request associated with the second VM from the second device, it is identified whether the second MMIO request targets at least one memory address in the set of memory addresses assigned to the second VM; and In response to identifying that the second MMIO request targets a memory address outside the set of memory addresses assigned to the second VM, execution of the second MMIO request is blocked.

20. The processor according to any one of claims 15 to 19, wherein the security hardware is configured to: In response to identifying that the first MMIO request targets a memory address assigned to the first VM, an encrypted data stream is selected to execute the first MMIO request.

Images