Direct allocation of physical devices to confidential virtual machines

Abstract

Methods, systems, and computer program products for directly assigning physical devices to confidential virtual machines (VMs). A direct allocation of a physical device associated with the host computer system to the guest partition is identified at a first guest privilege context of the guest partition. The guest partition includes a first guest privileged context and a second guest privileged context, the second guest privileged context being restricted from accessing a memory associated with the first guest privileged context. The guest partition corresponds to the confidential VM such that the host operating system cannot access a memory region associated with the guest partition. The physical device is allowed to be allocated directly to the guest partition based on the policy determination. Communication between the physical device and the second guest privileged context is allowed, such as by exposing the physical device and / or forwarding an interrupt on the virtual bus.

Description

Background Art

[0001] Hypervisor-based virtualization technology allocates parts of the physical resources of a computer system (e.g., processor cores and / or time, physical memory areas, storage resources, etc.) into separate partitions, and executes software within each of these partitions. Therefore, hypervisor-based virtualization technology facilitates the creation of virtual machine (VM) guests, each of which executes guest software, such as an operating system (OS) and other software executed therein. Although hypervisor-based virtualization technology can take various forms, the architecture used by many virtualization technologies includes a hypervisor that directly accesses hardware and operates in an execution environment separate from all other software in the system, a host partition that executes a host OS and a host virtualization stack, and one or more guest partitions corresponding to the VM guest. The host virtualization stack within the host partition manages the guest partitions, and therefore the hypervisor grants the host partition a higher level of access to the hypervisor and hardware resources than the guest partition.

[0002] Taking Hyper-V from MICROSOFT CORPORATION as an example, the Hyper-V hypervisor is the lowest layer of the Hyper-V stack. The Hyper-V hypervisor provides basic functions for scheduling and executing virtual processors for VM guests. The Hyper-V hypervisor has ownership of hardware virtualization capabilities (e.g., Second Level Address Translation (SLAT) processor extensions such as Rapid Virtualization Indexing (RVI) from Advanced Micro Devices (AMD), or Extended Page Tables (EPT) from INTEL; Input / Output (I / O) Memory Management Unit (IOMMU) that connects an I / O bus supporting direct memory access to main memory; Processor virtualization control). The Hyper-V hypervisor also provides a set of interfaces to allow the Hyper-V host stack within the host partition to utilize these virtualization capabilities to manage VM guests. The Hyper-V host stack provides common functions for VM guest virtualization (e.g., memory management, VM guest lifecycle management, device virtualization).

[0003] Many hypervisor-based virtualization technologies support direct assignment of physical devices to VM guests. For example, using Discrete Device Assignment (DDA) technology, the Hyper-V hypervisor can pass entire Peripheral Component Interconnect Express (PCIe) devices to VM guests. Direct assignment of physical devices allows high-performance access to devices like Non-Volatile Memory Express (NVMe) storage or graphics cards from within a VM guest while enabling the VM guest to take advantage of the device's native drivers.

[0004] In addition to isolating guest partitions from each other, some hypervisor-based virtualization technologies also operate to isolate VM guest states (e.g., registers, memory) from host partitions (and the host OS executed therein), and in some cases also from the hypervisor itself. Many of these technologies can also isolate VM guest states from entities that manage the computing system on which VM guests are hosted. To achieve the above, these virtualization technologies introduce a security boundary at least between the hypervisor and the host virtualization stack. The security boundary limits which VM guest resources the host OS (and accordingly, the host virtualization stack) can access to ensure the integrity and confidentiality of the VM guest. Such VM guests are referred to herein as confidential VMs (CVMs). Examples of hardware-based technologies that enable CVM guests include hardware-based technologies such as software protection extensions (SGX) from INTEL or secure encrypted virtualization secure nested paging (SEV-SNP) from AMD. Software-based CVM guests are also possible.

[0005] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as described above.Rather, this background is provided merely to illustrate one example technology area where some embodiments described herein may be practiced. Summary of the invention

[0006] In some aspects, the technology described herein relates to a method, comprising, at a first guest privileged context of a guest partition: identifying a direct assignment of a physical device associated with a host computer system to the guest partition, the guest partition comprising the first guest privileged context and a second guest privileged context restricted from accessing a memory associated with the first guest privileged context, wherein a memory region associated with the guest partition is inaccessible to a host OS; determining based on a policy that direct assignment of the physical device to the guest partition is permitted; and allowing communication between the physical device and the second guest privileged context.

[0007] In some aspects, the technology described herein relates to a computer system comprising: a processing system; and a computer storage medium storing computer executable instructions that can be executed by the processing system to cause the computer system, at least at a first guest privileged context of the guest partition, to: identify a direct assignment of a physical device associated with a host computer system to a guest partition, the guest partition comprising the first guest privileged context and a second guest privileged context that is restricted from accessing a memory associated with the first guest privileged context, wherein a memory region associated with the guest partition is inaccessible to the host OS; determine based on a policy that direct assignment of the physical device to the guest partition is allowed; and allow communication between the physical device and the second guest privileged context.

[0008] In some aspects, the technology described herein relates to a computer program product that includes a computer storage medium storing computer executable instructions that can be executed by a processing system to cause the computer system, at least at a first guest privileged context of a guest partition, to: identify a direct assignment of a physical device associated with a host computer system to a guest partition, the guest partition including the first guest privileged context and a second guest privileged context that is restricted from accessing a memory associated with the first guest privileged context, wherein a memory region associated with the guest partition is not accessible to a host OS; determine based on a policy that direct assignment of the physical device to the guest partition is allowed; and allow communication between the physical device and the second guest privileged context.

[0009] This summary is provided to introduce a series of concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be provided with reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein and are, therefore, not to be considered limiting of their scope, certain systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0011] Figure 1 An example computer architecture that facilitates secure direct assignment of physical devices to CVMs is shown;

[0012] Figure 2 An example of internal elements of a security component that facilitates direct assignment of a physical device to a CVM is shown;

[0013] Figure 3 An example of partitioning a CVM guest's memory into shared and private regions is shown; and

[0014] Figure 4 A flow chart of an example method for securely managing direct assignment of physical devices to CVMs is shown. DETAILED DESCRIPTION

[0015] Direct assignment of physical devices to virtual machine (VM) guests (such as using discrete device assignment (DDA) techniques) was previously incompatible with confidential VM (CVM) guests. This is because direct assignment of a physical device enables the device to access the memory space of the VM guest (e.g., via direct memory access (DMA) techniques). Because the physical device exists outside the trusted computing base (TCB) of the CVM guest (e.g., outside the security boundary that isolates the CVM from the host OS), and the CVM guest has no existing ability to verify the security and authenticity of the physical device, the CVM guest currently has no mechanism to ensure that the directly assigned physical device can be trusted to access the memory space of the CVM. Although technologies for verifying the security and authenticity of physical devices are being developed (e.g., the Trusted Device Interface Security Protocol (TDISP)), these technologies and devices that support them are not yet available.

[0016] The embodiments described herein enable untrusted physical devices to be directly assigned to CVM guests in a secure manner. These embodiments create isolated memory contexts within a guest partition corresponding to a CVM guest, including a lower privilege context and a higher privilege context. These embodiments then execute the guest OS within the lower privilege context and execute the security component within the higher privilege context. In an embodiment, based on a security component that identifies the direct assignment of a physical device to a guest partition, the security component determines whether a policy allows the physical device to be directly assigned to a guest partition, or whether a policy does not allow the physical device to be directly assigned to a guest partition. If allowed, the security component allows communication between the physical device and the lower privilege context (and the guest OS executed therein); if not allowed, the security component denies such communication. In an embodiment, communication between a physical device and a lower privilege context is allowed / disallowed based on controlling the exposure of the physical device to the virtual bus used by the lower privilege context and / or by filtering interrupts associated with the physical device.

[0017] In an embodiment, a security component divides a guest physical address (GPA) space of a guest partition into at least a private GPA area and a shared GPA area. Data stored in the private GPA area is encrypted (e.g., by hardware, a security component) to prevent the host OS from accessing the data, while the host OS can access data stored in the shared GPA area. The guest OS sends data to an allowed physical device by writing data to the shared GPA area, and receives data from an allowed physical device by reading from the shared GPA area. In some embodiments, the guest OS encrypts data to be sent to an allowed physical device, and writes the encrypted data to the shared GPA area; the guest OS decrypts data read from the shared GPA area. In this way, communication between the guest OS and the physical device is isolated from the host OS.

[0018] Figure 1 An example computer architecture 100 is shown that facilitates secure direct assignment of physical devices to CVMs (e.g., using DDA or similar techniques). As shown, computer architecture 100 includes a computer system 101 that includes hardware 102. Examples of hardware 102 include a processing system that includes processor(s) 103 (e.g., a single processor or multiple processors), a memory 104 (e.g., a system or main memory), a storage medium 105 (e.g., a single computer-readable storage medium, or multiple computer-readable storage media), and a physical device 106 (or multiple physical devices) for assignment to a VM guest. As an example, physical device 106 may include a PCIe input / output device such as a network interface, a graphics card, etc. Although not shown, physical device 106 may also include other hardware devices such as a network interface (e.g., one or more network interface cards) for interconnecting (via network 107) to one or more other computer systems (e.g., attestation system 120), a trusted platform module (TPM) for facilitating measured boot features, an IOMMU, a video display interface, a user input interface, an external bus, etc.

[0019] As shown, in the computer architecture 100, the hypervisor 108 executes directly on the hardware 102. Typically, the hypervisor 108 divides hardware resources (e.g., (multiple) processors 103, memory 104, I / O resources) between the host partition 110 and the guest partition 111a, wherein the host OS 114 executes within the host partition 110 and the guest OS 115 executes within the guest partition 111a. As indicated by the ellipsis, the hypervisor 108 can divide the hardware resources into multiple guest partitions 111 (e.g., guest partition 111a to guest partition 111n), each guest partition 111 executing a corresponding guest OS. In the description herein, the term "VM guest" is used to refer to a "guest partition", and the term "CVM guest" is used to indicate when a VM guest is a confidential VM guest operating in an isolated guest partition under a CVM architecture. The hypervisor 108 also implements controlled communication between partitions via a bus (e.g., a VM bus, not shown). As shown, host OS 114 includes a virtualization stack 117 that manages VM guest virtualization (eg, memory management, VM guest lifecycle management, device virtualization) via one or more application program interface (API) calls to hypervisor 108 .

[0020] In computer architecture 100, virtualization stack 117 is shown to include context manager 118, which divides guest partitions into different privileged areas (referred to herein as guest privileged contexts). Thus, for example, guest partition 111a is shown to include guest privileged context 112 (hereinafter referred to as context 112) and guest privileged context 113 (hereinafter referred to as context 113). In an embodiment, context manager 118 can divide any guest partition 111 into different guest privileged contexts. Figure 1 As indicated, in some embodiments, context 112 is a lower privileged context (e.g., when compared to context 113), and context 113 is a higher privileged context (e.g., when compared to context 112). In these embodiments, context 112 being less privileged than context 113 means that context 112 cannot access guest partition memory assigned to context 113. In some embodiments, context 113 can access guest partition memory assigned to context 112. In other embodiments, context 113 lacks access to guest partition memory assigned to context 112.

[0021] In some embodiments, context 112 and context 113 are created based on SLAT 109, which includes one or more tables that map system physical addresses (SPAs) in memory 104 to GPAs seen by guest partition 111a. In these embodiments, these mappings prevent context 112 from accessing memory assigned to context 113. In one example, hypervisor 108 is a HYPER-V hypervisor and uses virtualization-based security (VBS), which uses hardware virtualization features to create secure areas of memory and isolate secure areas of memory from the OS to sub-partition guest partition 111a into virtual trust levels (VTLs). In this example, context 113 operates under the VBS in a higher privileged VTL, and context 112 operates under the VBS in a lower privileged VTL. In other embodiments, context 112 and context 113 are created based on nested virtualization, where guest partition 111a operates similar to a hypervisor of hypervisor 108, dividing the resources of guest partition 111a into sub-partitions. In these embodiments, the hypervisor operating within guest partition 111a prevents context 112 from accessing memory allocated to context 113 .

[0022] exist Figure 1, context 113 is shown to include a security component 116. In an embodiment, security component 116 runs within each CVM that is configured to use the direct device allocation techniques described herein. Because security component 116 operates within guest partition 111a, in an embodiment, security component 116 is part of the TCB of the CVM guest and is measured as part of the initial image of the CVM guest.

[0023] In some embodiments, context 113 operates as a host compatibility layer (HCL) firmware environment that provides a set of facilities, such as virtualized TPM support, to the guest OS running within context 112. In these embodiments, security component 116 is part of the HCL firmware environment and provides direct device allocation facilities. In some embodiments, the operation of security component 116 within context 113 is transparent to guest OS 115, while in other embodiments, guest OS 115 is enlightened to understand security component 116 and the facilities it provides.

[0024] Figure 2 Shows Figure 1 An example 200 of internal elements of the security component 116 . Figure 2 Each internal element of the security component 116 depicted in represents various functions that the security component 116 can implement according to various embodiments described herein. However, it should be understood that the depicted elements, including their identities and arrangements, are presented only as an aid in describing example embodiments of the security component 116.

[0025] In an embodiment, the security component 116 operates within the context of a guest partition (e.g., guest partition 111a) configured as a CVM guest. The CVM guest may be created using hardware-based technologies (such as SGX from INTEL or SEV-SNP from AMD), and / or software-based technologies. Additionally, as described, in an embodiment, the security component 116 operates within a higher privileged context (e.g., context 113) of the CVM guest, such as a context created based on a mapping within a SLAT table or using nested virtualization.

[0026] In some embodiments, the security component 116 includes a memory manager 201 that operates to divide the GPA space of the CVM guest into at least a private GPA area and a shared GPA area. The guest OS 115 sends data to the physical device 106 by writing data to the shared GPA area, and receives data from the physical device 106 by reading from the shared GPA area.

[0027] In some embodiments, the guest OS 115 encrypts data to be sent to the physical device 106 and writes the encrypted data to the shared GPA area. Additionally, the guest OS 115 decrypts data read from the shared GPA area. In these embodiments, the physical device 106 includes functionality for encrypting and decrypting the data. In this way, the communication between the guest OS 115 and the physical device 106 is isolated from the host OS 114.

[0028] Figure 3 An example 300 of partitioning a CVM guest's memory into shared and private regions is shown. Initially, the example 300 shows an example of a VM GPA space 301. As will be appreciated, conventional 32-bit memory addresses can address 2^32 bytes (or 4GB) of memory, while modern 64-bit memory addresses can address 2^64 bytes of memory. Thus, the VM GPA space 301 shows a 4GB memory boundary that defines a lower memory region 303 that can be accessed using 32-bit addressing (as well as 64-bit addressing), and an upper memory region 302 that can be accessed using 64-bit addressing. It will also be appreciated that defined regions of memory space are typically used to communicate with physical devices via DMA, or to provide CPU access to device control registers. Thus, the VM GPA space 301 shows a guest device low range 305 within the lower memory region 303 (e.g., for communicating with physical devices using 32-bit memory addressing), and a guest device high range 304 within the upper memory region 302 (e.g., for communicating with physical devices using 64-bit memory addressing).

[0029] Example 300 also shows an example of a partitioned memory space 306, where the upper area of ​​the partitioned memory space 306 is a shared area 307 (indicated by a right slash), and the lower area of ​​the partitioned memory space 306 is a private area 308 (indicated by a left slash). In an embodiment, the memory manager 201 creates the partitioned memory space 306 based on the use of hardware-based technology. For example, some embodiments use the virtual machine privilege level (VMPL) from AMD to define the virtual top of memory (vTOM) to logically divide the memory into a private area (and therefore, only accessible by the CVM) and a shared area (and therefore, also accessible by the host partition). Other embodiments use memory page flags to indicate which memory pages are private (and therefore, only accessible by the CVM) or shared (and therefore, also accessible by the host partition).

[0030] According to an embodiment of the present invention, in conjunction with the VM GPA space 301 and the divided memory space 306, the example 300 also includes a CVM GPA space 309. In the CVM GPA space 309, the right and left slashes indicate that the CVM GPA area 309 includes a shared area 307 and a private area 308. Additionally, as indicated by the horizontal solid lines, the CVM GPA space 309 also includes an upper memory area 302 and a lower memory area 303 defined by 32-bit and 64-bit addressing. Because in the example 300, the guest device low range 305 resides in the private area 308, in an embodiment, the memory manager 201 maps the guest device low range 305 into the shared area 307 as the guest device low range 305'. This enables the guest OS to communicate with a directly allocated physical device that expects to use the guest device low range 305 via a shared memory instead of a private memory. In an alternative example, the guest device high range 304 also resides within the private region 308 , and the memory manager 201 maps the guest device high region 304 into the shared region 307 as well.

[0031] Example 300 also shows a partial mapping between CVM GPA space 309 and SPA space 310. As shown, the GPA in guest device high range 304 is mapped to the SPA in host device high range 311 of SPA space 310. Additionally, the GPAs in guest device low range 305 and guest device low range 305′ are dual mapped to the SPA in host device low range 312 of SPA space 310. With this dual mapping configuration, the driver 119 within the guest OS 115 can use the GPA in guest device low range 305′ to communicate with the physical device mapped to the host device low range 312.

[0032] The security component 116 also includes a direct device allocation manager 202 that identifies a direct allocation of a physical device 106 to a guest partition 111a (e.g., via a virtualization stack 117). Based on the identification, the direct device allocation manager 202 determines whether a policy 204 allows the physical device 106 to be directly allocated to the guest partition 111a, or whether such an allocation is not allowed. In some embodiments, the policy 204 includes an allow list of one or more physical devices that are allowed to be directly allocated to the guest partition 111a. Additionally, or alternatively, in some embodiments, the policy 204 includes a deny list of one or more physical devices that are not allowed to be directly allocated to the guest partition 111a. In some embodiments, the policy 204 resides at the context 113. In other embodiments, the policy 204 resides at the attestation system 120, and the direct device allocation manager 202 communicates with the attestation system 120 to determine whether a particular physical device is allowed to be directly allocated to the guest partition 111a. In an embodiment, policy 204 identifies devices that are allowed or not allowed based on device type (e.g., graphics card, network interface card), model identifier, vendor identifier (e.g., PCIe vendor identifier), device identifier (e.g., PCIe device identifier), etc.

[0033] In an embodiment, if the direct device allocation manager 202 determines that the policy 204 allows the physical device 106 to be directly assigned to the guest partition 111a, the direct device allocation manager 202 allows communication between the physical device 106 and the context 112 (and the guest OS 115 executed therein). Conversely, in an embodiment, if the direct device allocation manager 202 determines that the policy 204 does not allow the physical device 106 to be directly assigned to the guest partition 111a, the direct device allocation manager 202 denies such communication.

[0034] In some embodiments, direct device allocation manager 202 allows communication between physical device 106 and context 112 based on exposing physical device 106 on a virtual bus utilized by context 112, and denies such communication by blocking physical device 106 from the virtual bus (e.g., by omitting physical device 106 from the virtual bus).

[0035] Additionally or alternatively, in some embodiments, the direct device assignment manager 202 filters interrupts based on use of the interrupt manager 203 to allow or deny communication between the physical device 106 and the context 112. For example, when the interrupt manager 203 intercepts an interrupt associated with the physical device 106 (e.g., an interrupt originating from the physical device 106, or an interrupt directed to the physical device 106), the interrupt manager 203 forwards the interrupt to its destination if the physical device 106 is allowed to be directly assigned to the guest partition 111a, or blocks the interrupt if the physical device 106 is not allowed to be directly assigned to the guest partition 111a.

[0036] Now combine Figure 4 Components of the security component 116 are described, which shows a flowchart of an example method 400 for securely managing direct allocation of physical devices to CVMs. In an embodiment, instructions for implementing the method 400 are encoded as computer executable instructions (e.g., context manager 118, security component 116) stored on a computer storage medium (e.g., storage medium 105), which can be executed by a processor (e.g., processor (s) 103) to cause a computer system (e.g., computer system 101) to perform the method 400.

[0037] The following discussion now involves a number of methods and method actions. Although method actions may be discussed in a certain order or may be shown in a flowchart as occurring in a particular order, no particular order is required unless otherwise specified or because an action depends on another action being completed before performing the action.

[0038] Initially, it should be noted that, in an embodiment, method 400 is performed within the context of a guest partition configured as a CVM guest. This means that the host OS does not have access to memory regions associated with the guest partition. For example, the host OS 114 does not have access to memory regions associated with guest partition 111a. In an embodiment, the host OS does not have access to the memory regions associated with the guest partition based on at least one of a mapping within a SLAT table or encryption of the contents of the memory region.

[0039] refer to Figure 4In an embodiment, method 400 includes an act 401 of creating privileged and non-privileged memory contexts for a guest partition. In some embodiments, act 401 includes creating a first guest privileged context and a second guest privileged context for the guest partition, wherein the second guest privileged context is restricted from accessing memory associated with the first guest privileged context. In an example, context manager 118 creates context 112 and context 113 for guest partition 111a using SLAT mapping or by configuring guest partition 111a to use nested virtualization. By creating these different guest privileged contexts, act 401 configures the CVM to be able to run security component 116 in a manner that is isolated from guest OS 115 and potentially even transparent to guest OS 115.

[0040] In an embodiment, method 400 also includes an action 402 of creating private and shared guest memory regions. In some embodiments, action 402 includes partitioning the guest physical address space of the guest partition into a private physical address space region and a shared physical address space region at the first guest privileged context. In an example, memory manager 201 partitions the GPA space associated with guest partition 111a to include a shared region 307 and a private region 308, such as in the manner shown in CVM GPA space 309. This provides the guest OS 115 with a memory region (i.e., shared region 307) that can be used to communicate with the host OS 114 and the physical device 106, and a memory region (i.e., private region 308) that is isolated from the host OS 114 and the physical device 106.

[0041] In an embodiment, memory manager 201 isolates the contents of memory within private region 308 from host OS 114 based on encrypting and decrypting the contents on behalf of guest OS 115. Thus, in some embodiments, method 400 includes, at a first guest privileged context, encrypting writes to a private physical address space region by a second guest privileged context; and decrypting reads to a private physical address space region by the second guest privileged context.

[0042] like Figure 3 As shown, in some embodiments, the memory manager 201 maps the device memory region (guest device low range 305) into the shared region 307 (guest device low range 305') of the CVM GPA space 309. Figure 3Thus, in some embodiments, method 400 includes mapping, at a first guest privileged context, a device memory region (e.g., host device low range 312) within a host physical address space (e.g., SPA space 310) of a host computer system to each of a private physical address space region (e.g., guest device low range 305 within private region 308) and a shared physical address space region (e.g., guest device low range 305' within shared region 307).

[0043] In an embodiment, method 400 also includes an act 403 of identifying a direct device allocation within a privileged memory context. In some embodiments, act 403 includes identifying, at the first guest privileged context, a direct allocation of a physical device associated with the host computer system to a guest partition. In an example, direct device allocation manager 202 identifies an allocation of physical device 106 to guest partition 111a (e.g., by virtualization stack 117, using DDA techniques, or similar techniques).

[0044] In an embodiment, method 400 also includes an action 404 of determining whether the allocated physical device is allowed for the guest partition. In some embodiments, action 404 includes determining, at the first guest privileged context, based on a policy, that direct allocation of the physical device to the guest partition is allowed. In an example, based on direct device allocation manager 202 consulting policy 204 (and / or consulting attestation system 120), direct device allocation manager 202 determines that policy 204 allows direct allocation of physical device 106 to guest partition 111a.

[0045] In other embodiments, action 404 includes determining, at the first guest privileged context, based on policy, that direct assignment of the physical device to the guest partition is not permitted. In an example, based on direct device assignment manager 202 consulting policy 204 (and / or consulting attestation system 120), direct device assignment manager 202 determines that policy 204 does not permit direct assignment of physical device 106 to guest partition 111a.

[0046] In an embodiment, the policy 204 identifies the physical device 106 as allowed (or denied) based on one or more of: device type, model identifier, vendor identifier, or device identifier.

[0047] Depending on the result of action 404, method 400 also includes action 405 of allowing the physical device (for example, when the direct device allocation manager 202 determines that the physical device 106 is allowed to be directly assigned to the guest partition 111a), or action 408 of denying the physical device (for example, when the direct device allocation manager 202 determines that the physical device 106 is not allowed to be directly assigned to the guest partition 111a).

[0048] When method 400 includes action 405, in some embodiments, action 405 includes allowing communication between the physical device and the second guest privileged context at the first guest privileged context. In the example, based on determining in action 404 that physical device 106 is allowed to be directly assigned to guest partition 111a, direct device assignment manager 202 allows communication between physical device 106 and context 112. As shown, action 405 can include one or more of action 406 of exposing the physical device on the virtual bus, or action 407 of forwarding physical device interrupts.

[0049] When method 400 includes action 406, in some embodiments, action 406 includes exposing the physical device on the virtual bus used by the second guest privileged context. In an example, direct device allocation manager 202 exposes physical device 106 on the virtual bus used by context 112. This enables guest OS 115 to discover and utilize the device (e.g., using driver 119). In an embodiment, exposing the physical device on the virtual bus includes exposing an identifier (e.g., a PCI ID) of physical device 106 on the virtual bus, mapping the physical device to a portion of a memory space of a guest partition, etc.

[0050] Additionally or alternatively, in some embodiments, action 407 includes intercepting an interrupt associated with a physical device and forwarding the interrupt to an interrupt destination. In an example, the interrupt manager 203 intercepts an interrupt associated with a physical device 106 (e.g., originating from a physical device 106 or directed to a physical device 106) and forwards the interrupt to its destination (e.g., by triggering an interrupt at the destination). In some embodiments, the interrupt is initiated by a guest OS 115 operating at a second guest privileged context (context 112), and forwarding the interrupt to the interrupt destination includes forwarding the interrupt to the physical device 106. This enables the physical device 106 to receive the interrupt initiated by the guest OS 115. In other embodiments, the interrupt is initiated by the physical device 106, and forwarding the interrupt to the interrupt destination includes forwarding the interrupt to the second guest privileged context (context 112). This enables the guest OS 115 to receive the interrupt initiated by the physical device 106.

[0051] In some embodiments, when communication between the physical device and the second guest privileged context is allowed, the guest OS and the physical device rely on encrypted communication via the shared area 307 to isolate their communication from the host OS 114. Therefore, in an embodiment, the method 400 includes, at the second guest privileged context, sending data to the physical device based on encrypting the data to generate encrypted data, and writing the encrypted data to the shared physical address space area. Additionally, in an embodiment, the method 400 includes, at the second guest privileged context, receiving data from the physical device based on reading the encrypted data from the shared physical address space area to generate unencrypted data.

[0052] In some embodiments, action 408 includes denying communication between the physical device and the second guest privileged context at the first guest privileged context. In the example, based on determining in action 404 that direct assignment of physical device 106 to guest partition 111a is not allowed, direct device assignment manager 202 denies communication between physical device 106 and context 112. As shown, action 408 may include one or more of action 409 of blocking the physical device on the virtual bus, or action 410 of blocking physical device interrupts.

[0053] In some embodiments, action 409 includes blocking the physical device on the virtual bus used by the second guest privileged context. In an example, direct device allocation manager 202 blocks physical device 106 from accessing the virtual bus used by context 112. This prevents guest OS 115 from discovering and utilizing the device.

[0054] Additionally or alternatively, in some embodiments, action 410 includes intercepting an interrupt associated with a physical device and blocking the interrupt. In the example, interrupt manager 203 intercepts an interrupt associated with physical device 106 (e.g., originating from physical device 106, or directed to physical device 106), and blocks the interrupt. This ensures that there is no communication between physical device 106 and guest OS 115.

[0055] Based on the method 400, the security component 116 can securely assign physical devices to the CVM based on the use of policies, and the CVM itself determines whether direct device assignment is allowed. Additionally, by utilizing encrypted communications, the CVM and physical devices can communicate in isolation from the host OS.

[0056] Embodiments of the present disclosure may include or utilize a special or general-purpose computer system (e.g., computer system 101), as discussed in more detail below, which includes computer hardware, such as a processor system (e.g., (multiple) processors 103) and system memory (e.g., memory 104). Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general or special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 105). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Therefore, as an example, embodiments of the present disclosure may include at least two distinct computer-readable media: computer storage media and transmission media.

[0057] Computer storage media are physical storage media that store computer executable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other (multiple) hardware storage devices that can be used to store program code in the form of computer executable instructions or data structures that can be accessed and executed by a general or special purpose computer system to implement the disclosed functions.

[0058] Transmission medium can include network and / or data link, it can be used for carrying computer executable instruction or data structure form program code, and can be accessed by general or special computer system." network " is defined as one or more data links that can transmit electronic data between computer system and / or module and / or other electronic equipment.When transmitting or providing information to computer system by network or another kind of communication connection (hard wiring, wireless or hard wiring or wireless combination), computer system can regard this connection as transmission medium.Above-mentioned combination should also be included in the scope of computer readable medium.

[0059] In addition, upon reaching various computer system components, program code in the form of computer executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module and then ultimately transferred to computer system RAM and / or less volatile computer storage media at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0060] Computer executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general purpose computer system, a special purpose computer system, or a special purpose processing device to perform a certain function or group of functions. Computer executable instructions may be, for example, binary code, intermediate format instructions such as assembly language, or even source code.

[0061] It should be understood that the disclosed system and method can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, notebook computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The embodiments of the present disclosure can also be practiced in a distributed system environment, where local and remote computer systems linked through a network perform tasks separately. Thus, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0062] It should also be understood that embodiments of the present disclosure may be practiced in a cloud computing environment. A cloud computing environment may be distributed, although this is not required. When distributed, a cloud computing environment may be distributed internationally within an organization and / or have components across multiple organizations. In this specification and the following claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). A cloud computing model may consist of various features, such as on-demand self-service, extensive network access, resource pools, rapid elasticity, measured services, and the like. Cloud computing models may also appear in the form of various service models, such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). Cloud computing models may also be deployed using different deployment models, such as private clouds, community clouds, public clouds, hybrid clouds, and the like.

[0063] Some embodiments such as cloud computing environments may include a system that includes one or more hosts, each of which is capable of running one or more virtual machines. During operation, the virtual machine emulates an operating computing system that supports an OS and may also support one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machine using physical resources extracted from the virtual machine's view. The hypervisor also provides appropriate isolation between virtual machines. Therefore, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfaced with a physical resource, even if the virtual machine is only interfaced with the appearance of a physical resource (e.g., a virtual resource). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0064] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above, or to the order of acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0065] The present disclosure may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects as illustrative rather than restrictive. All changes within the meaning and range of equivalents of the claims should be included within their scope.

[0066] When introducing elements in the appended claims, the articles "a", "an", "the", and "said" are intended to mean that there are one or more of these elements. The terms "comprises", "comprising", and "having" are intended to be inclusive and mean that in addition to the listed elements, there may be additional elements. Unless otherwise stated, the terms "set", "superset", and "subset" are intended to exclude empty sets, and thus "set" is defined as a non-empty set, "superset" is defined as a non-empty superset, and "subset" is defined as a non-empty subset. Unless otherwise stated, the term "subset" excludes all of its supersets (i.e., the superset contains at least one item that is not included in the subset). Unless otherwise stated, a "superset" may include at least one additional element, and a "subset" may exclude at least one element.

Claims

1. A method, comprising, at a first guest privilege context in a guest partition: identifying a direct assignment of a physical device associated with a host computer system to the guest partition, the guest partition comprising the first guest privileged context and a second guest privileged context restricted from accessing a memory associated with the first guest privileged context, wherein a host operating system is unable to access a memory region associated with the guest partition; Based on the policy, determining that the physical device is allowed to be directly assigned to the guest partition; and Communication between the physical device and the second guest privileged context is permitted.

2. The method of claim 1 , wherein allowing communication between the physical device and the second guest privileged context comprises: The physical device is exposed on a virtual bus used by the second guest privileged context.

3. The method of claim 1 , wherein allowing communication between the physical device and the second guest privileged context comprises: intercepting an interrupt associated with the physical device; as well as The interrupt is forwarded to an interrupt destination.

4. The method according to claim 3, wherein: The interrupt is initiated by a guest operating system operating at the second guest privileged context; as well as Forwarding the interrupt to the interrupt destination includes: forwarding the interrupt to the physical device.

5. The method according to claim 3, wherein: The interruption is initiated by the physical device; as well as Forwarding the interrupt to the interrupt destination includes forwarding the interrupt to the second guest privileged context.

6. The method of claim 1 , wherein the host operating system is unable to access the memory region associated with the guest partition based on at least one of: A mapping within a secondary address translation table; or Encryption of the contents of the memory area.

7. The method according to claim 1, further comprising: At the first guest privileged context, a guest physical address space of the guest partition is divided into a private physical address space region and a shared physical address space region.

8. The method according to claim 7, further comprising: In the first guest privilege context: encrypting writes of the second guest privileged context to the private physical address space region; as well as Decrypting the second guest privileged context's reads of the private physical address space region.

9. The method according to claim 7, further comprising: At the second guest privileged context, data is sent to the physical device based on: encrypting the data to generate encrypted data; as well as The encrypted data is written to the shared physical address space area.

10. The method according to claim 7, further comprising: At the first guest privileged context, a device memory region within a host physical address space of the host computer system is mapped to each of the private physical address space region and the shared physical address space region.

11. The method of claim 1, wherein the policy identifies the physical device as allowed based on one or more of: a device type, a model identifier, a vendor identifier, or a device identifier.

12. The method of claim 1, wherein the physical device is a first physical device, the method further comprising, at the first guest privileged context: identifying a direct assignment of a second physical device associated with the host computer system to the guest partition; Based on the policy, determining that the second physical device is not allowed to be directly assigned to the guest partition; and Communications between the second physical device and the second guest privileged context are denied.

13. The method of claim 12, wherein denying communication between the second physical device and the second guest privileged context comprises: The second physical device on the virtual bus used by the second guest privileged context is blocked.

14. The method of claim 12, wherein denying communication between the second physical device and the second guest privileged context comprises: intercepting an interrupt associated with the second physical device; as well as Block the interrupt.

15. A computer system comprising: Processing systems; as well as A computer storage medium storing computer executable instructions executable by the processing system to cause the computer system, at least at a first guest privilege context of a guest partition: identifying a direct assignment of a physical device associated with a host computer system to the guest partition, the guest partition comprising the first guest privileged context and a second guest privileged context restricted from accessing a memory associated with the first guest privileged context, wherein a host operating system is unable to access a memory region associated with the guest partition; Based on the policy, determining that the physical device is allowed to be directly assigned to the guest partition; as well as Communication between the physical device and the second guest privileged context is enabled, wherein enabling communication between the physical device and the second guest privileged context includes exposing the physical device on a virtual bus used by the second guest privileged context.

Images