Lifecycle management for device input / output interfaces in virtualized environments

Abstract

A security module of a processor manages a lifecycle of a device interface of an input / output (I / O) device within 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 the device interface being bound, the security module is configured to attestation at least one of the device interface and the I / O device. In response to the at least one of the device interface or the I / O device being attestation, the security module is configured to configure an input / output memory management unit (IOMMU) and memory resources associated with the VM.

Description

Background Art

[0001] In a confidential computing environment, a processing system (e.g., a server) executes 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 executed by the environment are owned by different companies. The virtual machine manager (e.g., hypervisor) controls the assignment of environment resources to different virtual machines and provides an interface between the virtual machines and the server hardware, enabling each VM to operate as if it were executing on its own dedicated hardware. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0003] Figure 1 is a block diagram of a processing system that employs a security module to manage the lifecycle of a device interface of an input / output device in a virtualized environment, according to some embodiments.

[0004] Figure 2 and Figure 3 Together, flowcharts of methods for managing the lifecycle of a device interface in a secure and trusted manner according to some embodiments are illustrated. DETAILED DESCRIPTION

[0005] Confidential computing environments implement various security features to protect VMs from malicious attacks by untrusted devices or components. For example, a security feature may be implemented by a virtual machine manager that prevents one VM from accessing data (or other information) associated with another VM. This approach typically treats the virtual machine manager as 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 to protect the VM from malicious virtual machine managers accessing a given VM's confidential information. For example, in computing environments such as cloud-based computing environments, an entity may want to protect its VM-based workloads from cloud administrators to ensure the confidentiality of its data and minimize its exposure to vulnerabilities in the cloud provider's infrastructure. Therefore, some confidential computing environments implement security features that isolate VMs from the virtual machine manager and other code that may coexist on the physical server at the hardware level. For example, each VM is assigned a unique Advanced Encryption Standard (AES) encryption key, which is used to automatically encrypt data in use by each VM. When a component such as a virtual machine manager attempts to read memory within the VM, the component only sees the encrypted bytes. In another example, the VM register state is encrypted at each virtual machine manager transition, preventing the virtual machine manager from seeing the data that the VM is actively using. In yet another example, the integrity of the VM is protected by introducing a reverse mapping table (RMP) to record and check the ownership of the VM's memory pages. If the VM can read a private (encrypted) memory page, it must always read the value it last wrote.

[0006] While these and other security features protect VMs from a variety of attacks performed by malicious hypervisors, other VMs, and input / output (I / O) devices, these security features impose performance and functionality 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 the device interfaces is not managed in a secure or trusted manner. As a result, I / O devices and their interfaces are often considered untrusted devices and are not allowed to access the private memory of the VM, which leads to performance and functionality issues associated with VM memory access.

[0007] To overcome the functional and performance limitations of typical VM security features described above, a processing system using the techniques described herein employs a security module (e.g., a security coprocessor) to manage the lifecycle of a device interface in a manner that enables the VM to "trust" the device interface and its associated I / O devices. In other words, the VM can be certain that the operation of the device interface is secure and unlikely to result in the exposure of confidential 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.

[0008] As described below, the life cycle of a device interface includes different stages, such as device initialization, binding, certification, configuration, use, unbinding, rebinding or recycling, and device removal (deinitialization). During the binding phase, the system physical address (SPA) of the memory mapped input / output (MMIO) range is mapped to the guest physical address (GPA) of the VM, and the state of the device interface is transformed 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 certification phase includes certifying the I / O device and the device interface. For example, a certification report and a certificate chain for verifying the configuration of the I / O device are provided to the VM. An interface report for verifying the configuration of the device interface (such as, MMIO range layout) is also provided to the VM. The configuration phase includes configuring 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 unbinding phase includes unbinding the device interface from the VM and recovering from any I / O device or VM error state. The unbound device interface may then be rebound to the VM or its resources, such as a context page, or the device interface may be reclaimed.

[0009] These stages of the device interface lifecycle 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 implementing I / O device attestation operations, protecting I / O device configurations, and enabling VMs to mediate device interface assignments. VMs may have different judgments on the trustworthiness of device interfaces and may determine whether a device interface is trustworthy based on, for example, attestation reports, certificate chains, and interface reports. Furthermore, a VM can be bound to zero or more device interfaces, while a device interface can be bound to zero or one VM. Providing a trusted channel between the I / O device and the VM protects the VM from physical attacks targeting traces and also provides protection from snooping or masquerading by malicious machine managers. Furthermore, by allowing DMA into private ranges for the guest, performance is improved compared to conventional I / O virtualization environments, eliminating expensive bounce buffers.

[0010] Figure 1 A processing system 100 is illustrated that implements a lifecycle management process for a device interface of an I / O device according to some embodiments. The 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 various implementations, the processing system 100 is part of any of a variety of electronic devices. For purposes of this description, it is assumed that the processing system 100 is part of an electronic device (such as a server) that implements a confidential computing environment. However, in other implementations, the processing system 100 is part of a desktop computer, a laptop computer, a tablet computer, a game console, etc.

[0011] To implement a confidential computing environment and to execute the instruction set and corresponding operations, the processing system 100 includes a processor 102, a memory 104, and one or more input / output (I / O) devices, such as an I / O device 106. In some implementations, the processor 102 is a general-purpose processor, such as a central processing unit (CPU) that includes a hardware structure configured to retrieve and execute the instruction set. The memory 104 includes one or more memory devices that are configured to store and retrieve data based on commands (e.g., store and load commands) received from the processor 102. Thus, in different implementations, the memory 104 is a random access memory (RAM), a non-volatile memory (NVM), a storage device, or the like, or any combination thereof.

[0012] I / O device 106 is any device that can process input information, output information, or a combination thereof on behalf of processing system 100, independent of processor 102. For example, in some implementations, 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 implementations, 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, the processor 102 includes a processor core 108, a security module 110, and an input / output memory management unit (IOMMU) 112. It should be understood that in some implementations, the processor 102 includes additional hardware for executing instructions and performing operations based on those instructions, such as additional processor cores, additional processing units (e.g., one or more graphics processing units), one or more controllers (e.g., a memory controller and an input / output controller), etc.

[0014] The 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 implementations, the instruction pipeline of the processor core 108 includes a fetch stage, a decode stage, a dispatch stage, one or more execute stages (using one or more corresponding execution units), a retire stage, etc. The processor core 108 also includes or has access to memory structures and other hardware that supports instruction execution ( Figure 1 For example, in some implementations, processor core 108 includes or has access to one or more cache structures to store data used to execute instructions.

[0015] The security module 110 is a set of hardware structures that are generally configured to create, monitor, and maintain a secure environment for the processor 102. For example, in at least some implementations, the security module 110 is configured to manage the boot process of the processor 102, initialize the security-related mechanisms of the processor 102, and monitor the processing system 100 for suspicious activities or events and implement appropriate responses. In some implementations, the 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 includes interfaces for interacting with the memory 104, the I / O controller of the processor 102, and the configuration registers of the processor 102. In some implementations, the security module 110 includes environmental management control hardware that performs environmental and security checks to ensure that the processor 102 operates according to specified security parameters.

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

[0017] In at least some implementations, the confidential computing environment of processing system 100 provides integrity assurance by implementing a reverse mapping table (RMP) 128. RMP 128 is a single data structure shared across system 100 and includes an entry for each given memory page (e.g., a 4K page) of memory that can be used by VM 114. RMP 128 tracks the owner of each page of memory. A page of memory can be owned by hypervisor 116, a specific VM 114, or security module 110. Access to memory is controlled so that only the owner of the page can write to it. In at least some implementations, RMP 128 is used in conjunction with standard page tables to enforce memory restrictions and page access permissions. In at least some implementations, processing system 100 also implements a secure device table (SDT) 130 that encodes device interface VM bindings and security attributes. In at least some implementations, SDT 130 is a repository of security attributes for device interface 120 of I / O device 106. For example, SDT 130 includes the VM (guest) identifier of VM 114 (guest) to which device interface 120 is bound. When traffic enters or exits device interface 120, IOMMU 112 checks SDT 130 to make a security policy decision about whether to allow access.

[0018] The confidential computing environment also implements I / O virtualization, such that I / O devices 106 are virtualized and shared across multiple VMs 114. For example, in some implementations, one or more I / O devices 106 are devices that support physical I / O virtualization and implement one or more device interfaces 120 (illustrated as device interface 120-1 and device interface 120-2). Each device interface 120 allows the I / O device 106 to be virtualized as a different virtual I / O device for each VM 114. As used herein, "device interface" refers to a unit of assignment for a device that supports I / O virtualization. In at least some implementations, a device interface is an entire (physical) I / O device, a non-I / O virtualization function, a virtual function (VF), etc. An example of a device interface is a trusted execution environment (TEE) device interface (TDI). The security module 110 binds the device interface 120 to the VM 114 using a trusted and secure registration / binding process, such as a trusted execution environment (TEE) device interface security protocol (TDISP) process. For example, in some embodiments, the processing system 100 includes a communication structure (not shown) that complies with the Peripheral Component Interconnect Express (PCIe) communication protocol. Specifically, the I / O device (such as, I / O device 106) is configured to communicate with the processor 102 and the IOMMU 112 according to the PCIe communication protocol. In some embodiments, the PCIe communication protocol establishes a TDISP security registration process for binding the I / O device to the VM, and the security module 110 uses the TDISP security registration process to bind the I / O device to the execution VM. In addition, the security module 110 assigns a set of memory addresses to the corresponding execution VM. In at least some embodiments, the security module 110 programs a mapping table to store an indication of the I / O device bound to each VM and a set of memory addresses assigned to each VM.

[0019] In many confidential computing environments, the lifecycle of the device interface 120 is not managed in a manner that allows the VM 114 to trust the device interface 120. For example, in some confidential computing environments, an untrusted / unsecure registration process is used to bind the device interface to the VM, the channel / session established between the device interface and the VM is unsecured, multiple device interfaces are bound to the same VM, etc. As a result, I / O devices and their device interfaces are often considered untrusted by the VM, which often imposes functional and performance restrictions on the system, such as restricting the I / O devices and device interfaces from accessing the VM's private memory.

[0020] To overcome these functional and performance limitations, security module 110 implements a process 126 for managing the lifecycle of device interfaces 120 in a secure and trusted manner, allowing VM 114 to trust device interfaces 120 bound to VM 114, allowing device interfaces 120 to access VM 114's private memory while still protecting VM 114 from malicious devices. Security module 110 ensures that a given VM 114 is bound to zero or more device interfaces 120, and also ensures that a device interface 120 is bound to zero or one VM 114. This provides a trusted channel between I / O devices 106 and VM 114, protecting VM 114 from physical attacks directed at traces and also providing protection from snooping or impersonation by malicious machine managers.

[0021] After the device interface 120 is bound to the VM 114 and trusted by the VM according to one or more of the techniques described herein, the device interface 120 is able to access the memory 104 assigned to the VM. In at least some implementations, the device interface 120 accesses the memory 104 assigned to the VM 114 by generating direct memory access (DMA) requests (e.g., DMA requests 122) to read data from the memory 104, write data to the memory 104, or a combination thereof. The IOMMU 112 is configured to process DMA requests issued by the I / O device 106 or the associated device interface 120. For example, to improve processing efficiency, the IOMMU 112 is typically configured to perform specified memory access operations on behalf of the processor 102—that is, the memory access operations are performed using the dedicated hardware of the IOMMU 112, and the processor 102 is not required to manage the memory access operations. Specifically, the IOMMU 112 includes dedicated hardware for performing DMA operations. In some implementations, each DMA request issued by the 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 of the data to be written, or both). These virtual addresses indicate the area of the memory 104 targeted by the DMA request. The IOMMU 112 is typically configured to translate the virtual address indicated by the DMA request into a physical address of the memory 104 and interact with the memory 104 to perform one or more operations (read operations, write operations, or a combination thereof) indicated by the DMA request.

[0022] In at least some implementations, the processor core 108 accesses the I / O device 106 (or device interface 120) by issuing MMIO requests (e.g., MMIO 124) associated with a particular execution 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, the processor core 108 programs a particular register of the 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 the I / O device 106, the processor core 108 is able to interact with the I / O device 106 using a relatively simple access command set and by utilizing at least some of the hardware for accessing system memory, thereby improving the overall efficiency of the processor core.

[0023] Figure 2 and Figure 3 The flowchart of the process / method 126 implemented by the security module 110 for managing the life cycle of the device interface 120 in a confidential computing environment (such as a trusted execution environment) that implements I / O virtualization is illustrated in combination. For the purpose of description, the process 126 is relative to Figure 1 1. The process 126 is described with reference to an example implementation at a computing system 100, but it should be understood that in other implementations, the process 126 is implemented at a processing system having a different configuration.

[0024] At block 202, an I / O device 106 is connected to the processor 102, or, for example, to a system-on-chip (SoC) that includes the processor 102. As part of the connection process, the hypervisor 116 allocates a portion (e.g., a page) of system memory 104 to the security module 110 for use as a device context page 201. In at least some implementations, the device context page 201 is used by the security module 110 to track the memory resources of the I / O device 106 during the lifecycle management process 126. For example, in at least some implementations, the device context page 201 is an immutable memory page used by the security module 110 to identify each I / O device 106 and store per-device data. In at least some implementations, the device context page 201 is protected by the RMP 128. As part of the connection process, the security module 110 also 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 the communication between the I / O device 106, the hypervisor 116, and the security module 110. A secure session refers to the secure communication channel used to provide the SPDM connection. In at least some implementations, the security module 110 communicates with the hypervisor 116 to obtain the certificate chain of the I / O device 106. The security module 110 uses the certificate chain to establish a 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 implementations, the security module 110 also negotiates and programs the integrity and data encryption flow of the I / O device 106. In at least some implementations, the security module 110 stores the secure connection and secure session information in the device context page 201.

[0025] At block 204, the security module 110 creates a context page 207 for one or more device interfaces 120 of the I / O device 106. In at least some implementations, the device interface context page 207 is used by the security module 110 to track memory resources of the device interface 120 during the lifecycle management process 126. For example, the hypervisor 116 allocates a portion (e.g., a page) of system memory 104 to the security module 110 for use as the device interface context page 207. In at least some implementations, 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 each device interface 120 and to store per-device interface data, such as an interface identifier (ID) of the device interface 120. In at least some implementations, a device interface context page 207 includes status information for a device interface 120 (e.g., CONFIG_ULOCKED, CONFIG_LOCKED, RUN, ERROR, etc.), a pointer to the device context page 201 for its I / O device 106, and zero or one (bound) client context pages 213. In at least some implementations, the device interface context pages 207 have SPA pointers pointing 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 reclaiming a device context page 201, and also allows the security module 110 to determine that no two existing device interface context pages 207 represent the same device interface 120.

[0026] At block 206, the security module 110 initializes one or more device interfaces 120 of the I / O device 106 for a secure 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 also ensures that the device interface 120 is bound to zero or one VM 114. In at least some implementations, the security module 110 binds the device interface 120 to the VM 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 VM 114's GPA 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 checks whether the device interface 120 is 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 checks whether the ID assigned to the device interface 120 by the hypervisor 116 is already in use by another device interface 120 bound to the current VM 114. If the device interface 120 is currently unbound 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 lifecycle of the device interface 120, the device interface 120 cannot change its configuration.

[0027] In at least some implementations, 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, capabilities of the device interface 120 (e.g., address translation service (ATS)), the security configuration of the device interface 120, and security attributes per MMIO range (e.g., whether the MMIO range is allowed to be shared (accessible by both the VM 114 and the hypervisor 116) or whether it is 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 implementations, the security module 110 measures the interface report 209 by computing a digest of the entire interface report 209 using a cryptographic hash algorithm. In at least some implementations, security module 110 stores summary 211 of interface report 209 in context page 201 of device interface 120. Security module 110 uses interface report 209 to check that the memory page containing the MIMO range meets one or more conditions, such as whether the range is a full MMIO address, whether any private MMIO range is in pre-client RMP page state and owned by VM 114, and whether any non-private memory page is in hypervisor page state. In at least some implementations, the pre-client RMP page state indicates that the page to which the MMIO range is mapped is assigned to VM 114 and frozen, allowing security module 110 to operate on it. If security module 110 determines that the memory page containing the MIMO range meets the one or more conditions, security module 110 transitions device interface 120 to the RUN state, indicating that device interface 120 has been bound to VM 114 and is accessible to it. Otherwise, the binding process fails, and device interface 120 is not bound to VM 114. If the binding process is successful, security module 110 registers context page 207 of device interface 120 with guest context page 213 of VM 114. In at least some implementations, guest context page 213 is an immutable memory page and is protected by RMP 18. Guest context page 129 is used by security module 110 to identify individual VMs 114 and to store per-VM data.

[0028] At block 210, the security module 110 obtains attestation information or objects 215 associated with the bound device interface 120 in response to, for example, receiving a command or request from the hypervisor 116. Examples of attestation objects 215 include the interface report 209, the certificate chain 219 of the I / O device 106, the attestation report 217, etc. At block 212, the VM 114 obtains a digest of one or more of the attestation objects 215. Figure 3 Shown in Figure 2 2. A more detailed flow of the processes performed at blocks 210 and 212 of FIG. At block 302, security module 110 obtains interface report 209 from I / O device 106. In at least some implementations, security module 110 obtains and measures interface report 209 as part of the binding process described above with respect to block 208. At block 304, hypervisor 116 sends a request or command to security module 110 to obtain attestation report 217 from I / O device 106. At block 306, in response to receiving the request from hypervisor 116, security module 110 communicates with I / O device 106 to obtain device attestation report 217. Attestation report 217 includes information used to verify and authenticate the configuration of I / O device 106, such as a cryptographic digest of the firmware running on I / O device 106, a description of the security-related configuration of the I / O device, and the like. In other words, attestation report 217 includes information that allows VM 114 to determine whether device interface 120 is trustworthy and configured in a manner that does not violate the security of VM 114 if device interface 120 accesses private memory of VM 114. Security module 110 measures attestation report 217 and sends the report to hypervisor 116. In at least some implementations, security module 110 stores a summary 221 of the attestation report in context page 201 of I / O device 106.

[0029] At block 308, hypervisor 116 sends a request or command to security module 110 to obtain certificate chain 203 from I / O device 106, which is used to establish a secure session. At block 310, in response to receiving the request from hypervisor 116, security module 110 communicates with I / O device 106 to obtain certificate chain 203. Certificate chain 203 includes information used to authenticate I / O device 106 and verify its configuration. For example, certificate chain 203 includes a sequence of certificates. Each certificate consists of a public key, metadata about the owner of the public key, and another key signing the public key and metadata. Certificate chain 2003 is linked to the keys used to sign attestation report 207 and establish a secure channel with the manufacturer of the I / O device 106 using security protocols and data models. Security module 110 measures certificate chain 203 and sends it to hypervisor 116. At block 312, hypervisor 116 sends attestation objects 215 (e.g., certificate chain 203, interface report 209, attestation report 217, etc.) to VM 114 so that VM 114 can verify the configuration of I / O device 106 and the configuration of device interface 120. At block 314, VM 114 sends a request for a digest to hypervisor 116. At block 316, hypervisor 116 sends the request from VM 114 to security module 110. At block 318, security module 110 retrieves the digests from, for example, context page 201 of I / O device 106 and context page 207 of device interface 120, and sends these digests to hypervisor 116. At block 320, hypervisor 116 sends a message from security module 110 to VM 114, including the digests.

[0030] return Figure 2At block 214, VM 114 verifies the configuration of I / O device 106 and the configuration of device interface 120. Based on this verification process, VM 114 determines whether it trusts I / O device 106 or device interface 120. In at least some implementations, different VMs 114 may differ in their determination of the trustworthiness of a given I / O device 106 or bound device interface 120. Each VM 114 makes its own decision about whether to trust an I / O device 106 or bound device interface 120. In at least some implementations, VM 114 uses a digest to verify the attestation object received from hypervisor 116. In other words, VM 114 uses the digest to determine whether hypervisor 116 has altered 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 summary 219 of attestation report 217 to ensure that the measurements included in attestation report 217 match the measurements expected by VM 114. In yet another example, VM 114 uses summary 211 of interface report 209 to ensure that report 209 is consistent with the hypervisor's declaration of the MMIO range. VM 114 may also verify the security attributes and device-specific information of the MMIO range. If VM 114 determines that it cannot trust I / O device 106 or device interface 120, VM 114 provides an indication to hypervisor 116 or security module 110 that either or both of I / O device 106 and device interface 120 are untrustworthy. 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 another security action. Otherwise, the process continues to block 216.

[0031] 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, the RMP 128 blocks MMIO access until the MMIO ranges are validated. In at least some implementations, the interface report 209 enumerates 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 convert each MMIO SPA to a GPA. The security module 110 performs validation checks on 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 also ensures that the MMIO range includes a complete range and is in a pre-client page state. The VM 114 also performs validation checks on each MMIO in the interface report. For example, VM 114 ensures that the MMIO range assigned by hypervisor 116 is consistent with the MMIO range in interface report 209. VM 114 also ensures that the MMIO range does not overlap with an existing verified MMIO range. If the MMIO range is determined to be invalid, an error state occurs, and security module 110 unbinds device interface 120 from VM 114. Otherwise, if the MMIO range is determined to be valid, VM 114 sends a request to security module 110, and security module 110 marks these MMIO ranges as verified by VM 114. In at least some specific implementations, VM 114 can only access the MMIO range after the MMIO range is set to verified.

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

[0033] Thus, the process 126 implemented by the security module 110 for managing 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 confidential VM information. The process 126 described above also allows for a trusted channel to be provided between the I / O device 106 and the VM 114, which protects the VM 114 from physical attacks directed at the traces and also provides protection from snooping or masquerading by malicious hypervisors.

[0034] In some embodiments, certain aspects of the technology described above can be implemented by one or more processors of a processing system that executes software. The software includes one or more sets of executable instructions that are stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate the one or more processors to perform one or more aspects of the technology 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 a flash memory, a cache, a random access memory (RAM), or other one or more non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executed by one or more processors.

[0035] Computer-readable storage media may include 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 tapes, or 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 microelectromechanical system (MEMS)-based storage media. Computer-readable storage media may be embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard drive), removably attached to a computing system (e.g., an optical disc or flash memory based on a universal serial bus (USB)), or coupled to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0036] It should be noted that not all activities or elements described above in the general description are required, a particular activity or part of the device may not be required, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. In addition, these concepts have been described with reference to specific implementations. However, it is understood by those skilled in the art that various modifications and changes may be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present disclosure.

[0037] Benefits, other advantages and solutions to problems have been described above with respect to specific implementations. However, benefits, advantages, solutions to problems, and any features that may cause any benefit, advantage, or solution to appear or become more pronounced should not be construed as key, required, or essential features of any or all of the claims. Furthermore, the specific implementations disclosed above are merely illustrative, as the disclosed subject matter may be modified and practiced in different but equivalent manners that would be apparent to one skilled in the art having the benefit of the teachings herein. No limitation is intended to the details of construction or design shown herein, except as described in the claims below. It is therefore apparent that the specific implementations disclosed above may be changed or modified, and all such variations are considered to be within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

1. A method comprising: Binding device interfaces of input / output (I / O) devices within a virtualized environment to virtual machines (VMs); responsive to binding the device interface, certifying at least one of the device interface and the I / O device; as well as In response to attesting the at least one of the device interface or the I / O device, an input-output memory management unit (IOMMU) and memory resources associated with the VM are configured.

2. The method according to claim 1, further comprising: Unbind the device interface from the VM.

3. The method according to claim 2, further comprising: In response to unbinding the device interface from the VM, the device interface is bound to another VM.

4. The method according to claim 2, further comprising: In response to unbinding the device interface from the VM, memory resources associated with the device interface are reclaimed, wherein the memory resources are used to track the device interface during a lifecycle of the device interface.

5. The method according to any one of claims 1 to 4, wherein binding the device interface comprises: A memory mapped I / O (MMIO) range associated with the device interface is mapped to a guest physical address (GPA) of the VM.

6. The method according to any one of claims 1 to 5, wherein binding the device interface further comprises: The device interface is transitioned from a first state that allows changes to a configuration of the device interface to a second state that locks the configuration and allows the VM to access the device interface.

7. The method of any one of claims 1 to 6, wherein certifying the at least one of the device interface or the I / O device comprises: providing the VM with one or more of an attestation report or a certificate chain associated with the I / O device; as well as An interface report associated with the device interface is provided to the VM.

8. The method of claim 7, wherein certifying the at least one of the device interface or the I / O device further comprises: In response to providing the one or more of the attestation report or the certificate chain, determining that the configuration of the I / O device is valid; as well as In response to providing the interface report, it is determined that the configuration of the device interface is valid.

9. The method of claim 8, wherein determining that the configuration of the device interface is valid comprises: A determination is made that a memory mapped I / O (MMIO) range identified in the interface report matches an MMIO range assigned to the VM by a hypervisor.

10. The method of claim 8, wherein the IOMMU and the memory resource are configured in response to determining that the configuration of the I / O device and the configuration of the device interface are valid.

11. The method according to claim 8 further includes unbinding the device interface from the VM in response to at least one of the following: determining that the configuration of the I / O device is invalid based on the attestation report or the certificate chain, or determining that the configuration of the device interface is invalid based on the interface report.

12. The method according to any one of claims 1 to 11, wherein configuring the memory resources associated with the VM comprises: In response to asserting the at least one of the device interface or the I / O device, setting an MMIO range assigned by a hypervisor to the VM as valid.

13. The method according to any one of claims 1 to 12, wherein configuring the IOMMU comprises: An entry is created in a secure device table for the IOMMU, wherein the entry indicates that the IOMMU is configured to provide the device interface with access to a private memory of the VM.

14. A method comprising: Binding device interfaces of input / output (I / O) devices within a virtualized environment to virtual machines (VMs); In response to binding the device interface, providing, to the VM, certification information associated with at least one of the device interface and the I / O device; receiving, in response to providing the attestation information, an indication from the VM that one or more of the device interface or the I / O device is not trusted; as well as In response to receiving the indication, the device interface is unbound from the VM.

15. The method of claim 14, wherein providing the certification information comprises: providing the VM with one or more of an attestation report or a certificate chain associated with the I / O device; as well as An interface report associated with the device interface is provided to the VM.

16. The method according to claim 15, wherein providing the certification information further comprises: providing one or more of a digest of the attestation report or a digest of the certificate chain to the VM; as well as A summary of the interface report is provided to the VM.

17. A method according to claim 16, wherein the indication received from the VM is based on a comparison of one or more of: the summary of the attestation report and the attestation report, the summary of the certificate chain and the certificate chain, or the summary of the interface report and the interface report.

18. A processor comprising a security module, the security module being configured to execute the method according to any one of claims 1 to 17.

Images