Secure management of device control information in confidential computing environments

Abstract

The processor (100) includes a security processor (110) and an input / output memory management unit (IOMMU) (112). The security processor is configured to maintain device control information (122-2) in a secure data structure (120-2) and to prevent a hypervisor (116) from accessing the secure data structure. The IOMMU is configured to process at least one device request (124) from an input / output device (124) targeted to the virtual machine (114) based on the secure data structure.

Description

[Background technology]

[0001] In classified 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 classified 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 execution of the different 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 entities often own different VMs, 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 through input / output devices that interact with the VM.

[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] FIG. 1 is a block diagram of a processing system including a secure device table for securely managing device control information for input / output (I / O) devices, according to some embodiments. [Figure 2]2 is a block diagram of an exemplary secure device table implemented by the processing system of FIG. 1 to securely manage device control information, according to some embodiments. [Figure 3] 3 is a block diagram illustrating an example of an input / output memory management unit (IOMMU) of the processing system of FIG. 1 that uses the secure device table of FIG. 2 to securely manage device requests from I / O devices, in accordance with some embodiments. [Figure 4] 3 is a block diagram illustrating another example of an IOMMU that uses the secure device table of FIG. 2 to securely manage device requests from an I / O device, according to some embodiments. [Figure 5] 3 is a block diagram illustrating an example of an IOMMU that uses the secure device table of FIG. 2 to securely manage device requests from multiple I / O devices, according to some embodiments. [Figure 6] 1A-1D together with a flow diagram of a method for securely managing device control information using a secure device table, according to some embodiments. [Figure 7] 1A-1D together with a flow diagram of a method for securely managing device control information using a secure device table, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1-7 illustrate techniques for securely managing and using input / output (I / O) device control information in a confidential computing environment, according to some embodiments. Device control information that impacts the security or integrity of a VM or potentially allows the hypervisor access to sensitive information of the VM is maintained by a security module (e.g., a security processor) in a secure data structure, such as a secure device table (SDT). The security module maintains the SDT in a secure area of ​​memory that the hypervisor cannot access. However, in at least some embodiments, other device control information, such as host paging table information, that poses less of a security threat to the VM is nevertheless maintained by the hypervisor. When a device / access request, such as a direct memory access (DMA) request or an address translation request, is received by an input / output memory management unit (IOMMU) from an I / O device, the IOMMU is configured to process the received access request against the SDT to determine, for example, how to handle the access request and whether the access request should be granted. The techniques described herein ensure that information about I / O devices that may affect the security and integrity of a VM is managed and maintained in a secure manner by trusted components, rather than by potentially malicious entities such as a hypervisor. Thus, the techniques described herein prevent malicious entities from accessing sensitive information of a VM via I / O device control information (also referred to herein as "device control information"), and further prevent attacks on a VM via device control information.

[0006] To further illustrate with an example, in some processing systems, VMs interact with a hypervisor to access I / O devices in a virtualized manner. The hypervisor communicates with I / O devices through an IOMMU. However, the hypervisor itself can pose a security risk to VMs. In particular, allowing the hypervisor to manage and access device control information can enable the hypervisor to determine VM behavior and potentially expose sensitive data. For example, a malicious hypervisor can use the device control information to control the functionality of I / O devices and identify the behavior of a particular VM, such as how the VM attempts to use a particular I / O device, which devices are the target of a particular VM request, and so on. The malicious hypervisor can use this behavior to potentially identify sensitive information associated with the VM. Furthermore, enabling or disabling specific device controls can enable attacks on VMs via I / O devices.

[0007] To thwart these and similar attacks by malicious entities, a processing system using the techniques described herein employs a security module to ensure that device control information that may affect the security of a VM and its sensitive information is securely managed and maintained in an SDT that is not accessible to the hypervisor. The security module stores the device control information in a secure portion of memory that is not accessible to the hypervisor. Examples of device control information managed and maintained by the security module include I / O device identifiers, VM identifiers, identifiers of memory allocated to a VM, device interface VM bindings, security attributes, Peripheral Component Interconnect Express (PCIe) stream identifiers such as integrity and encryption (IDE) stream identifiers (StreamIDs), PCIe root port information, PCIe feature settings, Address Translation Service (ATS) mode indicators, etc. When a VM or hypervisor wants to make a change to the device control information stored in the SDT, the VM or hypervisor sends a change / modification request to the security module. The security module determines whether to act on the request based on, for example, one or more security policies. In at least some embodiments, when the hypervisor requests that the device control information be changed, the security module communicates with the VM to verify whether the VM will accept the change requested by the hypervisor. If the security module determines that the change requested by the VM or hypervisor would affect the security of the VM or sensitive information, the requested change to the device control information is not made.

[0008] In at least some embodiments, the IOMMU inspects the SDT when there is traffic to or from an I / O device to make a security policy decision on whether access is allowed. As part of this security policy decision, the IOMMU determines whether the I / O device is bound to the VM to which the I / O device is targeted. For example, in some embodiments, the security module implements a specific device binding process (e.g., a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) process) to bind the I / O device to the VM. The binding process implements specific processes, such as an authentication process, that allow the VM to "trust" the I / O device, i.e., to assume that the operation of the I / O device is secure and unlikely to result in the disclosure of sensitive VM information. The security module stores device control information in an SDT associated with the binding process. For example, the security module stores an identifier associated with the I / O device (or device interface) bound to a particular VM, an identifier associated with the VM, a region of memory allocated to the particular VM, etc.

[0009] In response to receiving a DMA or address translation request (also referred to herein as a "device request") from an I / O device, the IOMMU accesses the SDT to determine whether the requesting I / O device is securely bound to the VM. If so, the IOMMU performs access control checks, such as a reverse map table (RMT or RMP) check, appropriate for the type of device request (secure guest request or shared / non-secure guest / hypervisor request). For secure guest requests, the IOMMU checks the SDT to ensure that the memory accessed by the I / O device is owned by the VM to which the device is bound. If the memory is not owned by the VM or the I / O device is not bound to the VM, the IOMMU does not execute the device request. Otherwise, the IOMMU executes the access request. Thus, based on the techniques described herein, the IOMMU uses the SDT maintained by the security module to prevent execution of a device request if the requesting device is not bound to the VM associated with the request or if the memory accessed by the device is not owned / assigned to the VM. Therefore, the IOMMU, security module, and SDT prevent unauthorized access to or modification of sensitive information associated with a VM. Furthermore, because the SDT is not accessible to the hypervisor or directly accessible to the VM, it is difficult for the hypervisor or other entities to access and manipulate the device control information stored therein. Thus, VM security is maintained.

[0010] 1 illustrates a processing system 100 that implements secure management of device control information for I / O devices, according to some embodiments. Processing system 100 is generally configured to execute a set of instructions (e.g., a computer program) for performing tasks on behalf of an electronic device. Accordingly, processing system 100 may be part of various electronic devices in different embodiments. 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 other embodiments, processing system 100 may be part of a desktop computer, a laptop computer, a tablet, a game console, or the like.

[0011] To implement the secure computing environment and to execute the set of instructions and corresponding operations, processing system 100 includes processor 102, memory 104, and one or more input / output (I / O) devices, such as I / O device(s) 106. In some embodiments, processor 102 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 104 includes one or more memory devices configured to store and retrieve data based on commands (e.g., store and load commands) received from processor 102. Thus, in different embodiments, memory 104 is random access memory (RAM), non-volatile memory (NVM), hard disk memory, etc., or any combination thereof.

[0012] I / O device 106 is any device that can process input information, output information, or a combination thereof, independently of processor 102, on behalf of processing system 100. For example, in some embodiments, I / O device 106 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 106 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.

[0013] To execute the instruction set and corresponding operations, processor 102 includes processor core 108, security module 110 (e.g., security processor, security circuitry, etc.), and input / output memory management unit (IOMMU) 112. It should be understood that in some embodiments, processor 102 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.

[0014] Processor core 108 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 108 includes a fetch stage, a decode stage, a dispatch stage, one or more execute stages (with one or more corresponding execution units), a retire stage, etc. Processor core 108 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 108 includes or has access to one or more cache structures for storing data used to execute instructions.

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

[0016] In some embodiments, security module 110 manages a device binding process, in which I / O device 106 is bound to VM 114, also referred to as a guest, executing in the confidential computing environment, by going through a specified security registration process. For example, in some embodiments, VM 114 attempts to bind I / O device 106 by sending a bind request to security module 110. In response, security module 110 initiates the specified security registration process by requesting authentication information (e.g., a device certificate) from I / O device 106 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 106 is verified, security module 110 indicates to VM 114, and to other components of processor 102, as described further herein, that I / O device 106 is bound to VM 114.

[0017] It should be appreciated that in some embodiments, an I / O device 106 may be bound to multiple VMs 114 by undergoing a designated security registration process for that VM 114. For example, in some embodiments, each VM 114 interacts with the physical I / O device 106 using a different virtual function (VF), thus allowing the I / O device 106 to be virtualized as a different virtual I / O device for each VM 114. In some embodiments, the security module 110 binds the I / O device 106 to a VM 114 by binding a corresponding VF to the VM 114, thus allowing a single physical I / O device 106 to be bound to multiple VMs 114 (as long as the physical I / O device 106 undergoes a security registration process for each VM 114).

[0018] In at least some embodiments, security module 110 binds I / O devices 106 to VMs 114 by using a registration / binding process such as a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) process. For example, in some embodiments, processing system 100 includes a communications fabric (not shown) that complies with the PCIe communications protocol. In particular, I / O devices 106 are configured to communicate with processor 102 and IOMMU 112 in accordance with the PCIe communications protocol. In some embodiments, the PCIe communications protocol establishes a TDISP security registration process for binding I / O devices to VMs, and security module 110 uses the TDISP security registration process to bind I / O devices to running VMs. Additionally, security module 110 assigns a set of memory addresses to each running VM.

[0019] In some embodiments, the I / O device 106 has its own translation lookaside buffer (TLB), sometimes referred to as an address translation cache (ATC), and requests address translations from the IOMMU 112 using the address translation service (ATS). The I / O device 106 is assigned to the VM 114. In response to the I / O device 106 requesting an ATS, the IOMMU 112 performs security checks, including checking that the I / O device 106 is bound to the VM 114 and that the ATS request targets a region of memory assigned to the VM 114. If either of these checks fails, the IOMMU 112 rejects the ATS request. If both checks pass, the IOMMU 112 translates the address and returns the translated address to the I / O device 106, which caches the translated address in the ATC. The I / O device 106 then issues a DMA request using the translated address. In response, IOMMU 112 uses the mapping table to perform security checks on DMA requests.

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

[0021] In at least some embodiments, the I / O devices 106 access the memory 104 by generating direct memory access (DMA) requests to read data from the memory 104 allocated by the VM 114, DMA requests to write data to the memory 104, or a combination thereof. The IOMMU 112 is configured to process the DMA requests issued by the I / O devices 106. For example, to increase processing efficiency, the IOMMU 112 is generally configured to perform address translation and memory protection on behalf of the processor 102, i.e., to perform the address translation and memory protection operations using dedicated hardware in the IOMMU 112. In particular, the IOMMU 112 includes dedicated hardware for performing memory address translation and memory protection for DMA operations, and the I / O devices 106 generate DMA requests to read data from the memory 104, DMA requests to write data to the memory 104, or a combination thereof. In some embodiments, each DMA request includes a descriptor indicating the virtual address of the data to be accessed, i.e., the virtual address of the data to be read, the virtual address to which the data is to be written, or both. These virtual addresses indicate the regions of memory 104 that are the targets of the DMA requests. IOMMU 112 is generally configured to translate the virtual addresses indicated by the DMA requests into physical addresses in memory 104 and to interact with memory 104 to perform one or more operations indicated by the DMA requests (read operations, write operations, or a combination thereof).

[0022] Processing system 100, in at least some embodiments, maintains one or more data structures, such as device table 120 (shown as device table 120-1 and device table 120-2), which includes device control information 122 (shown as device control information 122-1 and device control information 122-2) associated with I / O devices 106 and VMs 114. Processing system 100 uses device table 120, for example, to enable VMs, disable VMs, securely manage access to VMs 114 by I / O devices 106 (which may be real / physical devices or virtual devices), etc.

[0023] In many confidential computing environments, the hypervisor typically programs the device table. Therefore, when a VM sends a request / command to program the device table, such as to program or enable / disable one or more functions of an I / O device, the hypervisor intercepts the request and programs the device table, which introduces vulnerabilities in the confidential computing environment. For example, allowing the hypervisor to manage and program device control information or control which device I / O functions are enabled or disabled for a particular VM can allow the hypervisor to determine VM behavior and potentially expose sensitive data. Also, a malicious hypervisor can control the functions of I / O devices through their associated device control information to identify the behavior of a particular VM, such as how the VM attempts to use a particular I / O device, which device is the target of a particular VM request, etc. The malicious hypervisor can use this behavior to potentially identify sensitive information associated with the VM. Furthermore, enabling or disabling a particular device control can enable attacks on a VM via an I / O device.

[0024] To address these and other potential security concerns, processing system 100 maintains a first device table 120-1, also referred to herein as hypervisor accessible tables (HDT) 120-1, accessible to hypervisor 116, and one or more device tables 120-2. Device table 120-2, also referred to herein as a secure device table (SDT), is accessible to security module 110 and IOMMU 112, but not to hypervisor 116. HDT 120-1, in at least some embodiments, is maintained by hypervisor 116 in a portion of memory 104 accessible to hypervisor 116. SDT 120-2, however, is maintained by security module 110 in a secure region 118 of memory 104 that is accessible to security module 110 and IOMMU 112, but not to hypervisor 116.

[0025] In at least some embodiments, HDT 120-1 includes device control information 122 (denoted as device control information 122-1) that does not pose a security risk to VM 114 when accessed by hypervisor 116. For example, HDT 120-1 includes information that allows hypervisor 116 to enable or disable VM 114, host paging table information, interrupt remapping table information, etc. In at least some embodiments, the SDT 120-2 includes secure (confidential) device control information 122-2, such as a device identifier for one or more I / O devices 106, a VM identifier (VMID) for a VM 114 operating in communication with the I / O device 106, a VMID for a VM 114 involved with the I / O device 106 or otherwise associated with the I / O device 106, an address space identifier (ASID), device (or device interface) VM binding information, a memory encryption key index for accessing VM memory, PCIe stream identifier information, a PCIe root port identifier, a secure ATS mode indicator, or combinations thereof.

[0026] The VMID includes a unique identifier for each VM 114. As an example, for each VM executing on the processor 102 or expected to execute on the processor 102, the security module 110 assigns the VM 114 a respective VMID including a unique identifier. Because the VMID includes a unique identifier for the VM 114, a field in the SDT 120-2 that includes the VMID indicates the VM corresponding to the associated entry in the SDT 120-2. The ASID identifies the memory address space assigned to the VM 114 associated with the corresponding entry in the SDT 120-2. For example, the security module 110 defines one or more memory address spaces based, for example, on registers and other storage locations of the memory 104, the I / O devices 106, or a combination thereof, and assigns a respective ASID to each memory address space. Such an ASID includes, for example, a unique identifier for each memory address space. During the provisioning process, the security module 110 then allocates one or more memory address spaces to each VM 114. The device (or device interface) VM binding information indicates whether the I / O device 106 associated with the SDT entry is securely bound to the VM 114 identified by the VMID of the SDT entry. The PCIe stream identifier information indicates a set of stream IDs expected to be used by the I / O device 106 associated with the SDT entry. Each stream identifier corresponds to an encrypted, integrity-protected channel for secure communication over the PCIe link. The PCIe root identifier indicates the root port to which the I / O device 106 associated with the SDT entry is connected. The secure ATS mode indicator provides an indication of the mode used to process ATS address translation requests received from the I / O device 106 associated with the SDT entry. For example, the ATS mode indicator indicates whether to return a system physical address or a guest physical address.

[0027] In at least some embodiments, security module 110 generates and maintains SDT 120-2. For example, when security module 110 assigns a VMID or ASID to VM 114, security module 110 stores the VMID or ASID in an entry in SDT 120-2 associated with VM 114. Also, when security module 110 binds an I / O device 106 (or device interface) to a VM, it stores the binding information in a corresponding entry in SDT 120-2. As described above, SDT 120-2 and the secure / sensitive device control information 122-2 stored therein are not accessible to hypervisor 116. However, SDT 120-2 and secure device control information 122-2 are indirectly accessible to VM 114 via security module 110.

[0028] In at least some embodiments, an I / O device 106 submits a device request 124 to access a VM 114. Examples of device requests 124 include a DMA request or an address translation request. The IOMMU 112 receives the device requests 124 and determines the VM 114 targeted by the device request 124 (e.g., based on a descriptor included in the device request 124). For example, in some embodiments, each device request 124 includes a VM identifier (e.g., a VMID) indicating the VM 114 targeted by the device request 124. In some embodiments, the device request 124 includes a requestor identifier indicating the I / O device 106 that issued the device request 124. The IOMMU 112 determines whether the requesting I / O device 106 is bound to the targeted VM 114 based on secure device control information 122-2 in the SDT 120-2. If not, the IOMMU 112 prevents the device request 124 from executing. For example, in some embodiments, if device request 124 is a DMA request (or address translation request), IOMMU 112 prevents the DMA request from executing by not initiating the address translation process for the DMA request, so that the virtual address indicated by the DMA request is not translated to a physical address. This prevents the DMA request from executing properly, thereby protecting sensitive information associated with VM 114.

[0029] In response to identifying the requesting I / O device 106 (i.e., the I / O device 106 that issued the device request 124) as bound to the targeted VM 114, the IOMMU 112 determines whether the device request 124 targets a portion of memory 104 that is within a memory region allocated to the targeted VM 114, as indicated by secure device control information 122-2 (e.g., ASID) in the SDT 120-2. Illustratively, if the device request 124 is a DMA request (or address translation request), the DMA request indicates a virtual address to be read from, a virtual address to be written to, or a combination thereof. In at least some embodiments, the IOMMU 112 translates the virtual address indicated by the device request 124 to a physical address to determine ownership. The IOMMU 112 compares the physical address to an address identified by the ASID stored in the secure device control information 122-2 associated with the targeted VM 114. IOMMU 112 determines whether all of the addresses associated with device request 124 are within the memory region allocated to the corresponding VM 114, as indicated by secure device control information 122-2. If any of the addresses associated with device request 124 are outside the allocated memory region of the targeted VM 114, IOMMU 112 prevents execution of the DMA request, as described above. If the addresses indicated by the DMA request are within the allocated memory region of the targeted VM 114, IOMMU 112 executes the DMA request. Thus, IOMMU 112 ensures that device request 124 is satisfied only if 1) the requesting I / O device 106 is bound to the targeted VM 114 and 2) the device request 124 targets a portion of memory 104 allocated to the targeted VM 114. Thus, IOMMU 112 uses SDT 120-2 to prevent malicious entities from accessing sensitive VM information via device requests.

[0030] It should be understood that in some embodiments, the operations of IOMMU 112 occur in a different order than described in the above example. For example, in some embodiments, IOMMU 112 first checks whether device request 124 targets a portion of memory 104 allocated to the targeted VM 114. If so, IOMMU 112 checks whether the requesting I / O device 106 is bound to the VM 114. In other embodiments, IOMMU 112 checks both conditions simultaneously or in parallel (whether the requesting I / O device 106 is bound to the targeted VM 114 and whether the device request 124 targets a portion of memory 104 allocated to VM 114).

[0031] 2 shows an example of an SDT 120-2, according to some embodiments. In the illustrated example, the SDT 120-2 includes multiple entries (e.g., entry 202 and entry 204), each assigned to a different I / O device 106 (or VM 114). Each entry in the SDT 120-2 includes secure device control information 122-2 stored in one or more fields, including a device identifier field 206, a VM identifier field 208, an allocated memory field 210, and a VM bind indicator field 212. In at least some embodiments, each entry in the SDT 120-2 also includes one or more other fields 214. The device identifier field 208 of an entry stores a value or set of values ​​that indicates the device identifier (device ID) of the corresponding I / O device 106. In some embodiments, in response to assigning an I / O device 106 (or device interface) to a VM 114, security module 110 stores the device ID of the assigned I / O device 106 in a corresponding entry 202 of SDT 120-2. VM identifier field 208 stores a virtual machine identifier (VMID) assigned by security module 110 to the VM 114 assigned to the I / O device 106 associated with entry 202. Allocated memory field 210 stores, for example, an ASID assigned by security module 110 to the VM 114 identified in VM identifier field 208. VM bind indicator field 212 stores an indication of whether the I / O device 106 associated with entry 202 is securely bound to the VM 114 identified in VM identifier field 208. For example, in response to the I / O device 106 successfully completing the specified security process for binding, the security module 110 stores an indicator in the VM bind indicator field 212 indicating that the I / O device 106 is bound to the VM 114 identified in the VM identifier field 208.One or more other fields 214 include other device control information 122-2, such as a memory encryption key index for accessing VM memory, PCIe stream identifier information, PCIe root port identifier, a secure ATS mode indicator, or combinations thereof.

[0032] In at least some embodiments, when the IOMMU 112 determines that a device request 124 has been received from an I / O device 106, the IOMMU 112 uses the device ID field 206 to identify the entry 202 in the SDT 120-2 that corresponds to the requesting I / O device 106. The IOMMU compares the VM identifier included in the device request 124 with the VMID included in the VM identifier field 208 to determine whether the requesting I / O device 106 is requesting access to a VM 114. The IOMMU 112 also compares the address information included in the device request 124 with the ASID included in the allocated memory field 210. The IOMMU 112 further accesses the VM bind indicator field 212 to determine whether the requesting I / O device 106 is securely bound to the targeted VM 114. If the IOMMU 112 determines that the requesting I / O device 106 is attempting to access a VM 114 to which the requesting device 106 is not assigned or securely bound, or is attempting to access memory 104 that is not assigned to the targeted VM 114, the IOMMU 112 does not execute the device request 124. Otherwise, the IOMMU 112 executes the device request 124.

[0033] 3 illustrates an example of an IOMMU 112 using an SDT 120-2 to block execution of a device request 124, according to some embodiments. In the illustrated example, the IOMMU 112 receives the device request 124 from the I / O device 106. The device request 124 includes a descriptor prepared by the I / O device 106 indicating that the device request 124 is associated with the VM 114 (e.g., by including the VMID of the VM 114 in the descriptor). That is, the I / O device 106 indicates, via fields in the device request 124, a request to perform address translation, a request to read data, a request to write data, or a request to transfer data (read and write) on behalf of the VM 114. The I / O device 106 also provides its own device ID in the device request 124 to indicate that the request was generated by the I / O device 106.

[0034] In response to receiving device request 124, IOMMU 112 accesses SDT 120-2, specifically the entry in SDT 120-2 that corresponds to the requesting I / O device 106 (or targeted VM 114). For example, in some embodiments, IOMMU 112 uses the device identifier (or VMID) indicated by device request 124 to identify an entry in SDT 120-2 that has a corresponding device identifier (or VMID) in device ID field 206 (or VM identifier field 208). IOMMU 112 then compares the VMID (or device identifier) ​​in device request 124 with the VMID (or device identifier) ​​stored in VM identifier field 208 (or device ID field 206) of the entry in SDT 120-2. If the entry contains a VM identifier that matches the VM identifier included in the device request, IOMMU 112 determines that the requesting I / O device 106 is assigned to the targeted VM 114. If not, IOMMU 112 determines that requesting I / O device 106 is not assigned to the targeted VM 114 and prevents execution of device request 124, as described above with respect to FIG.

[0035] IOMMU 112 also retrieves the value stored in VM binding field 212 to determine whether the requesting I / O device 106 is securely bound to the VM 114 associated with device request 124. In another example, VM binding field 212 includes a VM identifier indicating a VM 114 to which the I / O device 106 associated with the entry in SDT 120-2 is securely bound, or includes a device identifier indicating an I / O device 106 securely bound to the VM 114 associated with SDT entry 120-2. In the example of FIG. 3, assume that the information stored in SDT 120-2 indicates that the requesting I / O device 106 is not securely bound to the VM 114 targeted by security module 110. In response to determining that the requesting I / O device 106 is not securely bound to the targeted VM 114, IOMMU 112 prevents execution of device request 124. For example, in some embodiments, IOMMU 112 prevents execution of device request 124 by preventing the use of address mapping fields contained in SDT 120-2 or another mapping table to translate the virtual address of device request 124 into a physical address. In addition, IOMMU 112 provides message 302 to the requesting I / O device 106 indicating that device request 124 has been denied. In some embodiments, IOMMU 112 provides message 302 (or a similar message) to the targeted VM 114. In some embodiments, IOMMU 112 notifies security module 110 that device request 124 has been denied and that there has been a potential attempt at a security violation by I / O device 106. This allows security module 110 to take corrective action, such as notifying a system administrator of the potential security violation.

[0036] 4 illustrates another example of an IOMMU 112 using a mapping SDT 120-2 to block execution of a device request 124, according to some embodiments. In the illustrated example, similar to FIG. 4, the IOMMU 112 receives a device request 124 from an I / O device 106. The device request 124 includes a descriptor prepared by the I / O device 106 indicating the portion of memory 104 targeted by the device request 124. That is, the I / O device 106 indicates, via fields in the device request 124, the memory address targeted by the request to read data, write data, or transfer data (read and write) on behalf of the targeted VM 114.

[0037] In response to receiving device request 124, IOMMU 112 accesses SDT 120-2, specifically the entry in mapping SDT 120-2 that corresponds to the requesting I / O device 106 (or targeted VM 114). IOMMU 112 then compares the portion of memory indicated by device request 124 with the portion of memory indicated by allocated memory field 210 of the entry in SDT 120-2. In the example of FIG. 4 , the portion of memory indicated by device request 124 is assumed to be at least partially outside the portion of memory stored in allocated memory field 210. That is, device request 124 targets, at least in part, a portion of memory 104 that is not allocated to the targeted VM 114. In response, IOMMU 112 blocks execution of device request 124 and notifies security module 110 that device request 124 has been denied by sending message 402.

[0038] As described above, in at least some embodiments, the information represented by SDT 120-2 is stored in multiple different, differently indexed tables. For example, in some embodiments, a first table (called a source validation table) stores a device identifier field 206 (or VM identifier field 208) and a corresponding bound device field 212 for each I / O device 106 (or VM 114), and a second table (called a memory ownership table) stores an allocated memory field 210 and a corresponding VM identifier field 208. IOMMU 112 receives device requests from I / O devices 106, where the device request includes the device identifier of I / O device 106 and the virtual address targeted by the device request. IOMMU 112 accesses the source validation table to determine whether I / O device 106 is bound to the targeted VM 114, and if not, IOMMU 112 does not execute the request.

[0039] If the I / O device 106 is bound to a VM 114, the IOMMU 112 translates the virtual address to a physical address using a set of page tables. The IOMMU 112 uses the physical address to index a memory ownership table and compares the VM identifier obtained from the memory ownership table with the VM 114 indicated by the source verification table. If the VM identifiers do not match, the IOMMU 112 does not fulfill the device request. If the VM identifiers match, the IOMMU 112 fulfills the device request.

[0040] As described above, SDT 120-2 stores an individual entry for each assigned I / O device, each VM 114 executing on processor 102, or a combination thereof. This allows IOMMU 112 to individually grant or deny device requests for different VMs 114, independent of device requests for other VMs 114. An example according to some embodiments is shown in FIG. 5. In the example of FIG. 5, assume processor 102 is running two different VMs, namely VM 114 and VM 514. IOMMU 112 receives device request 124 from I / O device 106 indicating a request to access memory on behalf of VM 114. Further assume SDT 120-2 indicates that I / O device 106 is not bound to VM 114, that device request 124 targets a portion of memory 104 not assigned to VM 114, or both. Therefore, IOMMU 112 prevents device request 124 from being executed and indicates (via message 502) that device request 124 has been denied.

[0041] With respect to device request 524, assume that SDT 120-2 indicates that I / O device 506 is bound to VM 514. Further, assume that SDT 120-2 indicates that device request 524 targets a portion of memory 104 that is not allocated to VM 514. Therefore, IOMMU 112 determines that device request 524 is permitted (as indicated by message 504) and thereby executes device request 524. Thus, in the example of FIG. 5 , IOMMU 112 selectively permits some device requests and denies other device requests, thus preventing a malicious actor from stopping or slowing down the execution of multiple VMs in processing system 100 by issuing inappropriate device requests.

[0042] 6 and 7 together show a flow diagram of a method 600 for managing and implementing secure device control information, according to some embodiments. For purposes of explanation, method 600 is described with reference to an exemplary embodiment in processing system 100 of FIG. 1, but it should be understood that in other embodiments, method 600 is implemented in processing systems having different configurations. Also, method 600 is not limited to the sequence of operations shown in FIGS. 6 and 7, and at least some of the operations may be performed in parallel or in different sequences.

[0043] At block 602, the security module 110 allocates regions (portions) of memory 104 to one or more VMs 114. At block 604, the security module 110 allocates one or more I / O devices 106 (or device interfaces) to the VMs 114. At block 606, the security module 110 securely binds the one or more I / O devices (or device interfaces) to the specified VMs 114. At block 608, the security module 110 maintains confidential device control information 122-2 in the SDT 120-2. For example, the security module 110 maintains an entry for a specified I / O device 106, including a device identifier for the I / O device 106 in a device identifier field 206, a VM identifier for the VM 114 assigned to the I / O device 106 in a VM identifier field 208, an identifier for memory allocated to the VM 114 in an allocated memory field 210, an indicator of whether the I / O device 106 is securely bound to the identified VM 114 in a VM bind indicator field 212, etc.

[0044] At block 610, the IOMMU 112 receives a device request 124 (e.g., a DMA request or an address translation request) from an I / O device 106. The device request 124 includes, for example, an identifier of the requesting I / O device 106, an identifier of the VM 114 associated with the device request 124, address information indicating the portion of memory 104 targeted by the requesting device 124, etc. At block 612, the IOMMU 112 determines whether the requesting I / O device 106 is assigned to the VM 114 targeted by the device request 124. If not, method flow moves to block 620, where the IOMMU 112 prevents execution of the device request 124. Method flow then returns to block 610.

[0045] If, at block 612, the IOMMU 112 determines that the requesting I / O device 106 is assigned to the targeted VM 114, the method proceeds to block 614, where the IOMMU 112 determines whether the requesting I / O device 106 is securely bound to the targeted VM 114. In at least embodiments, the IOMMU 112 determines whether the requesting I / O device 106 is securely bound to the targeted VM 114 by a designated security registration process, such as TDISP. If the requesting I / O device 106 is not bound to the targeted VM 114 (or is not bound by a designated security registration process), method flow moves to block 620, where the IOMMU 112 prevents execution of the device request 124. Method flow then returns to block 610. If, at block 614, the IOMMU 112 determines that the requesting I / O device 106 is securely bound to the targeted VM 114, method flow proceeds to block 616, where the IOMMU 112 determines whether the device request 124 targets a portion of memory 104 allocated to the targeted VM 114. If not, method flow moves to block 620, where the IOMMU 112 blocks execution of the device request 124. If the device request 124 targets a portion of memory 104 allocated to the targeted VM 114, method flow moves to block 618, where the IOMMU 112 executes the device request 124. Method flow then returns to block 610.

[0046] As disclosed herein, in some embodiments, a method includes maintaining device control information in a secure data structure, the secure data structure being prevented from being accessed by a hypervisor, and processing at least one device request from an input / output (I / O) device targeted to a virtual machine (VM) based on the secure data structure. In one aspect, the method includes maintaining different device control information in a data structure accessible to the hypervisor. In another aspect, the device control information includes one or more of a device identifier identifying the I / O device, a virtual machine identifier identifying a VM assigned to the identified I / O device, an identifier identifying memory assigned to the identified VM, a VM bind indicator indicating whether the identified I / O device is bound to the identified VM, one or more Peripheral Component Interconnect Express (PCIe) stream identifiers, PCIe root port information, one or more PCIe function settings, or one or more Address Translation Services (ATS) mode indicators. In yet another aspect, processing the at least one device request based on the secure data structure includes identifying, in an input / output memory management unit (IOMMU), whether the I / O device is bound to the targeted VM based on the device control information; preventing, in the IOMMU, performance of the device request in response to identifying the I / O device as not bound to the targeted VM; and performing, in the IOMMU, the device request in response to identifying the I / O device as bound to the targeted VM.

[0047] In one aspect, identifying whether the I / O device is bound to the targeted VM further includes identifying whether the I / O device is bound to the targeted VM by a designated security enrollment process. In another aspect, executing the device request is performed in response to identifying the I / O device as bound to the targeted VM by a designated security enrollment process. In yet another aspect, preventing execution of the device request is performed in response to identifying the I / O device as not bound to the VM by a designated security enrollment process.

[0048] In one aspect, the designated security registration process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) registration process. In another aspect, identifying whether the I / O device is bound to the targeted VM includes identifying whether device control information stored in an entry of a secure data structure associated with the I / O device includes a VM bind indicator indicating that the I / O device is bound to the targeted VM. In yet another aspect, processing the at least one device request based on the secure data structure includes identifying, in an input / output memory management unit (IOMMU), whether the I / O device targets memory allocated to the targeted VM based on the device control information; preventing execution of the device request in the IOMMU in response to identifying the targeted memory as not allocated to the targeted VM; and executing the device request in the IOMMU in response to identifying the targeted memory as allocated to the targeted VM. In yet another aspect, identifying whether the I / O device targets memory allocated to the targeted VM includes determining whether an entry in a secure data structure associated with the I / O device includes an allocated memory identifier of the targeted VM corresponding to the targeted memory.

[0049] In some embodiments, a method includes, in response to assigning an input / output (I / O) device to a virtual machine (VM), updating an entry maintaining device control information for the I / O device in a secure data structure, the secure data structure not accessible to a hypervisor, to include an indication that the I / O device has been assigned to the VM, and in response to receiving a device request from the I / O device targeted to the VM, processing the device request based on the secure data structure. In one aspect, processing the device request based on the secure data structure includes, in an input / output memory management unit (IOMMU), identifying whether the I / O device is bound to the targeted VM based on the device control information maintained in the entry, and in response to identifying the I / O device as not bound to the targeted VM, preventing execution of the device request in the IOMMU, and in response to identifying the I / O device as bound to the targeted VM, executing the device request in the IOMMU. In another aspect, processing the device request based on the secure data structure includes identifying, based on device control information maintained in an entry in an input / output memory management unit (IOMMU), whether the I / O device targets memory assigned to the targeted VM; preventing, in the IOMMU, performance of the device request in response to identifying the targeted memory as not assigned to the targeted VM; and executing, in the IOMMU, the device request in response to identifying the targeted memory as assigned to the targeted VM.

[0050] In some embodiments, a processor includes a security processor configured to maintain device control information in a secure data structure, the secure data structure being prevented from being accessed by a hypervisor, and an input / output memory management unit (IOMMU) configured to process at least one device request targeted to a virtual machine (VM) from an input / output (I / O) device based on the secure data structure. In one aspect, the IOMMU is configured to process the at least one device request based on the secure data structure by identifying whether the I / O device is bound to the targeted VM based on the device control information, preventing execution of the device request in response to identifying the I / O device as not bound to the targeted VM, and executing the device request in response to identifying the I / O device as bound to the targeted VM.

[0051] In one aspect, the IOMMU is configured to identify whether the I / O device is bound to the targeted VM by identifying whether the I / O device is bound to the targeted VM by a designated security enrollment process. In another aspect, the IOMMU is configured to identify whether the I / O device is bound to the targeted VM by identifying whether device control information stored in an entry of a secure data structure associated with the I / O device includes a VM bind indicator indicating that the I / O device is bound to the targeted VM. In yet another aspect, the IOMMU is configured to process at least one device request based on the secure data structure by identifying whether the I / O device targets memory allocated to the targeted VM based on the device control information, preventing execution of the device request in response to identifying the targeted memory as not allocated to the targeted VM, and executing the device request in response to identifying the targeted memory as allocated to the targeted VM. In yet another aspect, the IOMMU is configured to identify whether the I / O device targets memory allocated to the targeted VM by determining whether an entry in a secure data structure associated with the I / O device includes an allocated memory identifier of the targeted VM that corresponds to the targeted memory.

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

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

[0054] 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. maintaining device control information in a secure data structure, wherein a hypervisor is prevented from accessing said secure data structure; and processing at least one device request from an input / output (I / O) device targeted to a virtual machine (VM) based on the secure data structure. method.

2. maintaining different device control information in a data structure accessible to the hypervisor; 10. The method of claim 1.

3. The device control information a device identifier for identifying the I / O device; a virtual machine identifier identifying a VM assigned to the identified I / O device; an identifier identifying memory allocated to the identified VM; a VM bound indicator indicating whether the identified I / O device is bound to the identified VM; one or more Peripheral Component Interconnect Express (PCIe) stream identifiers; PCIe root port information, one or more PCIe function settings, or one or more Address Translation Service (ATS) mode indicators including one or more of The method of claim 1 or 2.

4. Processing the at least one device request based on the secure data structure includes: Identifying, in an input / output memory management unit (IOMMU), whether the I / O device is bound to the targeted VM based on the device control information; In response to identifying the I / O device as not being bound to the targeted VM, preventing execution of the device request at the IOMMU; and executing the device request in the IOMMU in response to identifying the I / O device as bound to the targeted VM.

10. The method of claim 1.

5. identifying whether the I / O device is bound to the targeted VM includes identifying whether the I / O device is bound to the targeted VM by a designated security registration process; The method of claim 4.

6. performing the device request in response to identifying the I / O device as bound to the VM targeted by the specified security registration process; The method of claim 5.

7. and preventing execution of the device request occurs in response to identifying the I / O device as not being bound to the VM by the designated security registration process. The method of claim 5.

8. the designated security enrollment process includes a Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP) enrollment process; The method of claim 5.

9. Identifying whether the I / O device is bound to the targeted VM includes identifying whether device control information stored in an entry of the secure data structure associated with the I / O device includes a VM bind indicator indicating that the I / O device is bound to the targeted VM. The method of claim 4.

10. Processing the at least one device request based on the secure data structure includes: identifying, in an input / output memory management unit (IOMMU), whether the I / O device targets memory allocated to the targeted VM based on the device control information; In response to identifying the targeted memory as not being allocated to the targeted VM, preventing execution of the device request at the IOMMU; and executing the device request at the IOMMU in response to identifying the targeted memory as allocated to the targeted VM.

10. The method of claim 1.

11. identifying whether the I / O device targets memory allocated to the targeted VM includes determining whether an entry in the secure data structure associated with the I / O device includes an allocated memory identifier of the targeted VM corresponding to the targeted memory; The method of claim 10.

12. In response to assigning an input / output (I / O) device to a virtual machine (VM), updating an entry maintaining device control information for the I / O device in a secure data structure to include an indication that the I / O device has been assigned to the VM, the secure data structure being inaccessible to a hypervisor; in response to receiving a device request from the I / O device targeted to a VM, processing the device request based on the secure data structure. method.

13. Processing the device request based on the secure data structure includes: Identifying whether the I / O device is bound to the targeted VM based on the device control information maintained in the entry in an Input / Output Memory Management Unit (IOMMU); In response to identifying the I / O device as not being bound to the targeted VM, preventing execution of the device request at the IOMMU; and executing the device request in the IOMMU in response to identifying the I / O device as bound to the targeted VM.

13. The method of claim 12.

14. Processing the device request based on the secure data structure includes: identifying whether the I / O device targets memory allocated to the targeted VM based on the device control information maintained in the entry in an Input / Output Memory Management Unit (IOMMU); In response to identifying the targeted memory as not being allocated to the targeted VM, preventing execution of the device request at the IOMMU; and executing the device request at the IOMMU in response to identifying the targeted memory as allocated to the targeted VM.

13. The method of claim 12.

15. a security processor configured to maintain device control information in a secure data structure, the security processor preventing a hypervisor from accessing the secure data structure; an input / output memory management unit (IOMMU), The IOMMU is and configured to process at least one device request from an input / output (I / O) device targeted to a virtual machine (VM) based on the secure data structure. Processor.

16. The IOMMU is Identifying whether the I / O device is bound to the targeted VM based on the device control information; In response to identifying the I / O device as not being bound to the targeted VM, preventing execution of the device request; In response to identifying the I / O device as being bound to the targeted VM, performing the device request; and processing the at least one device request based on the secure data structure by 16. The processor of claim 15.

17. the IOMMU is configured to identify whether the I / O device is bound to the targeted VM by identifying whether the I / O device is bound to the targeted VM by a specified security registration process; 17. The processor of claim 16.

18. the IOMMU is configured to identify whether the I / O device is bound to the targeted VM by identifying whether device control information stored in an entry of the secure data structure associated with the I / O device includes a VM bind indicator that indicates that the I / O device is bound to the targeted VM; 17. The processor of claim 16.

19. The IOMMU is Identifying whether the I / O device targets memory allocated to the targeted VM based on the device control information; responsive to identifying the targeted memory as not being allocated to the targeted VM, preventing execution of the device request; performing the device request in response to identifying the targeted memory as allocated to the targeted VM; and processing the at least one device request based on the secure data structure by 16. The processor of claim 15.

20. the IOMMU is configured to identify whether the I / O device targets memory allocated to the targeted VM by determining whether an entry in the secure data structure associated with the I / O device includes an allocated memory identifier of the targeted VM that corresponds to the targeted memory.

20. The processor of claim 19.

Images