Lifecycle management of device input / output interfaces in virtualized environments

Abstract

A security module of a processor manages the lifecycle of a device interface of an input / output (I / O) device in a virtualized environment in a secure and trusted manner. For example, the security module is configured to bind a device interface of the I / O device interface to a virtual machine (VM). In response to binding the device interface, the security module is configured to certify at least one of the device interface and the I / O device. In response to certifying at least one of the device interface and the I / O device, the security module is configured to configure an input / output memory management unit (IOMMU) and memory resources associated with the VM.

Description

[Background technology]

[0001] In confidential computing environments, processing systems (e.g., servers) run multiple software programs, such as virtual machines (VMs) 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 allocation of environment resources to the different virtual machines and provides an interface between the virtual machines and the server hardware, so that each VM can operate as if it were running on its own dedicated hardware.

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

[0003] [Figure 1] FIG. 1 is a block diagram of a processing system employing a security module to manage the lifecycle of device interfaces of input / output devices in a virtualized environment, according to some embodiments. [Figure 2] FIG. 1 is a flow diagram of a method for managing the lifecycle of a device interface in a secure and trusted manner, according to some embodiments. [Figure 3] FIG. 1 is a flow diagram of a method for managing the lifecycle of a device interface in a secure and trusted manner, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] Confidential computing environments implement various security features to protect VMs from malicious attacks by untrusted devices or components. For example, a security feature that prevents one VM from accessing data (or other information) associated with another VM may be implemented by a virtual machine manager. This approach typically considers the virtual machine manager to be a trusted component and does not isolate the virtual machine manager from the VMs. However, in many confidential computing environments, VMs can benefit from a VM trust model in which the virtual machine manager is considered an untrusted component and protects the VM from a malicious virtual machine manager accessing a given VM's confidential information. In computing environments, such as cloud-based computing environments, entities may want to protect VM-based workloads from cloud administrators to maintain data confidentiality and minimize the impact of bugs in the cloud provider's infrastructure. Therefore, some confidential computing environments implement security features at the hardware level to isolate VMs from virtual machine managers and other code that may happen to coexist on the physical server. For example, each VM is assigned a unique Advanced Encryption Standard (AES) encryption key that is used to automatically encrypt each VM's data in use. When a component such as a Virtual Machine Manager attempts to read memory within a VM, it can only see encrypted bytes. In another example, the VM's register state is encrypted at every Virtual Machine Manager transition, so the Virtual Machine Manager cannot see data that is actively being used by the VM. In yet a further example, the integrity of the VM is protected by introducing a Reverse Map Table (RMP) to record and verify the VM's ownership of memory pages. If a VM can read a private (encrypted) page of memory, it must always read the value it last wrote.

[0005] Although these and other security features protect VMs from various attacks performed by malicious virtual machine managers, other VMs, and input / output (I / O) devices, these security features impose performance and functional limitations on the system. For example, many confidential computing environments use device interfaces to virtualize and share I / O devices across multiple VMs. Device interfaces allow I / O devices to be virtualized as different virtual I / O devices for each VM. In many cases, the lifecycle of device interfaces is not managed in a secure or reliable manner. Therefore, I / O devices and their interfaces are typically considered untrusted devices and are not allowed to access the VM's private memory, resulting in performance and functional issues related to VM memory access.

[0006] To overcome the functional and performance limitations of typical VM security features described above, using the techniques described herein, a processing system employs a security module (e.g., a security coprocessor) to manage the lifecycle of device interfaces, allowing a VM to "trust" the device interfaces and their associated I / O devices. In other words, the VM can determine that the operation of the device interfaces is safe and unlikely to result in the exposure of sensitive VM information. Thus, one or more of the techniques described herein relax the restriction that I / O devices and their interfaces cannot access VM private memory, while maintaining protection of the VM from malicious devices.

[0007] As described below, the life cycle of a device interface includes different phases, such as device initialization, binding, attestation, configuration, usage, unbinding, rebinding, reclaiming, and device teardown (de-initialization). During the bind phase, the system physical address (SPA) of the memory mapped Input / Output (MMIO) range is mapped to the VM's guest physical address (GPA), and the state of the device interface transitions from an unlocked state (e.g., the device interface configuration can be changed / modified) to a locked state (e.g., the device interface configuration cannot be changed / modified). The attestation phase involves attesting the I / O devices and device interfaces. For example, the VM is provided with an attestation report and a certificate chain to verify the configuration of the I / O device. The VM is also provided with an interface report to verify the configuration, such as the MMIO range layout, of the device interface. The configuration phase includes configuring the MMIO for use by the VM and configuring the input / output memory management unit (IOMMU). The use phase includes the VM accessing the device interface and vice versa. The unbind phase includes unbinding the device interface from the VM and recovering from any I / O device or VM error conditions. The unbound device interface can then be rebound to its resources, such as the VM or context page, or the device interface can be reclaimed.

[0008] These phases of the device interface life cycle and their processes, managed by the security module, provide memory security, such as protection from malicious DMA, unexpected memory types, and unexpected memory-mapped input / output (MMIO) accesses. I / O device assurance is also provided by enforcing I / O device attestation operations, protecting I / O device configuration, and allowing VMs to mediate device interface assignment. VMs may disagree about the trustworthiness of a device interface, and can determine whether a device interface is trustworthy based on, for example, attestation reports, certificate chains, and interface reports. A VM can be bound to zero or more device interfaces, but a device interface can be bound to zero or one VM. A trusted channel is provided between I / O devices and VMs, protecting VMs from physical tracing attacks and also protecting against snooping or masquerading by malicious machine managers. Enabling DMA to the guest's private range also improves performance over traditional I / O virtualization environments, eliminating costly bounce buffering.

[0009] 1 illustrates a processing system 100 that implements a lifecycle management process for a device interface of an I / O device, 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 other 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 102, memory 104, and one or more input / output (I / O) devices, such as I / O device 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 a set of instructions. Memory 104 includes one or more memory devices configured to store and retrieve data (e.g., store and load commands) based on commands received from processor 102. Thus, in different embodiments, memory 104 is random access memory (RAM), non-volatile memory (NVM), storage, or the like, or any combination thereof.

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

[0012] To execute the instruction set and corresponding operations, processor 102 includes processor core 108, security module 110, 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.

[0013] 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 in the execution of instructions.

[0014] Security module 110 is generally a set of hardware structures configured to create, monitor, and maintain a security 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, for example, cryptographic keys, and an interface 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 processor 102 is operating in accordance with specified security parameters.

[0015] As described above, processing system 100 is generally configured to implement a confidential computing environment, and in particular to execute multiple virtual machines (VMs), also referred to as guests (e.g., VM 114), and hypervisor 116, also referred to as a host or virtual machine manager, for managing the execution of the multiple VMs. Because different VMs and, at least in some cases, hypervisor 116, 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 116. For example, processing system 100 implements VM data security by implementing secure area 118 of memory 104 that stores encrypted data. In particular, processor 102 is configured to encrypt data designated for each VM according to a corresponding private encryption key and store the encrypted data in secure area 118. Because the data is encrypted, data of one VM is protected from unauthorized access by other VMs and hypervisor 116. In at least some embodiments, cryptographic keys for VMs are managed by security module 110, and data encryption and decryption for VMs is performed by a dedicated hardware encryption / decryption module (not shown) in the memory controller (not shown) of processor 102.

[0016] In at least some embodiments, the secure computing environment of the processing system 100 provides integrity assurance by implementing a Reverse Map Table (RMP) 128. The RMP 128 is a single data structure shared across the system 100 and contains one entry for each given memory page (e.g., a 4k page) of memory that may be used by the VMs 114. The RMP 128 tracks the owner of each page of memory. A page of memory may be owned by the hypervisor 116, a specific VM 114, or the security module 110. Access to memory is controlled so that only the owner of that page can write to it. The RMP 128, in at least some embodiments, is used in conjunction with standard page tables to enforce memory restrictions and page access rights. In at least some embodiments, the processing system 100 implements a Secure Device Table (SDT) 130, which encodes device interface VM bindings and security attributes. The SDT 130, in at least some embodiments, stores security attributes for the device interfaces 120 of the I / O devices 106. For example, the SDT 130 includes a VM (guest) identifier of the VM 114 (guest) to which the device interface 120 is bound. The IOMMU 112 inspects the SDT 130 when there is traffic between the IOMMU 112 and the device interface 120, and makes a security policy decision as to whether access is permitted.

[0017] The confidential computing environment further implements I / O virtualization such that I / O devices 106 are virtualized and shared across multiple VMs 114. For example, in some embodiments, one or more I / O devices 106 are physical I / O virtualization-enabled devices that implement one or more device interfaces 120 (shown as device interface 120-1 and device interface 120-2). Each device interface 120 allows an I / O device 106 to be virtualized as a different virtual I / O device for each VM 114. As used herein, a "device interface" refers to a unit of allocation of an I / O virtualization-enabled device. In at least some embodiments, a device interface may be an entire (physical) I / O device, a non-I / O virtualized function, a virtual function (VF), etc. One example of a device interface is a Trusted Execution Environment (TEE) device interface (TDI). Security module 110 binds device interface 120 to VM 114 by using a trusted and secure registration / binding 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 106, are configured to communicate with processor 102 and IOMMU 112 according to 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 binds the I / O devices to running VMs using the TDISP security registration process. Additionally, security module 110 assigns a set of memory addresses to each running VM.Security module 110, in at least some embodiments, programs the mapping table to store an indication of the I / O devices bound to each VM and a set of memory addresses assigned to each VM.

[0018] In many confidential computing environments, the lifecycle of device interface 120 is not managed in a manner that allows VM 114 to trust device interface 120. For example, in some confidential computing environments, device interfaces are bound to VMs using an untrusted / insecure registration process, the channel / session established between the device interface and the VM is insecure, multiple device interfaces are bound to the same VM, etc. Therefore, I / O devices and their device interfaces are generally considered untrusted by VMs, which typically imposes functional and performance limitations on the system, such as I / O devices and device interfaces being restricted from accessing the VM's private memory.

[0019] To overcome these functional and performance limitations, security module 110 implements process 126 for managing the lifecycle of device interfaces 120 in a secure and trusted manner, allowing VMs 114 to trust the device interfaces 120 bound to them, such that the device interfaces 120 can access the private memory of the VMs 114 while still protecting the VMs 114 from malicious devices. Security module 110 ensures that a given VM 114 is bound to zero or more device interfaces 120, and further ensures that a device interface 120 is bound to zero or one VMs 114. A trusted channel is provided between I / O devices 106 and VMs 114, which protects the VMs 114 from physical attacks on tracing and also provides protection from snooping or masquerading by malicious machine managers.

[0020] After device interface 120 is bound to and trusted by VM 114 according to one or more of the techniques described herein, device interface 120 can access memory 104 allocated to the VM. In at least some embodiments, device interface 120 accesses memory 104 allocated to VM 114 by generating direct memory access (DMA) (e.g., DMA request 122) requests to read data from memory 104, write data to memory 104, or a combination thereof. IOMMU 112 is configured to process DMA requests issued by I / O devices 106 or associated device interfaces 120. For example, to increase processing efficiency, IOMMU 112 is generally configured to perform designated memory access operations on behalf of processor 102, i.e., to perform memory access operations using dedicated hardware in IOMMU 112 without requiring management of memory access operations by processor 102. In particular, IOMMU 112 includes dedicated hardware for performing DMA operations. In some embodiments, each DMA request issued by device interface 120 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 region of memory 104 that is the target of the DMA request. IOMMU 112 is generally configured to translate the virtual address indicated by the DMA request into a physical address in memory 104 and to interact with memory 104 to perform one or more operations (read operations, write operations, or a combination thereof) indicated by the DMA request.

[0021] In at least some embodiments, processor core 108 accesses I / O device 106 (or device interface 120) by issuing MMIO requests (e.g., MMIO 124) associated with a particular executing VM 114. Each MMIO request identifies 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, processor core 108 programs a particular register of I / O device 106 by issuing an MMIO request to write data to a memory address associated with the register. By using memory addresses to provide information to or retrieve information from I / O device 106, processor core 108 can interact with I / O device 106 by leveraging at least some of the hardware used to access system memory using a relatively simple set of access commands, thereby improving the overall efficiency of the processor core.

[0022] 2 and 3, combined, illustrate a flow diagram of a process / method 126 performed by security module 110 to manage the lifecycle of device interface 120 in a confidential computing environment, such as a trusted execution environment that implements I / O virtualization. For purposes of explanation, process 126 is described with reference to an exemplary embodiment in processing system 100 of FIG. 1, although it should be understood that in other embodiments, process 126 is performed in a processing system with a different configuration.

[0023] In block 202, an I / O device 106 is connected to a processor 102 or, for example, a system-on-chip (SoC) that includes a processor 102. As part of the connection process, the hypervisor 116 allocates a portion (e.g., a page) of the system memory 104 to the security module 110 for use as a device context page 201. In at least some embodiments, the device context page 201 is a memory resource used by the security module 110 to track the I / O device 106 during the lifecycle management process 126. For example, in at least some embodiments, the device context page 201 is an immutable memory page used by the security module 110 to identify individual I / O devices 106 and hold per-device data. The device context page 201, in at least some embodiments, is protected by the RMP 128. As part of the connection process, the security module 110 establishes a secure connection, such as a Security Protocol and Data Model (SPDM) connection, with the I / O device 106 and also establishes a secure session, such as an SPDM session, with the I / O device 106. A secure connection refers to communication between the I / O device 106, the hypervisor 116, and the security module 110. A secure session refers to a secure communication channel for providing the SPDM connection. The security module 110, in at least some embodiments, communicates with the hypervisor 116 to obtain a certificate chain for the I / O device 106. The security module 110 uses the certificate chain to establish the secure session with the I / O device 106. A digest 205 of the certificate chain 203 is stored in the device context page 201 of the I / O device 106. In at least some embodiments, the security module 110 negotiates and programs integrity and data encryption streams for the I / O device 106.The security module 110, in at least some embodiments, stores the secure connection and secure session information in the device context page 201.

[0024] At block 204, the security module 110 generates a context page 207 for one or more device interfaces 120 of the I / O device 106. In at least some embodiments, the device interface context page 207 is a memory resource used by the security module 110 to track the device interfaces 120 during the lifecycle management process 126. For example, the hypervisor 116 allocates a portion (e.g., a page) of the system memory 104 to the security module 110 for use as the device interface context page 207. In at least some embodiments, the device interface context page 207 is an immutable memory page and is protected by the RMP 128. The device interface context page 207 is used by the security module 110 to identify individual device interfaces 120 and to hold per-device interface data, such as the interface identifier (ID) of the device interface 120. A device interface context page 207, in at least some embodiments, contains state information for the device interface 120 (e.g., CONFIG_ULOCKED, CONFIG_LOCKED, RUN, ERROR, etc.), points to the device context page 201 for that I / O device 106, and points to zero or one (bound) guest context page 213. In at least some embodiments, device interface context pages 207 have SPA pointers to each other in a linked list. Each time a device interface context page 207 is created, the security module 110 adds the context page to the linked list. The device context page 201 holds the head of the list.This allows the security module 110 to determine whether other device interface context pages 207 exist before re-requesting the device context page 201, and also allows the security module 110 to determine that two existing device interface context pages 207 do not represent the same device interface 120.

[0025] At block 206, the security module 110 initializes one or more device interfaces 120 of the I / O device 106 for a security registration process. At block 208, the security module 110 manages the binding of the device interfaces 120 to the VMs 114. During the binding process, the security module 110 ensures that a given VM 114 is bound to zero or more device interfaces 120, and further ensures that a device interface 120 is bound to zero or one VM 114. In at least some embodiments, the security module 110 binds the device interfaces 120 to the VMs 114 using the TDISP process in response to receiving a bind command or request from the hypervisor 116. As part of the binding process, the hypervisor 116 maps the MMIO range associated with the device interface 120 to the GPA of the VM 114 and also provides a unique ID that is used by the VM 114 to identify the device interface 120 in VM messages sent between the VM 114 and the hypervisor 116 or between the VM 114 and the security module 110. The security module 110 verifies that the device interface 120 is not already bound to another VM 114. If so, the security module 110 does not allow the device interface 120 to be bound to the current VM 114. The security module 110 also verifies that the ID assigned to the device interface 120 by the hypervisor 116 is not already in use by another device interface 120 bound to the current VM 114. If the device interface 120 is not currently bound and the ID assigned to the device interface 120 is unique to the current VM 114, the security module 110 proceeds to transition the device interface 120 to the CONFIG_LOCKED state. At this point in the life cycle of the device interface 120, the device interface 120 cannot change its configuration.

[0026] In at least some embodiments, the security module 110 communicates with the device interface 120 or at least the hypervisor 116 to obtain an interface report 209 for the device interface 120 from the I / O device 106. The interface report 209 includes information related to the current configuration of the device interface 120, such as the MMIO range associated with the device interface 120, device-specific information, the capabilities of the device interface 120 (e.g., Address Translation Service (ATS)), the security configuration of the device interface 120, and security attributes for each MMIO range (e.g., whether the MMIO range is shareable (accessible to both the VM 114 and the hypervisor 116) or private). The security module 110 measures the interface report 209 and then returns the interface report 209 to the hypervisor 116. In at least some embodiments, the security module 110 measures the interface report 209 by computing a digest over the entire interface report 209 using a cryptographic hash algorithm. In at least some embodiments, security module 110 stores digest 211 of interface report 209 in context page 201 of device interface 120. Security module 110 uses interface report 209 to verify that the memory page containing the MIMO range meets one or more conditions, such as that the range is entirely an MMIO address, that any private MMIO range is in pre-guest RMP page state and owned by VM 114, and that any non-private memory page is in hypervisor page state. In at least some embodiments, the pre-guest RMP page state indicates that the page to which the MMIO range is mapped is allocated to VM 114 and frozen so that security module 110 can operate on the page.If the security module 110 determines that the memory page containing the MIMO range satisfies one or more conditions, the security module 110 transitions the device interface 120 to the RUN state, which indicates that the device interface 120 is bound to and accessible to the VM 114. Otherwise, the binding process fails and the device interface 120 is not bound to the VM 114. If the binding process is successful, the security module 110 registers the context page 207 of the device interface 120 with the guest context page 213 of the VM 114. The guest context page 213, in at least some embodiments, is an immutable memory page and is protected by the RMP 18. The guest context page 129 is used by the security module 110 to identify individual VMs 114 and to hold per-VM data.

[0027] At block 210, the security module 110 retrieves attestation information or objects 215 associated with the bound device interface 120, for example, in response to receiving a command or request from the hypervisor 116. Examples of attestation objects 215 include an interface report 209, a certificate chain 219 for the I / O device 106, an attestation report 217, etc. At block 212, the VM 114 retrieves digests of one or more of the attestation objects 215. FIG. 3 illustrates a more detailed flow of the processes performed at blocks 210 and 212 of FIG. 2. At block 302, the security module 110 retrieves the interface report 209 from the I / O device 106. In at least some embodiments, the security module 110 retrieves and measures the interface report 209 as part of the binding process described above with respect to block 208. At block 304, the hypervisor 116 sends a request or command to the security module 110 to retrieve the attestation report 217 from the I / O device 106. In block 306, in response to receiving a request from the hypervisor 116, the security module 110 communicates with the I / O device 106 to obtain a device attestation report 217. The attestation report 217 includes information to verify and authenticate the configuration of the I / O device 106, such as a cryptographic digest of firmware running on the I / O device 106 and a description of the security-related configuration of the I / O device. In other words, the attestation report 217 includes information that enables the VM 114 to determine whether the device interface 120 is trusted and configured such that accessing the private memory of the VM 114 will not compromise the security of the VM 114. The security module 110 measures the attestation report 217 and sends the report to the hypervisor 116. The security module 110, in at least some embodiments, stores a digest 221 of the attestation report in the context page 201 of the I / O device 106.

[0028] At block 308, the hypervisor 116 sends a request or command to the security module 110 to obtain a certificate chain 203 from the I / O device 106 to be used to establish a secure session. At block 310, in response to receiving the request from the hypervisor 116, the security module 110 communicates with the I / O device 106 to obtain the certificate chain 203. The certificate chain 203 contains information for authenticating the I / O device 106 and verifying its configuration. For example, the certificate chain 203 includes a series of certificates. Each certificate consists of a public key, metadata about the owner of that public key, and a signature of the public key and metadata by another key. The certificate chain 203 connects the key used to sign the attestation report 207 and to build a secure channel for security protocols and data models with the manufacturer of the I / O device 106. The security module 110 measures the certificate chain 203 and sends the certificate chain 203 to the hypervisor 116. At block 312, the hypervisor 116 sends the attestation objects 215 (e.g., certificate chain 203, interface report 209, attestation report 217, etc.) to the VM 114 so that the VM 114 can verify the configuration of the I / O device 106 and the configuration of the device interface 120. At block 314, the VM 114 sends a request for the digest to the hypervisor 116. At block 316, the hypervisor 116 sends the request from the VM 114 to the security module 110. At block 318, the security module 110 retrieves the digest from, for example, the context page 201 of the I / O device 106 and the context page 207 of the device interface 120 and sends the digest to the hypervisor 116. At block 320, the hypervisor 116 sends a message including the digest from the security module 110 to the VM 114.

[0029] Returning to FIG. 2 , in block 214, the VM 114 verifies the configuration of the I / O device 106 and the configuration of the device interface 120. Based on this verification process, the VM 114 makes a determination whether to trust the I / O device 106 or device interface 120. In at least some embodiments, different VMs 114 may have different opinions on the trustworthiness of a given I / O device 106 or bound device interface 120. Each VM 114 makes its own determination whether to trust the I / O device 106 or bound device interface 120. In at least some embodiments, the VM 114 uses the digest to verify the attestation object received from the hypervisor 116. In other words, the VM 114 uses the digest to determine whether the hypervisor 116 has modified the attestation object 215. For example, VM 114 uses digest 205 of certificate chain 203 to verify the signature of certificate 203 and ensure that VM 114 trusts the root Certificate Authority (CA). In another example, VM 114 uses digest 219 of attestation report 217 to ensure that the measurements included in attestation report 217 match the measurements expected by VM 114. In a further example, VM 114 uses digest 211 of interface report 209 to ensure report 209 and the hypervisor's statement about where the MMIO ranges match. VM 114 can also verify security attributes of the MMIO ranges and device-specific information. If VM 114 determines that either I / O device 106 or device interface 120 is untrusted, VM 114 provides an indication to hypervisor 116 or security module 110 that either I / O device 106, device interface 120, or both are untrusted. Security module 110 then determines that an error condition has occurred and performs one or more actions, such as unbinding device interface 120 from VM 114 or taking other security measures.If not, the process proceeds to block 216 .

[0030] At block 216, MMIO validation is performed based on the interface report 209 and the mapping of MMIO ranges to GPAs. At this point in the device interface lifecycle, MMIO access is prevented by the RMP 128 until the MMIO range is validated. In at least some embodiments, the interface report 209 lists all MMIO ranges in the system physical address (SPA) space. The interface report 209 also reports MMIO range security attributes. During the binding process described above with respect to block 208, the hypervisor 116 uses the RMP 128 to translate each MMIO SPA to a GPA. The security module 110 performs validation checks for each MMIO range. For example, the security module 110 ensures that the MMIO range is assigned to the VM 114 in the RMP 128 and that the MMIO range is contiguous in the GPA space. The security module 110 ensures that the MMIO range contains the complete range and is in a pre-guest page state. The VM 114 also performs validation checks for each MMIO in the interface report. For example, the VM 114 ensures that the MMIO range assigned by the hypervisor 116 matches the MMIO range in the interface report 209. The VM 114 also ensures that the MMIO range does not overlap with an existing validated MMIO range. If the MMIO range is determined to be invalid, an error condition occurs, and the security module 110 unbinds the device interface 120 from the VM 114. Otherwise, if the MMIO range is determined to be valid, the VM 114 sends a request to the security module 110, which marks the MMIO range as valid for the VM 114. In at least some embodiments, the VM 114 can access the MMIO range only after the MMIO range has been set as valid.

[0031] At block 218, the VM 114 sends a request to the security module 110 to add an entry for the device interface 120 to the SDT 130. At this point in the device interface lifecycle, DMA is prevented by the IOMMU until an entry for the device interface 120 is added to the SDT. In response to receiving this request, the security module 110 creates an entry for the device interface 120 in the SDT 130. The entry encodes the binding of the device interface 120 to the VM 114 and also encodes security attributes for the binding. Thus, at block 218, the VM 114 is essentially requesting the security module 110 to initiate the IOMMU 112 granting device access to VM memory. At block 220, the VM 114 uses the I / O device 106, and vice versa. For example, the VM 114 accesses the I / O device 106 by issuing MMIO requests, and the device interface 120 accesses the VM 114 by issuing DMA requests. At block 222, the security module 110 unbinds the device interface 120 from the VM 114. For example, the security module 110 verifies that all pages in the MMIO range of the device interface 120 are no longer allocated to the VM 114. The security module 110 then transitions the device interface 120 to the CONFIG_UNLOCKED state. The security module 110 also unregisters the context page 207 of the device interface 120 from the context page 213 of the VM 114. Once unbound, the device interface 120 can be bound to the same VM 114 or a different VM 114. At block 224, the security module 110 reclaims the context page 207 of the device interface 120. Alternatively, if the device interface 120 is not rebound, the security module 110 reclaims the context page 207 of the device interface 120.For example, security module 110 verifies that device interface 120 is no longer bound to VM 114. Security module 110 unregisters the context page 207 of device interface 120 from the context page 201 of that I / O device 106. Security module 110 then transitions the context page 207 of device interface 120 to a reclaim page state.

[0032] Thus, the process 126 implemented by the security module 110 to manage the lifecycle of the device interface 120 ensures a trusted environment that allows the VM 114 to assume that the operation of the device interface 120 is secure and unlikely to result in the exposure of sensitive VM information. The process 126 described above also enables providing a trusted channel between the I / O device 106 and the VM 114, which protects the VM 114 from physical attacks on tracing and further provides protection from snooping or masquerading by a malicious hypervisor.

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

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

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

[0036] 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: Binding a device interface of an input / output (I / O) device in a virtualized environment to a virtual machine (VM); certifying at least one of the device interface and the I / O device in response to binding the device interface; and configuring an input / output memory management unit (IOMMU) and memory resources associated with the VM in response to authenticating at least one of the device interface and the I / O device. method.

2. unbinding the device interface from the VM.

10. The method of claim 1.

3. In response to unbinding the device interface from the VM, binding the device interface to another VM. The method of claim 2.

4. In response to unbinding a device interface from the VM, reclaiming memory resources associated with the device interface; The memory resource is used to track a device interface during its lifecycle. The method of claim 2.

5. Binding the device interface includes: mapping a memory-mapped I / O (MMIO) range associated with the device interface to a guest physical address (GPA) of the VM; 10. The method of claim 1.

6. Binding the device interface includes: transitioning the device interface from a first state to a second state that allows a configuration of the device interface to be changed; The second state locks the configuration and allows the VM to access the device interface.

10. The method of claim 1.

7. certifying at least one of the device interface and the I / O device, providing to the VM one or more of an attestation report and a certificate chain associated with the I / O device; and providing an interface report associated with the device interface to the VM.

10. The method of claim 1.

8. certifying at least one of the device interface and the I / O device, determining that the configuration of the I / O device is valid in response to providing one or more of the attestation report and the certificate chain; and determining that the device interface configuration is valid in response to providing the interface report. The method of claim 7.

9. determining that the device interface configuration is valid includes determining that a memory-mapped I / O (MMIO) range identified in the interface report matches an MMIO range assigned to the VM by a hypervisor.

9. The method of claim 8.

10. the IOMMU and the memory resources are configured in response to determining that the configuration of the I / O device and the configuration of the device interface are valid.

9. The method of claim 8.

11. unbinding the device interface from the VM in response to at least one of determining that a configuration of the I / O device is invalid based on the attestation report or the certificate chain and determining that a configuration of the device interface is invalid based on the interface report.

9. The method of claim 8.

12. Configuring memory resources associated with the VM includes: setting an MMIO range assigned to the VM by a hypervisor as valid in response to authenticating at least one of the device interface and the I / O device.

10. The method of claim 1.

13. Configuring the IOMMU includes: creating an entry in a secure device table of the IOMMU; The entry indicates that the IOMMU is configured to provide the device interface with access to the VM's private memory.

10. The method of claim 1.

14. 1. A method comprising: Binding a device interface of an input / output (I / O) device in a virtualized environment to a virtual machine (VM); In response to binding the device interface, providing to the VM credentials associated with at least one of the device interface and the I / O device; receiving an indication from the VM that one or more of the device interface and the I / O device are untrusted in response to providing the certification information; and unbinding the device interface from the VM in response to receiving the indication. method.

15. Providing the certification information includes: providing to the VM one or more of an attestation report and a certificate chain associated with the I / O device; and providing an interface report associated with the device interface to the VM.

15. The method of claim 14.

16. Providing the certification information includes: providing one or more of a digest of the attestation report and a digest of the certificate chain to the VM; providing a digest of the interface report to the VM.

16. The method of claim 15.

17. the indication received from the VM is based on one or more of: a comparison of a digest of the certificate report to the certificate report; a comparison of a digest of the certificate chain to the certificate chain; and a comparison of a digest of the interface report to the interface report.

17. The method of claim 16.

18. A security module configured to perform the method of any of claims 1 to 17. Processor.

Images