Secure mapping of process address space identifiers for computing environments implementing input / output virtualization

Abstract

The processor includes a virtual machine manager (VMM) configured to map a guest process address space identifier (PASID) associated with a virtual machine (VM) to a host PASID associated with a host machine of the VM. The processor includes a processor core configured to maintain an entry in a PASID reverse mapping table (PMP) that includes one or more security attributes associated with the host PASID in response to the guest PASID being mapped to the host PASID.

Description

[Background technology]

[0001] Processing systems (e.g., servers) often use virtualized execution environments to combine and scale the processing system's physical and logical resources. For example, a processing system executes virtual machines (guests). A virtual machine is a software entity that emulates or otherwise interfaces with the processing system's hardware to provide support for running software programs. A virtual machine can use hardware elements (e.g., processor, memory, network interface, etc.) in the processing system to provide support for running one or more instances of an operating system, referred to as a guest operating system. The guest operating system, in turn, provides support for running other software programs, such as applications and databases. A virtual machine manager or monitor (e.g., a hypervisor) controls the scheduling of different virtual machines for execution 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. In another example, a processing system virtualizes one or more of its input / output devices, such as controllers (e.g., bus, interconnect, and / or fabric controllers, network interface controllers, etc.), processors / accelerators (e.g., graphics processors, cryptographic accelerators, compression accelerators), and any other resources that can be addressed within the processing system. Virtualization of input / output devices allows a physical device to appear as multiple physical devices to a host machine or virtual machine.

[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 secure mapping of process address space identifiers (PASIDs) for a virtualized computing / execution environment, according to some embodiments. [Figure 2] FIG. 1 illustrates an example of a PASID mapping table configuration, according to some embodiments. [Figure 3] FIG. 2 illustrates an example of a PASID reverse map table (PMP), according to some embodiments. [Figure 4] 4 is a block diagram illustrating an example of a virtual machine manager (VMM) of the processing system of FIG. 1 implementing a PMP update process to add a host PASID security attribute to the PMP of FIG. 3 in accordance with some embodiments. [Figure 5] 1 is a block diagram illustrating an example of a virtual machine (VM) of the processing system of FIG. 1 that performs a PMP verification process to verify the contents of an entry in the PMP of FIG. 3 for a host PASID associated with the VM's guest PASID, according to some embodiments. [Figure 6] 2 is a block diagram illustrating an example of a processing core of the processing system of FIG. 1 that performs a PMP check process in response to receiving an enqueue command from a VM to ensure that the PMP includes the VM's guest PASID and guest identifier, according to some embodiments. [Figure 7] FIG. 1 is a block diagram illustrating a detailed view of the PMP check process, according to some embodiments. [Figure 8] 1A-1D together illustrate an exemplary method for secure management of PASID mappings in a computing environment implementing virtualized input / output devices, according to some embodiments. [Figure 9]1A-1D together illustrate an exemplary method for secure management of PASID mappings in a computing environment implementing virtualized input / output devices, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] Various techniques may be implemented by a processing system for virtualizing input / output (I / O) devices. One example of an I / O virtualization technique is single-root I / O virtualization (SR-IOV), which enables multiple virtual machines (also referred to herein as guests or VMs) to share Peripheral Component Interconnect Express (PCIe) hardware resources under a single node system (e.g., a single-root complex). For example, an SR-IOV device enables a physical device, such as a network interface controller (NIC), to appear as multiple NICs to a VM or a host machine. Thus, multiple VMs on a host machine can share a single PCIe device. In an SR-IOV environment, a hypervisor (also referred to as a virtual machine manager or monitor (VMM)) maps one or more logical interfaces (i.e., virtual functions) to a VM, with each logical interface appearing as a single input / output device to the host operating system (OS). However, the number of virtualized instances (e.g., virtual functions) of a given hardware type, such as a NIC or bus, is limited. For example, a NIC is limited by hardware constraints regarding the number of virtual functions it can support. Thus, SR-IOV limits the number of virtual functions of an input / output device, thereby limiting the number of VMs that can utilize the virtual functions.

[0005] Scalable I / O Virtualization (SIOV) attempts to overcome scalability and other issues associated with SR-IOV. SIOV is a PCIe-based virtualization technology that provides scalable sharing of I / O devices across virtualized execution environments. Unlike SR-IOV's coarse-grained device partitioning approach to creating multiple virtual functions on a device, SIOV allows software to flexibly configure virtual devices with hardware assistance for device sharing at a finer granularity. Performance-critical operations on the configured virtual devices are mapped directly to the underlying device hardware, while non-critical operations are emulated via device-specific configuration software in the host.

[0006] SIOV scales device interactions by implementing shared work queues (SWQs) and a type of memory access over PCIe called deferrable memory writes. For example, an SIOV-enabled device is configured to group its resources into multiple isolated assignable device interfaces (ADIs), which form the unit of device allocation and isolation to form virtual devices. An ADI is associated with an SWQ for work submission, and an SWQ is an interface that can be used simultaneously by different VMs. In other words, an SWQ allows multiple VMs to submit work requests to the same ADI. A VM process submits work requests to an SWQ using deferrable memory writes (DMWr). A DMWr is a write that can temporarily fail due to unavailability of the underlying resource. Such a failure indicates that the process should retry accessing the SWQ. When a process in a VM writes to a register in the SWQ to submit a work request / descriptor to the ADI, the process uses an instruction to generate a DMWr to that register. That is, the instruction used by the process atomically submits the work descriptor to the SWQ. More generally, this instruction is an "enqueue command" to write a command to an "enqueue register," which is a special device register accessed using memory-mapped I / O (MMIO). Examples of this instruction include Enqueue Command (ENQCMD) and Enqueue Command Supervisor (ENQCMDS).

[0007] In SIOV, clients of an ADI are identified using a process address space identifier (PASID), a unique identifier that isolates the process address space used by the guest (VM) OS and links the client's access to memory views and access rights. The PASID is used to distinguish upstream memory transactions performed on different ADIs and convey the address space targeted by the transaction. This contrasts with SR-IOV, where clients (e.g., processes in VMs) interact with the SR-IOV interface using interface-specific MMIO addresses. In non-virtualized environments, the OS manages the assignment of PASIDs to processes, for example, using a model-specific register (MSR). This MSR allows the application address space to be associated with a PASID. When a scheduler context switches to a process, the OS sets the MSR to the appropriate PASID. Instructions such as ENQCMD then use the MSR to attach the PASID to DMWr requests to input / output device work queues. However, in a virtualized system, a guest OS assigns multiple PASIDs to its processes. Therefore, the VMM virtualizes the PASIDs associated with a VM. That is, the VMM transparently maps the PASIDs assigned by the guest OS to actual PASIDs, giving the guest OS the view that it owns the entire PASID space. As part of this PASID mapping process, the VMM uses a memory data structure to point to a mapping table that maps guest PASIDs to host PASIDs. Therefore, when a guest process invokes an enqueue command, the PASID written by the VM process is automatically translated by the processor to a host PASID and written to the SWQ via the DMWr.

[0008] While SIOV allows many different VMs to access a single input / output device resource without the constraints imposed by SR-IOV, SIOV is generally not designed with security or confidential computing in mind, which can make it difficult to implement in a confidential computing environment. For example, the mapping from guest PASID to host PASID and from host PASID to guest context in the I / O device are trusted by the VMM in the SIOV. However, the VMM is not typically considered a trusted device in a confidential computing environment because the VMM could act maliciously or introduce security risks into the environment. For example, the VMM could maliciously execute a DMWr with the VM's PASID and gain access to an isolated domain in the SIOV.

[0009] Accordingly, this disclosure describes embodiments of systems and methods for securely managing PASID mapping in a confidential computing environment that implements input / output virtualization, such as SIOV or the like, according to some embodiments. As described in more detail below, one or more techniques are implemented that allow the VMM to indirectly allocate PASIDs to VMs while not allowing any authority in the VMM to change the mapping. For example, in at least some embodiments, the VMM is configured to allocate a table, such as a system-global PASID reverse map table (PMP), indexed by host PASID. When a VM process invokes an enqueue command to submit a work request to a device interface (e.g., ADI) via a SWQ, the processor translates the guest PASID to the host PASID using one or more translation techniques. The processor then indexes the PMP table with the resulting host PASID. If the PMP entry associated with the host PASID includes the guest PASID and an identifier of the accessing VM process, the processor determines that the access is valid, and the enqueue command proceeds. Otherwise, the processor determines that the VMM has changed the PASID mapping, and the enqueue command fails. For example, the processor may issue an error message to the VMM or the VM, or both, which prevents the enqueue command from being processed. Thus, the techniques described herein provide for secure management of PASID mapping by the VMM and protect the VM from malicious PASID modification.

[0010] 1 illustrates a processing system 100 that implements secure PASID mapping for a virtualized computing / execution environment, according to some embodiments. One or more techniques presented herein are described with respect to scalable input / output virtualization, but it should be understood that these techniques are applicable to any virtualization architecture, framework, or specification that implements PASID mapping for virtualized resources.

[0011] 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. Accordingly, processing system 100 may be part of a variety of electronic devices in different embodiments. For purposes of explanation, it will be assumed that processing system 100 is part of an electronic device implementing a secure computing environment, such as a server. However, in other embodiments, processing system 100 may be part of a desktop computer, a laptop computer, a tablet, a game console, or the like.

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

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

[0014] To execute the instruction set and corresponding operations, 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 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.

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

[0016] Security module 110 is a set of hardware structures generally configured to create, monitor, and maintain a secure environment for processor 102. For example, in at least some embodiments, security module 110 is configured to manage the boot process of processor 102, initialize security-related mechanisms of processor 102, monitor processing system 100 for suspicious activity or events, and implement appropriate responses. In some embodiments, security module 110 includes a microcontroller, a cryptographic coprocessor (CCP) for encrypting and decrypting data, local memory and local registers for storing cryptographic keys, and 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 that processor 102 operates in accordance with specified security parameters.

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

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

[0019] In at least some embodiments, the secure computing environment of the processing system 100 provides integrity assurance by implementing a Reverse Map Table (RMP) 120. The RMP 120 is a single data structure shared across the system 100 and contains one entry for each predefined memory page (e.g., 4k pages) of memory that may be used by the VMs 114. The RMP 120 tracks the owner of each page of memory. A page of memory may be owned by the VMM 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 120, 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) 122, which encodes device interface VM bindings and security attributes. The SDT 122, in at least some embodiments, stores security attributes for the I / O devices 106. The IOMMU 112 examines the SDT 1122 when there is traffic from or to the I / O device 106 and makes a security policy decision as to whether access is allowed.

[0020] In at least some embodiments, I / O devices 106 access memory 104 by generating direct memory access (DMA) requests to read data from memory 104 allocated by VM 114, DMA requests to write data to memory 104, or a combination thereof. IOMMU 112 is configured to process DMA requests issued by I / O devices 106. For example, to increase processing efficiency, IOMMU 112 is generally configured to perform specified memory access operations on behalf of processor 102, i.e., using dedicated hardware in IOMMU 112 to perform memory access operations without requiring management of the 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 I / O devices 106 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 targeted by the DMA request. IOMMU 112 is generally configured to translate virtual addresses indicated by DMA requests into physical addresses 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 requests.

[0021] In at least some embodiments, the processor core 108 accesses the I / O device 106 by issuing MMIO requests associated with a particular running 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 can interact with the I / O device 106 using a relatively simple set of access commands and by leveraging at least some of the hardware used to access system memory, thereby improving the overall efficiency of the processor core. To increase processing efficiency, the IOMMU 112 assists in the execution of MMIO requests, such as by performing virtual-to-physical address translation for the MMIO requests.

[0022] The secure computing environment further implements I / O virtualization such that I / O devices 106 are virtualized and shared across multiple VMs 114. One example of I / O virtualization implemented by the secure computing environment is SIOV. In some embodiments, one or more I / O devices 106 are physical I / O virtualization-enabled devices that implement one or more device interfaces 134 (shown as device interface 134-1 and device interface 134-2). Each device interface 134 allows the I / O device 106 to be virtualized as a different virtual I / O device for each VM 114. In at least some embodiments, the device interfaces 134 are allocatable device interfaces (ADIs), forming the unit of allocation and isolation for forming virtual devices.

[0023] After a VM 114 is assigned to a device interface 134 by the VMM 116, a software process / thread of the VM submits a work request to the device interface 134 using one or more techniques. In one example, the process submits the work request through a shared work queue (SWQ) of the device interface 134, which is an interface that allows multiple VMs 114 to submit work requests to the same device interface 134. In at least some embodiments, a process of the VM 114 submits a work request to the device interface 134 by sending an enqueue command 124, such as ENQCMD or ENQCMDS, to the processor core 108. The enqueue command 124, in at least some embodiments, is an instruction that atomically submits a work descriptor to the device interface 134. The enqueue command 124 includes, for example, the virtual addresses of all parameters, the virtual address of the completion record, and the PASID of the VM process that is submitting the work descriptor.

[0024] A PASID is a unique identifier that isolates process address spaces used by VM 114 and links process accesses to the process's view of memory and its access rights to that memory. PASIDs are used to distinguish upstream memory transactions performed on different devices and to convey the address space targeted by the transaction. VM 114 operates using guest PASIDs, while VMM 116 (including the underlying hardware) operates using host PASIDs. In at least some embodiments, VMM 116 assigns PASIDs to VM 114 from a global pool of available PASIDs, and VM 114 assigns multiple PASIDs to its processes. VMM 116 virtualizes PASIDs by maintaining a mapping of guest and host PASIDs in one or more data structures, such as PASID mapping table 126. That is, VMM 116 transparently maps the PASIDs assigned by VM 114 to actual PASIDs, giving VM 114 the view that VM 114 owns the entire PASID space.

[0025] 2 illustrates an example of a PASID mapping table configuration 200 applicable to the techniques described herein. It should be understood that other mapping table configurations are equally applicable. In the mapping table configuration 200, a first portion 204 of a guest PASID 202 includes a PASID directory indicator. The PASID directory indicator identifies a PASID directory pointer 210 (shown as PASID directory pointer 1 210-1 and PASID directory pointer N 210-2) in a memory data structure 212 associated with the corresponding VM 114. The PASID directory pointer 210 points to a PASID directory 214 (shown as PASID directory 1 214-1 and PASID directory N 214-2). A second portion 206 of the guest PASID 202 identifies a designated entry 216 (shown as entry 216-1 and entry 216-2) in the PASID directory 214. The designated entry 216 points to a designated PASID table 218 (shown as PASID table 1 218-1 and PASID table M 218-2). The third portion 208 of the guest PASID 202 identifies a specified entry in the PASID table 218 that contains the guest PASID 202's corresponding host PASID 220 (shown as host PASID 220-1 and host PASID 220-2).

[0026] Referring again to FIG. 1 , each task submitted to device interface 134 by a process within VM 114 is associated with a guest PASID that is translated to a corresponding host PASID. This translation task is performed by CPU core 108 for enqueue command 124. For example, when a VM process invokes enqueue command 124 to submit a work request descriptor to device interface 134 by writing to a register in the SWQ, processor core 108 automatically translates the guest PASID associated with the work request to a host PASID using PASID mapping table 126. Processor core 108 then places the work request in the SWQ of device interface 134 using a type of memory access over PCIe called a deferrable memory write (DMWr) 128. A DMWr 128 is a write that may temporarily fail due to unavailability of underlying resources. DMWr 128 includes information such as the host PASID identified based on the translation process and the work request sent by the VM process. In at least some embodiments, the CPU core 108 sends the DMWr 128 to the device interface 134 via the PCIe controller 130.

[0027] As described above, the VMM 116 is responsible for mapping guest PASIDs to host PASIDs and for mapping host PASIDs to guest contexts within the I / O devices 106. Thus, a malicious or corrupted VMM potentially has the opportunity to maliciously set / change PASIDs and gain access to isolated domains within the virtualized computing environment. Therefore, the processing system 100 implements one or more security mechanisms to allow the VMM 116 to indirectly assign PASIDs to VMs 114 while disallowing the VMM 116 any ability to change the mapping. For example, the processor core 108 maintains and protects one or more data structures, referred to herein as PASID reverse map tables (PMPs) 132, that are global to the system and indexed by host PASIDs. In at least some embodiments, the PMP 132 contains one entry for each guest PASID assigned by the VM 114. PMP 132 contains a per-host PASID security attribute that is checked by processor core 108 when it receives an enqueue command 124 from a VM process to ensure that VMM 116 has not unexpectedly changed the PASID mapping. In at least some embodiments, security module 110 initializes PMP 132.

[0028] 3 illustrates an example of a PMP 132, according to some embodiments. In the illustrated example, the PMP 132 includes multiple entries 301, each assigned to a different host PASID. Each entry in the PMP 132 includes multiple fields, including an assigned field 302, a guest ID field 304, a guest PASID field 306, a locked field 308, a verified field 310, etc. The assigned field 302 stores a bit (or other information) indicating whether the host PASID associated with the PMP entry 301 is assigned or unassigned to the VM 114. For example, if a bit is set in the assigned field 302, this indicates that the host PASID is assigned to the VM 114. The guest ID field 304 stores an identifier, such as an address space identifier (ASID), of the VM 114 assigned to the host PASID associated with the PMP entry 301. The guest PASID field 306 stores the guest PASID, which is translated into the host PASID associated with the PMP entry 301. Lock field 308 stores a bit (or other information) used to coordinate multiple hardware threads of processor core 108 when simultaneously accessing PMP 132. When multiple hardware threads exist and one thread is updating entry 301 in PMP 132 and other threads are attempting to access the same entry 301, lock field 308 indicates the thread that owns entry 301. For example, when a thread writes to entry 301, it attempts to atomically set a bit in lock field 308. If the thread successfully sets the bit, the thread knows it owns the entry and can continue accessing the entry. The thread clears the bit after completing its operation. Verified field 310 stores a bit (or other information) that indicates that VM 114 has previously verified that the host PASID associated with entry 301 is assigned to VM 114, as described in more detail below.

[0029] 4-6 together illustrate an example of a processing system 100 that uses a PMP 132 to implement secure management of PASID mappings to protect a VM 114 from unexpected changes to the PASID mappings, according to some embodiments. In the illustrated example, the VMM 116 initially assigns a host PASID to the VM 114, which in turn assigns a guest PASID to one or more of its processes. The VMM 116 then sets an entry in the PASID mapping table 126 using one or more techniques (e.g., a memory write) to map the guest PASID to the host PASID. As shown in FIG. 4 , the VMM 116 then invokes a PMP update process 401 to update the entry 301 in the PMP 132 for the particular host PASID. In at least some embodiments, the VMM 116 performs the PMP update process 401 by sending an instruction 402, such as a PMPUPDATE instruction, to the processor core 108. The processor core 108 then executes the instruction 402 to update the entry 301 in the PMP 132. Instruction 402 includes information / parameters for updating one or more fields of entry 301. For example, assigned field 302 is updated to indicate that the associated host PASID is assigned to VM 114, guest ID field 304 is updated to contain the guest ID of the VM 114 that owns the associated host PASID, and guest PASID field 306 is updated with the guest PASID that translates to the associated host PASID. The PMP update process also clears / resets the bit stored in verified field 310, which indicates that VMM 114 has modified the information maintained by that entry 301. For example, FIG. 4 shows that verified field 310 of PMP entry 301 has a value of “0,” indicating that the contents of entry 301 have been modified and have not been verified by VM 114.

[0030] In at least some embodiments, when a VM 114 attempts to access a device interface 134 using a specified guest PASID, the VM 114 performs a PMP validation process 501 to validate the mapping of the guest PASID, as shown in FIG. 5 . For example, the VM 114 sends an instruction or request 502, such as a PMPVALIDATE instruction, to the processor core 108. The processor core 108 then executes the instruction 502. The instruction 502 includes one or more parameters, such as a guest PASID. The instruction 502 uses the PASID mapping table 126 to translate the guest PASID to the host PASID of the VM 114. For example, with reference to the mapping table configuration 200 of FIG. 2 , the instruction 502 uses a PASID directory indicator in the first portion 204 of the guest PASID to identify a PASID directory pointer 210 from the memory data structure 212 associated with the VM 114. Next, instructions 502 use the second portion 206 of the guest PASID to identify a particular entry 216 in the associated PASID directory 214 to find the corresponding PASID table 218. Instructions 502 use the third portion 208 of the guest PASID to find the entry in PASID table 218 that contains the guest PASID's corresponding host PASID. The host PASID is used by instructions 502 as an index into PMP 132 to identify an entry 301 associated with the host PASID. After an entry 301 in PMP 132 is identified, instructions 502 check one or more fields of entry 301. For example, instructions 502 check assigned field 302 to determine whether a host PASID has been assigned and guest ID field 304 to determine whether the VM 114 performing the PMP verification process 501 is assigned to the host PASID. If the host PASID is assigned and is assigned to a VM 114 that performs the PMP verification process 501, instruction 502 sets a bit in the verified field 310 of entry 301 to indicate that the contents of entry 301 have been explicitly verified by VM 114.For example, FIG. 5 shows that the verified field 310 of PMP entry 301 has a value of “1,” indicating that the contents of entry 301 have been verified by VM 114 .

[0031] When a process in a VM 114 wants to access a device interface 134 assigned to the VM 114, it issues an enqueue command 124 to the processor core 108, as shown in FIG. 6. The enqueue command is generated by a process that places a work request in the SWQ of the device interface 134, as described above with reference to FIG. 1. The enqueue command 124 includes, for example, the virtual addresses of all parameters, the virtual address of the completion record, and the guest PASID of the VM process that is submitting the work to the device interface 134. In another embodiment, the enqueue command 124 obtains the guest PASID by reading an MSR programmed with the guest PASID. The processor core 108 receives the enqueue command 124 and uses the guest PASID included in the enqueue command 124 to translate the guest PASID to the host PASID of the VM 114 using the PASID mapping table 126, similar to the translation process described above with reference to the PMP verification process 501.

[0032] As part of executing enqueue command 124, processor core 108 performs PMP check 601 on the PASID translation, as shown in FIG. 7. For example, FIG. 7 shows processor core 108 performing translation process 703 to translate guest PASID 702 included in enqueue command 124 to host PASID 720 of VM 114. Processor core 108 uses host PASID 720 as an index into PMP 132 to identify PMP entry 701 corresponding to host PASID 720. Processor core 108 then performs PMP check 601 to determine whether entry 701 meets one or more conditions. For example, processor core 108 determines whether guest PASID field 306 of entry 701 contains a guest PASID that matches the translated guest PASID 702 and whether guest ID field 304 of entry 701 contains an identifier for the accessing VM 114 (i.e., the VM 114 that issued enqueue command 124). This reverse mapping check ensures that the VMM 116 did not modify the PASID mapping table 126. In at least some embodiments, the processor core 108 checks whether the assigned field 302 indicates that the host PASID 720 is assigned to the VM 114, whether the verified field 310 indicates that the current contents of entry 301 have been previously verified by the VM 114 associated with the enqueue command 124, or a combination thereof. If either of these conditions is not true, the PMP check fails, and the processor core 108 determines that the VMM 116 unexpectedly modified the PASID mapping after the VM 114 previously verified the contents of entry 301. The enqueue command 124 then terminates the VM 114, and the VMM 116 is expected to recover by updating the PMP 132 using the PMP update instruction 402 described above.However, if the PMP check condition is true, the enqueue command 124 proceeds and the processor core 108 issues a DMWr 128 to place the work request submitted by the process in the VM 114 into the SWQ of the device interface 134. Thus, the PMP verification 501 and PMP check 601 processes ensure that the process in the VM 114 does not act on unexpected or malicious PASID mappings.

[0033] 8 and 9 together illustrate a flow diagram of a method 800 for securely managing PASID mapping in a secure computing environment that implements input / output virtualization, according to some embodiments. For purposes of explanation, the method 800 is described with reference to an exemplary embodiment in the processing system 100 of FIG. 1 , although it should be understood that in other embodiments, the method 800 is implemented in a processing system having a different configuration. At block 802, the VMM 116 initially assigns a host PASID to the VM 114. For example, the VMM 116 assigns a host PASID to the VM 114 from a global pool of available PASIDs. At block 804, the VM 114 assigns a guest PASID to one or more of its processes. At block 806, the VMM 116 stores guest PASID and host PASID mapping information. For example, the VMM 116 sets up entries in the PASID mapping table 126, as described above with reference to FIG. 1 . By maintaining the PASID mapping, the VMM 116 can virtualize the PASIDs. That is, the VMM 116 transparently maps the PASIDs assigned by the VM 114 to the actual PASIDs, giving the VM 114 the view that it owns the entire PASID space.

[0034] At block 808, the VMM 116 performs the PMP update process 401 described above with respect to FIG. 4 based on the mapping performed at block 506. For example, the VMM 116 executes the PMP update instruction 402, which updates the assigned field 302, the guest ID field 304, and the guest PASID field 306. The PMP verify instruction 402 also clears the verified bit in the verified field 310. At block 810, a process in the VM 114 attempts to access the device interface 134 using the assigned guest PASID and executes the PMP verify instruction (or request) 502. The PMP verify instruction 502 translates the guest PASID to the host PASID of the VM 114 using the PASID mapping table 126, as described above with respect to FIG. 5. The PMP verify instruction 502 uses the host PASID as an index into the PMP 132 to identify an entry 301 associated with the host PASID. After the entry 301 in the PMP 132 is identified, the instruction 502 checks one or more fields of the entry 301. For example, PMP verify instruction 502 verifies that the entry indicates that the host PASID associated with entry 101 is assigned to the guest ID of VM 114 .

[0035] At block 812, the process issues an enqueue command 124 to access the device interface 134. For example, the enqueue command 124 attempts to place a work request in the SWQ of the device interface 134, as described above with reference to FIG. 1. At block 814, the processor core 108 receives the enqueue command 124. At block 816, the processor core 108 translates the guest PASID included in the enqueue command 124 into the host PASID of the VM 114, as described above with reference to FIGS. 6 and 7. The processor core 108 uses the host PASID as an index into the PMP 132 to perform the PMP check 601, at blocks 818-826. For example, at block 818, the processor core 108 uses the host PASID as an index into the PMP 132 to identify the entry 301 corresponding to the host PASID. At block 820, the processor core 108 determines whether the assigned field 302 of the entry 301 indicates that the host PASID is assigned to the VM 114. If a host PASID is not assigned to the VM 114, the process proceeds to block 828, where the processor core 108 sends an error notification to the VMM 116. In other words, the processor core 108 blocks the VM 114 from accessing the device interface 134. The VMM 116 is then expected to perform the PMP update process 401 to correct the error. Otherwise, the process proceeds to block 822, where the processor core 108 determines whether the guest ID of the VM 114 matches the guest ID included in the guest ID field 304 of the entry 301. If the guest ID of the VM 114 does not match the guest ID included in the guest ID field 304, the process proceeds to block 828, where the processor core 108 sends an error notification to the VMM 116. Otherwise, the process proceeds to block 824, where the processor core 108 determines whether the converted guest PASID matches the guest PASID included in the guest PASID field 306 of the entry 301.If the translated guest PASID does not match the guest PASID contained in guest PASID field 306, the process proceeds to block 828, where processor core 108 sends an error notification to VMM 116. Otherwise, the process proceeds to block 826, where processor core 108 determines whether the current contents of entry 301 have been previously verified by VM 114. If the contents of entry 301 have not been previously verified, processor core 108 determines that VMM 116 has changed the contents of entry 301 since VM 114 performed PMP verification process 501 in block 510. The process then flows to block 828, where processor core 108 sends an error notification to VMM 116. However, if the current contents of entry 301 have been previously verified by VM 114, the processor issues DMWr 128 in block 530 to queue the work request submitted by the process of VM 114 to the SWQ of device interface 134. DMWr 128 includes information such as the translated host ID and work requests submitted by the process. It should be understood that in other embodiments, processor core 108 performs PMP check 601 using different configurations of blocks 820-826.

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

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

[0038] 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. a virtual machine manager mapping a guest process address space identifier (PASID) associated with a virtual machine (VM) to a host PASID associated with the VM's host machine; and a security module of the processor, in response to the mapping, maintaining an entry in a PASID reverse mapping table (PMP), the entry including one or more security attributes associated with the host PASID. method.

2. Maintaining the entries in the PMP comprises: storing the guest PASID in a field of the entry as a first security attribute of the one or more security attributes; and storing a guest identifier associated with the VM in a second field of the entry as a second security attribute of the one or more security attributes.

10. The method of claim 1.

3. Maintaining the entries in the PMP comprises: setting a third security attribute of the one or more security attributes in a third field of the entry to an indicator indicating that the VM has not verified the guest PASID and the guest identifier stored in the entry; The method of claim 2.

4. receiving a PMP verification command from the VM including a guest PASID; translating the guest PASID included in the PMP verification command into a host PASID; determining that the entry in the PMP corresponds to the host PASID associated with a translated guest PASID; and in response to the guest PASID stored in the entry matching the translated guest PASID and the one or more security attributes in the entry indicating that the guest identifier stored in the entry corresponds to a guest identifier of the VM, setting an indicator in the entry indicating that the VM has verified the guest PASID and the guest identifier stored in the entry.

10. The method of claim 1.

5. In response to receiving a request from the VM to access a virtual device, translating a guest PASID included in the request to a host PASID; Identifying the entry in the PMP based on the host PASID associated with the translated guest PASID; and permitting the access by the VM to the virtual device in response to the one or more security attributes satisfying at least one particular condition.

10. The method of claim 1.

6. The at least one specific condition includes: a guest PASID stored in an entry matches the converted guest PASID; and a guest identifier stored in the entry matches a guest identifier of the VM. The method of claim 5.

7. the at least one particular condition includes an indication that the VM has previously verified the guest PASID and the guest identifier stored in the entry. The method of claim 6.

8. In response to receiving a request from the VM to access a virtual device, translating a guest PASID included in the request to a host PASID; Identifying an entry in the PMP based on the host PASID associated with the translated guest PASID; and blocking access to the virtual device in response to at least one of the guest PASID stored in an identified entry and the guest identifier stored in the identified entry not matching the translated guest identifier and the guest identifier of the VM, or the identified entry including an indication that a VM has not previously validated the guest PASID and the guest identifier stored in the identified entry.

10. The method of claim 1.

9. In response to receiving a request from a virtual machine (VM) device to access a virtual device, translating a guest process address space identifier (PASID) of the VM to a host PASID associated with a host machine; and blocking access to the virtual device in response to identifying that an entry in a PASID reverse mapping table (PMP) corresponding to the host PASID does not satisfy one or more conditions. method.

10. Blocking said access comprises: determining that the guest PASID stored in the entry does not match the translated guest PASID, or determining that the guest identifier stored in the entry does not match the guest identifier of the VM; 10. The method of claim 9.

11. blocking the access includes determining that the entry includes an indication that the VM has not verified at least one of a guest PASID stored in the entry and a guest identifier stored in the entry.

10. The method of claim 9.

12. determining that the guest PASID stored in the entry matches the translated guest PASID; determining that the guest identifier stored in the entry matches the guest identifier of the VM; and permitting the access of the virtual device in response to the 10. The method of claim 9.

13. permitting the access of the virtual device in response to determining that the entry includes an indication that the VM has verified at least one of a guest PASID stored in the entry and a guest identifier stored in the entry.

10. The method of claim 9.

14. 1. A processor, comprising: an executable Virtual Machine Manager (VMM) configured to map a guest process address space identifier (PASID) associated with a virtual machine (VM) to a host PASID associated with the VM's host machine; a processor core configured to maintain an entry in a PASID reverse mapping table (PMP) in response to the guest PASID being mapped to the host PASID, the entry including one or more security attributes associated with the host PASID. Processor.

15. The processor core storing the guest PASID in a field of the entry as a first security attribute of the one or more security attributes; storing a guest identifier associated with the VM in a second field of the entry as a second security attribute of the one or more security attributes; and maintaining the entry in the PMP by The processor of claim 14.

16. The processor core and maintaining the entry in the PMP by setting a third field of the entry as a third security attribute of the one or more security attributes, an indicator indicating that the VM has not verified the guest PASID and the guest identifier stored in the entry.

16. The processor of claim 15.

17. The processor core receiving a PMP verification command from the VM including a guest PASID; translating the guest PASID included in the PMP verification command into a host PASID; determining that the entry in the PMP corresponds to the host PASID associated with a translated guest PASID; responsive to the guest PASID stored in the entry matching the translated guest PASID and the one or more security attributes in the entry indicating that the guest identifier stored in the entry corresponds to a guest identifier of the VM, setting an indicator in the entry indicating that the VM has verified the guest PASID and the guest identifier stored in the entry; configured to: The processor of claim 14.

18. The processor core In response to receiving a request from the VM to access a virtual device, translating a guest PASID included in the request to a host PASID; Identifying the entry in the PMP based on the host PASID associated with the translated guest PASID; permitting the access by the VM to the virtual device in response to the one or more security attributes satisfying at least one particular condition; configured to: The processor of claim 14.

19. The at least one specific condition is: The guest PASID stored in the entry matches the converted guest PASID, and the guest identifier stored in the entry matches the guest identifier of the VM, or An indication that the VM has previously verified the guest PASID and the guest identifier stored in the entry. including at least one of 20. The processor of claim 18.

20. The processor: In response to receiving a request from the VM to access a virtual device, translating a guest PASID included in the request to a host PASID; Identifying an entry in the PMP based on the host PASID associated with the translated guest PASID; blocking the access to the virtual device in response to at least one of the guest PASID stored in an identified entry and the guest identifier stored in the identified entry not matching the translated guest identifier and the guest identifier of the VM, or the identified entry including an indication that a VM has not previously validated the guest PASID and the guest identifier stored in the identified entry; configured to: The processor of claim 14.

Images