Secure memory-mapped input / output

Abstract

The processor [101] manages memory-mapped input / output (MMIO) accesses in a secure manner in an input / output memory management unit (IOMMU) [110]. The processor is configured to ensure that for a given MMIO request [111] issued by a processor core and associated with a particular running VM [106], the request targets an MMIO address assigned to the VM by a security module (e.g., a security coprocessor [104]). Thus, the processor prevents malicious entities from accessing sensitive information of the VM via the MMIO request.

Description

[Background technology]

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

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

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

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

[0005] 1-5 illustrate techniques for managing MMIO access in a secure manner in a processing system, according to some embodiments. A processor including an input / output memory management unit (IOMMU) is configured to ensure that, for a given MMIO request issued by a processor core and associated with a particular running VM, the request targets an MMIO address assigned to the VM by a security module (e.g., a security coprocessor). Thus, the processor prevents malicious entities from accessing sensitive information of the VM via the MMIO request.

[0006] To further illustrate, in some processing systems, a processor core accesses an I / O device by issuing MMIO requests, with each MMIO request identifying a memory address from which data is to be read, a memory address to which data is to be written, or a combination thereof. For example, in some cases, a processor core programs a particular register of an I / O device by issuing an MMIO request to write data to a memory address associated with the register. By using a memory address to provide information to or retrieve information from the I / O device, the processor core can interact with the I / O device using a relatively simple set of access commands and by leveraging at least some of the hardware used to access system memory, thereby improving the overall efficiency of the processor core. To increase processing efficiency, an IOMMU in a processing system assists in the execution of MMIO requests. However, in at least some cases, MMIO requests make secure data in the processing system vulnerable to unauthorized access or modification. For example, a malicious entity can use an MMIO request to program registers or other portions of an I / O device assigned to a running VM, thereby accessing sensitive information. As another example, a malicious entity can use an MMIO request to write data to a register of an I / O device assigned to a running VM, requesting the VM to take corrective action that exposes the VM's behavior to unauthorized inspection.

[0007] To prevent these and similar attacks by malicious entities, a processing system, using the techniques described herein, employs security hardware to ensure that each MMIO request associated with a VM targets memory allocated to the VM. For example, in some embodiments, a security module (e.g., a security coprocessor) of the processing system implements a designated device binding process (e.g., a Trusted Execution Environment (TEE) Device Interface Secure Protocol (TDISP) process) that binds I / O devices to a VM. The binding process implements designated processes, such as an authentication process, that allow the VM to “trust” the I / O device, i.e., to assume that the I / O device's operations are secure and unlikely to result in the disclosure of sensitive VM information. Furthermore, the security module assigns each running VM a corresponding memory address space that corresponds to both a region of system memory and a set of memory-mapped I / O devices to which the VM is exclusively permitted to write or read data.

[0008] In response to receiving an MMIO request from a processor core, the IOMMU determines the VM associated with the request, such as by determining a 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 the security module. If not, the IOMMU prevents execution of the MMIO request as described herein, such as by preventing translation of the memory address to a physical address. If the memory address targeted by the MMIO request is assigned to the VM, the IOMMU executes the MMIO request. Thus, using the techniques described herein, if the MMIO request targets a memory address not assigned to the VM, the IOMMU prevents execution of the MMIO request on behalf of the VM. Thus, the IOMMU prevents unauthorized access to or modification of sensitive information related to the VM. Furthermore, because these security operations are performed by the IOMMU itself, it is difficult for a hypervisor or other entity to interfere with these operations, thus supporting secure MMIO access in sensitive computing environments.

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

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

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

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

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

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

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

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

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

[0018] To increase processing efficiency, IOMMU 110 is generally configured to perform designated memory access operations on behalf of processor 101, i.e., to perform memory access operations using dedicated hardware in IOMMU 110 without requiring management of the memory access operations by processor 101. In particular, IOMMU 110 includes dedicated hardware for performing MMIO operations, and a processor core (such as processor core 102), when executing a VM, generates MMIO requests (e.g., MMIO request 111) 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 embodiments, each MMIO request indicates the virtual address of a register or other memory location of the I / O device being accessed, i.e., the virtual address of the register or other memory location from which data is read, the virtual address of the register or other memory location to which data is written, or both. IOMMU 110 is generally configured to interact with I / O devices to perform one or more operations (read operations, write operations, or a combination thereof) indicated by MMIO requests.

[0019] Because MMIO requests, in at least some cases, execute independently of the operation of processor 101, MMIO requests provide a means for a malicious entity to access sensitive information associated with a VM executing on processor 101. For example, a malicious entity (or an I / O device controlled by the malicious entity) can issue an MMIO request that targets a register or memory location not allocated to VM 106 when VM 106 is executing, thereby exposing sensitive data of VM 106 to unauthorized access or triggering behavior by VM 106 that can expose sensitive information to the malicious entity (e.g., to manage an I / O device programmed by the malicious MMIO request).

[0020] To address these potential vulnerabilities, IOMMU 110 maintains a mapping table 109 for each VM that indicates the set of memory addresses assigned to the VM, including memory addresses associated with registers or other storage locations. While in the example of FIG. 1 , mapping table 109 is shown as part of IOMMU 110, in some embodiments, mapping table 109 is stored in secure region 120 of memory 103, and IOMMU 110 reads portions of mapping table 109 from the secure region as needed to perform operations described further herein. Additionally, in some embodiments, IOMMU 110 caches portions of mapping table 109 to improve performance.

[0021] Mapping table 109 stores information such as an I / O device root port number (e.g., a PCIe root port number), a data stream identifier (e.g., a PCIe IDE Stream ID), and an MMIO address range that is used by processor 101 to determine whether to allow MMIO request 111 to be performed, as described further below. These determinations are performed by security hardware of processor 101, specifically security hardware located in processor core 102 (designated MMIO security 117) and security hardware located in IOMMU 110 (designated MMIO security 118). For purposes of the following description, it is assumed that security operations associated with an MMIO request are performed by MMIO security 118 in 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 in processor 101.

[0022] To illustrate, in some embodiments, when a VM begins execution, security module 104 determines a set of memory addresses to be assigned to the VM, 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 the same portion (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 in mapping table 109 (e.g., by storing a set of memory addresses indicating the assigned portion). In some embodiments, security module 104 determines port numbers (e.g., PCIe port numbers) assigned to the VM for one or more I / O devices and stores the port numbers in mapping table 109.

[0023] Additionally, in some embodiments, 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 a communications protocol (e.g., a PCIe protocol) that governs communications between processor 101 and the I / O devices. Security module 104 determines the encrypted stream identifier assigned to each VM for communicating with the corresponding I / O device and stores the encrypted stream identifier in mapping table 109.

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

[0025] To illustrate, in some embodiments, an MMIO request indicates a virtual address to be read from, written to, or a combination thereof. MMIO security 118 compares the virtual address indicated by the MMIO request to determine whether the virtual address is within the set allocated to the corresponding VM, as indicated by mapping table 109. If the virtual address is outside the VM's set of allocated addresses, or if the virtual address mapping is not valid, MMIO security 118 prevents execution of the MMIO request, such as by stopping or not starting the translation of the virtual address to the set of physical addresses. If the virtual address indicated by the MMIO request is within the VM's set of allocated memory addresses (and any other security checks pass), MMIO security 118 executes the MMIO request. In some embodiments, IOMMU 110 (or other circuitry) translates the virtual address targeted by the MMIO request to a physical address and compares the physical address to the set of physical addresses allocated to the corresponding VM. Thus, MMIO security 118 ensures that MMIO requests are satisfied only if they target memory addresses (either virtual or physical) assigned to the VM and the mapping of virtual addresses to physical addresses is valid. Thus, IOMMU 110 prevents malicious entities from accessing sensitive VM information via MMIO requests.

[0026] In some embodiments, MMIO security 118 performs additional security checks and processing for each MMIO request. For example, in some embodiments, each MMIO request indicates a port number (e.g., a PCIe port number) for which the request is targeted. MMIO security 118 compares the port number of the MMIO request with the port numbers 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 root port's address mapping), MMIO security 118 prevents the MMIO request from executing. If the port number indicated by the MMIO request is assigned to the VM and other security checks are passed, MMIO security 118 executes the MMIO request.

[0027] In some embodiments, in response to determining that all security checks have passed and that the MMIO request should be executed, MMIO security 118 selects one of a plurality of encrypted data streams (e.g., a PCIe IDE data stream) based on a data stream identifier stored in mapping table 109. MMIO security 118 instructs IOMMU 110 to execute the MMIO request using the selected encrypted data stream. Thus, the selection of the encrypted data stream for executing the MMIO request is selected by the security hardware of processor 101, rather than by the hypervisor or the VM, thereby protecting the VM's secure information from misuse via the MMIO request.

[0028] 2 illustrates an example of mapping table 109, according to some embodiments. In the illustrated example, mapping table 109 includes multiple entries (e.g., entry 220, entry 221), each of which is assigned to a different VM, such as a VM currently running on processor 101, a VM that has undergone a VM provisioning process on processing system 100 (and thus is expected to run on processing system 100 in response to a VMRUN command), or any combination thereof.

[0029] 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. VM identifier field 225 stores a virtual machine identifier (VMID) assigned (e.g., by security module 104) to the VM associated with the corresponding entry. That is, the VM identifier field of an entry stores a value called VMID that indicates the VM corresponding to that entry.

[0030] The bound devices field 226 of an entry stores a value or set of values ​​indicating the identity of each I / O device bound to the corresponding VM by security module 104. For example, in some embodiments, the bound devices field stores a root port number, such as a PCIe root port number, that indicates a port of processor 101 associated with the corresponding VM (i.e., the port a request is expected to take to reach the device owning the target MMIO address). In some embodiments, the bound devices field 226 stores a stream identifier (e.g., a PCIe stream ID) that identifies the encrypted data stream between the root port and the corresponding I / O device. In some embodiments, in response to an I / O device successfully completing the specified security process for binding, security module 104 sends a message to IOMMU 110 indicating 1) the identity (e.g., root number) of the bound I / O device and 2) the VM ID of the VM to which the I / O device is bound. In response, IOMMU 110 updates the bound devices field 226 of the corresponding entry to reflect the indicated information.

[0031] Allocated addresses field 227 indicates a set of memory addresses allocated 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 a VM begins execution (e.g., via a VMRUN command), security module 104 determines a set of memory addresses to be allocated to the VM. Security module 104 indicates the set of allocated memory addresses to IOMMU 110, which stores information indicating the allocated set (e.g., by storing the set of memory addresses indicating the allocated portion) in allocated addresses field 227 of the corresponding entry in mapping table 109. Address mapping field 228 stores a set of address mappings for the VM corresponding to the entry in mapping table 109.

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

[0033] In response to receiving MMIO request 111, MMIO security 118 accesses mapping table 109, particularly the entry in mapping table 109 that corresponds to VM 106. MMIO security 118 then compares the memory address indicated by MMIO request 111 with the memory address indicated by allocated address field 227 of the entry in mapping table 109. In the example of FIG. 3 , the memory address indicated by MMIO request 111 is assumed to be outside the set of memory addresses stored in allocated address field 227. That is, MMIO request 111 targets a memory address that is not allocated to VM 106. In response to determining that MMIO request 111 targets a memory address outside allocated address field 227, MMIO security 118 prevents execution of MMIO request 111 and notifies processor core 102 that MMIO request 111 has been denied by sending message 342. In some embodiments, MMIO security 118 determines whether the address indicated by MMIO request 111 has a valid mapping based on address mapping field 228. If not, MMIO security 118 prevents execution of MMIO request 111. In some embodiments, MMIO security 118 checks, for each MMIO request, whether the port number associated with the request matches the 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.

[0034] As described above, mapping table 109 stores an individual entry for each VM executing on processor 101. This allows IOMMU 110 to individually grant or deny MMIO requests for different VMs, independent of MMIO requests for other VMs. An example according to some embodiments is shown in FIG. 4. In the example of FIG. 4, assume that processor 101 is running two different VMs, namely VM 106 and VM 450. IOMMU 110 receives MMIO request 111 from processor core 102, indicating a request to access a register or other memory location of an I / O device on behalf of VM 106. Further assume that mapping table 109 indicates that MMIO request 111 targets a memory address not assigned to VM 106. Therefore, MMIO security 118 prevents MMIO request 111 from executing and indicates (via message 342) that MMIO request 111 has been denied.

[0035] With respect to MMIO request 451, assume that mapping table 109 indicates that MMIO request 451 targets a memory address 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 embodiments, MMIO security 118 selects an encrypted data stream for executing MMIO request 111 based on a stream identifier stored in mapping table 109. Thus, in the example of FIG. 4 , MMIO security 118 selectively permits some MMIO requests and denies other MMIO requests, thus preventing a malicious actor from stopping or slowing down the execution of multiple VMs in processing system 100 by issuing inappropriate MMIO requests.

[0036] FIG. 5 illustrates a flow diagram of a method 500 for managing secure MMIO access in an IOMMU, according to some embodiments. For illustrative purposes, method 500 is described with reference to an exemplary embodiment in processing system 100 of FIG. 1 , although it should be understood that in other embodiments, method 500 is implemented in processing systems having different configurations. At block 502, security module 104 binds one or more I / O devices to VM 106 according to a specified security process, such as a Trusted Execution Environment (TEE) Device Interface Secure Protocol (TDISP) process. For example, in some embodiments, processing system 100 includes a communications fabric (not shown) that conforms to the Peripheral Component Interconnect Express (PCIe) communications protocol. In particular, I / O devices, such as I / O device 108, are configured to communicate with processor 101 and IOMMU 110 according to the PCIe communications protocol. In some embodiments, the PCIe communication protocol establishes a TDISP security registration process for binding I / O devices to VMs, and the security module 104 binds the I / O devices to running VMs using the TDISP security registration process. Further, at block 502, the security module 104 assigns a set of memory addresses to each running VM. The security module 104 programs the mapping table 109 to store indicators of the I / O devices bound to each VM, such as by storing a port number (e.g., a PCIe port number) assigned to each VM and the set of memory addresses assigned to each VM. In some embodiments, the security module 104 determines an encrypted communication stream (e.g., a PCIe IDE stream) assigned to each VM and stores a stream identifier of the assigned communication stream in the mapping table 109.

[0037] At block 504, the IOMMU 110 receives an MMIO request 111 from the I / O device 108. The MMIO request 111 includes an identifier of a VM associated with the request and address information indicating the memory address to which the request is directed. At block 506, the MMIO security 118 determines whether the MMIO request 111 targets a memory address assigned to the corresponding VM. If not, method flow moves to block 508, where the IOMMU 110 prevents the MMIO request 111 from executing. Method flow then returns to block 504.

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

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

[0040] 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 of a set of memory addresses allocated to the first VM, and preventing 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 allocated 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 allocated to the first VM, and executing the second MMIO request in an input / output memory management unit (IOMMU) in response to identifying that the second MMIO request targets the set of memory addresses allocated to the first VM. In another aspect, the method includes receiving a set of memory addresses allocated to the first VM from a security coprocessor of a processor configured to execute the first VM.

[0041] In one aspect, the method includes preventing execution of the first MMIO request in response to identifying that the first MMIO request targets a port number not assigned to a set of memory addresses. In another aspect, the method includes, in response to receiving a second MMIO request from a second device associated with a second VM, identifying whether the second MMIO request targets at least one of the set of memory addresses assigned to the second VM, and preventing 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, in response to identifying that the first MMIO request targets a memory address assigned to the first VM, selecting an encrypted data stream for executing the first MMIO request.

[0042] In some embodiments, a method includes, in response to a first MMIO request targeting at least one memory address outside a first set of memory addresses assigned to a first virtual machine (VM), preventing execution of a first MMIO request for a first VM. In one aspect, the method includes, in response to a second MMIO request targeting at least one memory address of the first set of memory addresses assigned to the first VM, performing a second MMIO request for the first VM at an input / output memory management unit (IOMMU). In yet another aspect, the method includes, in response to a third MMIO request targeting at least one memory address outside the second set of memory addresses assigned to a second VM, preventing execution of a third MMIO request for a second VM.

[0043] In one aspect, a method includes preventing execution of a first virtual machine (MMIO) request to a first VM in response to the first MMIO request being targeted to a communication port not assigned to the first VM. In another aspect, the method includes receiving a first set of memory addresses assigned to the first VM from a security coprocessor of a processor 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 in an IOMMU.

[0044] In some embodiments, 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 of a set of memory addresses allocated to the first VM; and in response to identifying that the first MMIO request targets a memory address outside the set of memory addresses allocated to the first VM, prevent execution of the first MMIO request. In one aspect, the security hardware is configured 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 allocated to the first VM, and in response to identifying that the second MMIO request targets the set of memory addresses allocated to the first VM, execute the second MMIO request. In another aspect, the security hardware is configured to receive the set of memory addresses allocated to the first VM from a security coprocessor of the processor.

[0045] In one aspect, the security hardware is configured to prevent execution of the first MMIO request in response to identifying that the first MMIO request targets a port number not assigned to the set of memory addresses. 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 of the set of memory addresses assigned to the second VM, and prevent 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, in response to identifying that the first MMIO request targets a memory address assigned to the first VM, select an encrypted data stream for executing the first MMIO request.

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

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

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

Claims

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

2. In response to receiving a second MMIO request associated with the first VM from a second device, identifying whether the second MMIO request is targeted to a set of memory addresses assigned to the first VM; and executing, in an input / output memory management unit (IOMMU), the second MMIO request in response to identifying the second MMIO request as being directed to a set of memory addresses assigned to the first VM.

10. The method of claim 1.

3. receiving a set of memory addresses assigned to the first VM from a security coprocessor of a processor configured to execute the first VM; 10. The method of claim 1.

4. preventing execution of the first MMIO request in response to identifying the first MMIO request as being directed to a port number not assigned to a set of memory addresses.

10. The method of claim 1.

5. 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 of a set of memory addresses assigned to the second VM; and preventing execution of the second MMIO request in response to identifying the second MMIO request as being directed to a memory address outside a set of memory addresses allocated to the second VM.

10. The method of claim 1.

6. the first MMIO request is directed to an input / output device; 10. The method of claim 1.

7. selecting an encrypted data stream for executing the first MMIO request in response to identifying the first MMIO request as being targeted to a memory address assigned to the first VM. The method of any one of claims 1 to 6.

8. 1. A method comprising: Preventing execution of a first memory-mapped input / output (MMIO) request to a first virtual machine (VM) in response to the first MMIO request being targeted to at least one memory address outside a first set of memory addresses assigned to the first VM. method.

9. executing, at an input / output memory management unit (IOMMU), a second MMIO request to the first VM in response to the second MMIO request being targeted to at least one memory address in a first set of memory addresses assigned to the first VM; 9. The method of claim 8.

10. Preventing execution of a third MMIO request to a second virtual machine (VM) in response to the third MMIO request being targeted to at least one memory address outside a second set of memory addresses assigned to the second VM.

10. The method of claim 9.

11. Preventing execution of the first MMIO request to a first virtual machine (VM) in response to the first MMIO request being targeted to a communication port not assigned to the first VM.

9. The method of claim 8.

12. receiving a first set of memory addresses assigned to the first VM from a security coprocessor of a processor configured to execute the first VM; 9. The method of claim 8.

13. determining a first set of memory addresses assigned to the first VM based on a mapping table that maps addresses associated with the first VM; The method of any one of claims 8 to 12.

14. The mapping table is cached in the IOMMU.

14. The method of claim 13.

15. 1. A processor, comprising: an input / output memory management unit (IOMMU); security hardware; The security hardware 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 is targeted to at least one of a set of memory addresses assigned to the first VM; Preventing execution of the first MMIO request in response to identifying that the first MMIO request is directed to a memory address outside a set of memory addresses allocated to the first VM; configured to: Processor.

16. The security hardware includes: In response to receiving a second MMIO request associated with the first VM from a second device, identifying whether the second MMIO request is targeted to a set of memory addresses assigned to the first VM; In response to identifying the second MMIO request as being directed to a set of memory addresses assigned to the first VM, performing the second MMIO request; configured to:

16. The processor of claim 15.

17. The security hardware includes: configured to receive, from a security coprocessor of the processor, a set of memory addresses assigned to the first VM; 16. The processor of claim 15.

18. The security hardware includes: configured to prevent execution of the first MMIO request in response to identifying the first MMIO request as being targeted to a port number that is not assigned to a set of memory addresses.

16. The processor of claim 15.

19. The security hardware 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 of a set of memory addresses assigned to the second VM; responsive to identifying the second MMIO request as being directed to a memory address outside a set of memory addresses allocated to the second VM, preventing execution of the second MMIO request; configured to:

16. The processor of claim 15.

20. The security hardware includes: and configured to select an encrypted data stream for executing the first MMIO request in response to identifying the first MMIO request as being targeted to a memory address assigned to the first VM. The processor of any one of claims 15 to 19.

Images