Software Separation of Virtual Machine Resources

Abstract

Separating the resources of a virtual machine (VM) guest from the host operating system. The computer system receives a reception request from a guest partition corresponding to the separated VM. The reception request identifies a guest memory page mapped in the guest physical address space of the guest partition and a memory page visibility class. The computer system determines whether the physical memory page mapped to the guest memory page meets the memory page visibility class. Based on the physical memory page meeting the memory page visibility class, the computer system sets the page reception instruction for the guest memory page from a non-reception state to a reception state.

Description

Background Art

[0001] Hypervisor-based virtualization technology allocates portions of a computer system's physical resources (e.g., processor cores and / or time, physical memory regions, storage resources, etc.) into separate partitions and runs software within each of those partitions. Hypervisor-based virtualization technology thus facilitates the creation of virtual machine (VM) guests that each execute guest software such as an operating system (OS) and other software running within the VM guest. Hypervisor-based virtualization technology can take various forms, but many use an architecture that includes a hypervisor that has direct access to the hardware and operates in an execution environment separate from all other software in the system, a host partition that runs the host OS and the host virtualization stack, and one or more guest partitions corresponding to the VM guests. The host virtualization stack within the host partition manages the guest partitions, and thus the hypervisor gives the host partition a greater level of access to the hypervisor and hardware resources than it gives to the guest partitions.

[0002] As an example, taking HYPER-V from MICROSOFT CORPORATION, the HYPER-V hypervisor is the lowest layer of the HYPER-V stack. The HYPER-V hypervisor dispatches virtual processors for VM guests and provides basic functions for execution, but it relies on the HYPER-V host stack for many other aspects of VM guest virtualization. The HYPER-V hypervisor acquires ownership of hardware virtualization features (e.g., second-level address translation (SLAT) processor extensions such as Rapid Virtualization Indexing from ADVANCED MICRO DEVICES or Extended Page Table from INTEL, an I / O memory management unit (IOMMU) that connects a direct memory access-capable input / output (I / O) bus to main memory, processor virtualization control), and the HYPER-V hypervisor provides a set of interfaces to enable the HYPER-V host stack to utilize these virtualization features to manage VM guests. The HYPER-V host stack, on the other hand, contains most of the HYPER-V functionality. The HYPER-V host stack contains components that provide general functions for VM guest virtualization (e.g., memory management, VM guest lifecycle management, device virtualization) across the kernel and user mode of the host OS operating within the host partition.

[0003] Using current hypervisor-based virtualization architectures, the host OS (and the virtualization stack operating within it) assumes that it has full access to each VM guest, including all of the state of the VM guest. For example, the host virtualization stack expects to be able to read from and write to any part of the memory of the guest partition (for purposes of, e.g., device I / O), and expects to be able to read and manipulate the processor registers of the guest partition (for purposes of, e.g., device emulation).

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or embodiments that operate only in environments such as those described above. Rather, this background art is provided only to illustrate one exemplary technical field in which some embodiments described herein may be implemented.

Summary of the Invention

[0005] In some aspects, the techniques described herein are a method implemented in a computer system including a processor for separating VM guest resources from a host OS, the method comprising receiving a reception request from a guest partition corresponding to a separated VM guest, the reception request identifying a guest memory page mapped in the guest physical address (GPA) space of the guest partition and a memory page visibility class; and setting a page reception instruction for the guest memory page from a non-receiving state to a receiving state based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class.

[0006] In some aspects, the techniques described herein are a computer system for separating VM guest resources from a host OS, the computer system including a processor and a computer storage medium storing computer-executable instructions executable by the processor to cause the computer system to receive a reception request from a guest partition corresponding to a separated VM guest, the reception request identifying a guest memory page mapped in the GPA space of the guest partition and a memory page visibility class; and set a page reception instruction for the guest memory page from a non-receiving state to a receiving state based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class.

[0007] In some aspects, the techniques described herein include a computer program product including a computer storage medium storing computer-executable instructions executable by a processor to separate VM guest resources from a host OS in a computer system, the computer-executable instructions including at least receiving a reception request from a guest partition corresponding to a separated VM guest, the reception request specifying a guest memory page mapped in a GPA space of the guest partition and a memory page visibility class, and setting a page acceptance instruction for the guest memory page from a non-accepted state to an accepted state based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class, which is related to a computer program product including instructions executable by a processor to cause a computer system to perform the above actions.

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description of the embodiments for implementing the invention. This summary is neither intended to identify key features or essential features of the claimed subject matter nor intended to be used as an aid in determining the scope of the claimed subject matter.

[0009] To describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more detailed description of the embodiments briefly described above is provided by reference to those specific embodiments shown in the accompanying drawings. It should be understood that these drawings only illustrate typical embodiments of the systems and methods described herein and thus are not considered to limit their scope. With the use of the accompanying drawings, some systems and methods will be described and explained with additional specificity and detail.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

[0011] In cloud computing architectures, customer VM guests and the data they operate on are hosted by cloud providers within a virtualized environment. As cloud computing becomes more common, providing strong assurances about the confidentiality and integrity of hosted VM guests and their data has become increasingly important for cloud providers and their customers. For example, by being able to provide strong assurances about the security and privacy of hosted VM guests, security-conscious customers can move their workloads to the cloud. Additionally, stronger separation and protection of VM guests can prevent malicious intrusions into on-premises virtualization fabrics, so stronger separation and protection of VM guests can also be beneficial for on-premises customers who manage their own data centers.

[0012] At least some of the embodiments described herein are directed to a software-based architecture, referred to herein as the IVM architecture, for providing IVM guests. The IVM architecture enables highly secure and confidential computing by completely separating the VM guest state (e.g., registers, memory) from the host operating system (OS) running within the host partition and also from the entity that manages the computing system on which the IVM guest is hosted. To achieve the above, the IVM architecture described herein introduces a new security boundary between the hypervisor and the host virtualization stack. In an embodiment, this new security boundary is enforced by the hypervisor by restricting which VM guest resources can be accessed by the host OS (and thus the host virtualization stack) in order to guarantee the integrity and confidentiality of the IVM guest.

[0013] In addition to these security benefits, in an embodiment, the IVM architecture described herein provides the benefit of supporting existing guest operating systems (e.g., without requiring changes to the guest OS kernel and bootloader). For example, in an embodiment, an existing guest OS can be supported via enlightened OS drivers. Further, since the IVM architecture described herein is software-based, it is operable on existing computing hardware. Thus, for example, a cloud provider can leverage the security benefits described herein without having to wait for the development or purchase of a new hardware system designed with hardware-based VM guest isolation.

[0014] FIG. 1 shows an exemplary computer architecture 100 that facilitates software isolation of VM guest resources (including, for example, the IVM architecture). As shown, computer architecture 100 includes hardware 101 (e.g., a computer system) comprising a processor 102 (e.g., a single processor or multiple processors), a memory 103 (e.g., system memory or main memory), a storage medium 104 (e.g., a single computer-readable storage medium or multiple computer-readable storage media), an IOMMU 105, and firmware 106 (stored, for example, on storage medium 104 and / or on a dedicated memory device such as read-only memory). Although not shown, hardware 101 may also include other hardware devices such as a trusted platform module (TPM) to facilitate a measured boot function, a network interface (e.g., one or more network interface cards) for interconnecting to one or more other computer systems (via a network), a video display interface, a user input interface, etc.

[0015] As shown in the illustration, in computer architecture 100, hypervisor 107 operates directly on hardware 101. Generally, hypervisor 107 divides hardware resources (e.g., processor 102, memory 103, I / O resources) between host partition 111 that executes host OS 116 and guest partitions 112 (or, as shown in the illustration, multiple guest partitions) that execute guest OS 118. In the description herein, the term "VM guest" is used to refer to a "guest partition", and the term "IVM guest" is used to indicate when a VM guest is a separate VM guest operating in a separate guest partition under the IVM architecture described herein. Hypervisor 107 also enables coordinated communication between partitions via bus 113 (e.g., a VM bus). As shown in the illustration, host OS 116 includes a virtualization stack 117, and virtualization stack 117 manages VM guest virtualization (e.g., memory management, VM guest lifecycle management, device virtualization) via one or more application program interfaces (APIs) calls to hypervisor 107.

[0016] Computer architecture 100 includes security component 108, and security component 108 provides a function for converting any VM guest, such as guest partition 112, into an IVM guest by separating resources (e.g., registers within processor 102, portions of memory 103, I / O resources) allocated from host OS 116 (and thus from virtualization stack 117) to the VM guest. In an embodiment, security component 108 has privileged access to the VM guest state. In computer architecture 100, security component 108 is shown as operating within hypervisor 107, and thus, in some embodiments, the functions of security component 108 are implemented partially or fully within hypervisor 107.

[0017] In computer architecture 100, host partition 111 is shown as including a high-trust zone 114 and a low-trust zone 115. Here, host OS 116 operates within low-trust zone 115, and security component 108 operates within high-trust zone 114. Thus, in some embodiments, the functionality of security component 108 is implemented partially or fully within high-trust zone 114. In an embodiment, high-trust zone 114 is separated from low-trust zone 115 based at least on mappings within SLAT table 109 that map system physical addresses (SPA) to guest physical addresses (GPA) and mappings within an IOMMU translation table (IOMMU table 110). As a result, high-trust zone 114 (and security component 108) is separated from low-trust zone 115 (as well as host OS 116 and software operating on host OS 116 such as virtualization stack 117). In one example, hypervisor 107 is a HYPER-V hypervisor that supports virtualization-based security (VBS) to subdivide partitions into virtual trust levels (VTL), and high-trust zone 114 operates under VBS in VTL0 with higher privileges, and low-trust zone 115 operates under VBS in VTL1 with lower privileges.

[0018] In an embodiment, using the security component 108, the IVM architecture introduces a new security boundary between the hypervisor 107 and the host OS 116. This new security boundary is shown using the thick lines surrounding the low-trust zone 115 and the thick lines surrounding the IOMMU 105. In an embodiment, due to this new security boundary, the components of the computer architecture 100 that are within the virtualized trusted computing base (TCB) on which the IVM guest depends are only the trusted firmware components within the firmware 106, the hypervisor 107, and (if present) the components within the high-trust zone 114 of the host partition 111. In an implementation that uses the HYPER-V stack and uses WINDOWS as the host OS 116, the introduction of this new security boundary results in a 95% ultra-reduction in the number of lines of code within the virtualized TCB, thereby significantly reducing the potential attack surface. In addition to reducing the size of the virtualized TCB, the IVM architecture described herein also provides a clear and scoped security boundary between the virtualized TCB and the rest of the system. This security boundary is defensible and greatly simplifies the verification of the TCB of the virtualized host.

[0019] According to this new security boundary, in computer architecture 100, hypervisor 107 and highly trusted zone 114 (including components operating internally such as security component 108) are shown as being trusted and within the virtualized TCB, while low trusted zone 115 (including components operating internally such as host OS 116 and virtualization stack 117) is shown as not being trusted and outside the virtualized TCB. In particular, in embodiments where there is no division of the host partition 111 into a highly trusted zone 114 and a low trusted zone 115 (and thus security component 108 is fully implemented within hypervisor 107), the entire host partition 111 would be within the virtualized TCB. In either case, using this new security boundary, host OS 116 is considered untrusted and outside the virtualized host TCB. This provides a clear and defensible security boundary that strongly separates the IVM guest from host OS 116.

[0020] Furthermore, the DMA devices behind IOMMU 105 are shown as being outside the virtualized TCB, and firmware 106 is shown as having a part within the virtualized TCB and a part outside the virtualized TCB. In embodiments, the amount of firmware 106 within the virtualized TCB varies based on whether computer architecture 100 supports Dynamic Root of Trust for Measurement (D-RTM). On systems that utilize D-RTM, the firmware components within the virtualized TCB can be limited to the microcode of processor 102 and the firmware used for D-RTM activation. This is because D-RTM gives the ability to eliminate from the virtualized TCB the basic input / output system (BIOS) and runtime firmware components including, for example, system management mode (SMM) and Unified Extensible Firmware Interface (UEFI) runtime services. On systems that do not support D-RTM, the BIOS and runtime firmware components can be within the virtualized TCB.

[0021] In an embodiment using the IVM architecture described herein, the hypervisor 107 continues to enable the host OS 116 to control the allocation of processors, memory, and I / O resources to the VM guests as in the prior art. This means that the host OS 116 is still responsible for managing the resource usage of the IVM guests and can use the existing allocation policies to control how much computing resources the IVM guests receive. This also potentially means that the host OS 116 can deny access to resources by the IVM guests and thus prevent the IVM guests from functioning fully or at all. Thus, under the IVM architecture, the host OS 116 still maintains control over the allocation of resources among the hardware 101. However, using the new security boundary introduced by the IVM architecture, the hypervisor 107 restricts the host OS 116 from reading or modifying the contents of the state of the IVM guests. This includes restricting the host OS 116 from accessing the contents of the virtual processor state of the IVM guests as well as restricting the host OS 116 from accessing the memory contents of the IVM guests.

[0022] FIG. 2 shows an example 200 of an IVM security component, such as the security component 108 of FIG. 1. Each internal component of the security component 108 shown in FIG. 2 represents various functions that the security component 108 may implement according to the various embodiments described herein. However, it will be understood that the shown components, including the identification information and configuration of the components, are presented only as an aid in describing an exemplary embodiment of the security component 108. In particular, the internal components of the security component 108 may be distributed in various manners between the highly trusted zone 114 and / or the hypervisor 107.

[0023] In Example 200, security component 108 includes an attestation component 201. In an embodiment, the attestation component 201 provides attestation and key management functions that enable the party (host party) operating computer architecture 100 to be completely excluded from the TCB of the virtual host. Since the virtualization stack 117 is not trusted, it cannot rely on the virtualization stack 117 to ensure that the IVM guest has not been tampered with before it is launched. Further, since the guest OS 118 operating within the IVM guest can never guarantee that it is operating on a secure host, it cannot simply query the hypervisor 107 to determine whether it was launched securely. Thus, in order for the IVM guest to be launched securely, the remote server is responsible for attesting to the configuration of the IVM guest's launch and disclosing the IVM guest's secrets (such as encryption keys) to the software operating within the IVM guest. Thus, using the attestation component 201, a tenant operating an IVM guest can securely verify the authenticity and security of the virtual host on which that tenant's IVM guest is operating, and that tenant can disclose keys to the virtual host and receive assurance that the party operating computer architecture 100 cannot access those keys or read / change the state of the IVM guest without detection.

[0024] In Example 200, security component 108 also includes a processor state isolation component 202. Currently, many hypervisors are responsible for managing the processor state of VM guests and give the host OS the ability to read and change the processor state of VM guests for the purpose of emulating devices. In an embodiment, the processor state isolation component 202 completely isolates the processor state of the IVM guest from the host OS 116. In particular, the processor state isolation component 202 prevents the host OS 116 from reading or writing to the registers of the IVM guest, including the IVM guest's instructions and stack pointer.

[0025] In an embodiment, the processor state isolation component 202 also prevents the host OS 116 from setting intercepts for events that could result in the leakage of confidential information to the host OS 116. In an embodiment, the processor state isolation component 202 also limits the types of interrupts and exceptions that the host OS 116 can generate for the IVM guest. In one example, the processor state isolation component 202 permits synthetic interrupts to be generated by the host OS 116 for the purpose of para-virtualized communication over the bus 113. However, since the IVM guest will be vulnerable to unexpected interrupts and exceptions at any point during its execution, giving the host OS 116 the ability to generate emulated interrupts or exceptions would create an attack surface, and thus the processor state isolation component 202 does not permit emulated interrupts or exceptions to be generated by the host OS 116.

[0026] In example 200, the security component 108 also includes a memory isolation component 203. In an embodiment, the memory isolation component 203 separates the memory of the IVM guest from components outside the security boundary shown in FIG. 1. This includes separating the memory of the IVM guest from the host OS 116 and from the DMA devices behind the IOMMU 105. Further, in an embodiment, the memory isolation component 203 protects the integrity of the GPA space (e.g., the address space that the IVM guest considers to be its own physical address space) of each IVM guest.

[0027] In computer architecture 100, host OS 116 is responsible for memory management (e.g., via virtualization stack 117). Thus, host OS 116 is responsible for allocating physical memory for the IVM guest and assigning physical memory to the VM guest (e.g., guest partition 112) corresponding to the IVM guest. Host OS 116 also controls the GPA space for the IVM guest and determines where to map the pages in the GPA space of the IVM guest. However, to ensure the separation and integrity of the IVM guest's memory, memory separation component 203 enforces a set of rules regarding host OS 116 when managing the IVM guest's memory. In embodiments, these rules center around memory access control (MAC) and GPA integrity control. Thus, memory separation component 203 is shown as including MAC component 204 and GPA integrity control component 205. In embodiments, MAC component 204 provides the facility to control which portions of memory host OS 116 can access for the IVM guest, while GPA integrity control component 205 provides the facility to enable the IVM guest to always receive guarantees of the integrity of its GPA space.

[0028] Regarding MAC component 204, for the memory pages assigned to the IVM guest, the IVM architecture introduces the concept of memory page visibility classes. In embodiments, MAC component 204 records the host OS visibility for the memory pages as the host visibility attribute for each one or more pages within SLAT table 109. For the memory pages mapped within the GPA space of the IVM guest, these per-page host visibility attributes define the amount of access permitted by host OS 116 to each memory page. In embodiments, these memory page visibility classes include exclusive memory, shared read-only memory, and shared read / write memory. In embodiments, these memory page visibility classes define various attributes regarding the accessibility and management of the memory pages, including the host visibility attribute of the memory pages.

[0029] Regarding exclusive memory, in an embodiment, the exclusive memory is physical memory (e.g., within memory 103) allocated by host OS 116 for exclusive use by an IVM guest. Thus, conceptually, an IVM guest can be considered to "own" the physical memory pages allocated to the IVM guest as exclusive memory. In an embodiment, the IVM guest obtains full access privileges (e.g., read, write, and execute) to the physical memory pages allocated to the IVM guest as exclusive memory. In an embodiment, host OS 116 allocates the physical memory to be used for the IVM guest's memory and then makes one or more API calls to hypervisor 107 to allocate the physical memory for use as the IVM guest's memory. When host OS 116 allocates a memory page as exclusive to an IVM guest, MAC component 204 removes host OS 116's access to that memory page. This ensures that the content of the IVM guest's exclusive memory page is inaccessible by host OS 116. Thus, host OS visibility for the IVM guest's exclusive memory page is no access. In an embodiment, MAC component 204 enforces host OS visibility by controlling the SLAT table 109 (e.g., host second-level page table) for host OS 116 and the IOMMU table 110 for DMA devices. Thus, when host OS 116 allocates a physical memory page and allocates it to an IVM guest for exclusive use, MAC component 204 updates the SLAT table 109 for host OS 116 to prevent host OS 116 from accessing the memory page and updates the IOMMU table 110 to prevent access to the memory page by DMA devices and their downstream consumers.

[0030] In an embodiment, the host OS 116 cannot regain ownership / control of the exclusive memory pages of the IVM guest until the memory pages are completely unmapped from the GPA space of the IVM guest. In an embodiment, as part of unmapping exclusive memory pages from the GPA space of the IVM guest, the MAC component 204 wipes / clears the content of the memory pages (e.g., by zeroing the memory pages, by writing a pattern of bits to the memory pages, by writing random bits to the memory pages, by deleting the encryption key associated with the memory pages).

[0031] In an embodiment, the MAC component 204 enforces a set of rules to ensure the privacy and integrity of exclusive memory. In an embodiment, these rules require that exclusive memory pages of the IVM guest are mapped / owned by only a single VM guest at a time, that exclusive memory pages of the IVM guest are mapped to only a single GPA of the IVM guest, that the content of the memory pages is wiped before the exclusive memory pages of the IVM guest are re-released to the host OS 116, and that the exclusive memory pages of the IVM guest are wiped upon system reset (e.g., reset of the IVM guest).

[0032] As described, exclusive memory pages are by default invisible to the host OS 116. However, there may be cases where the guest OS 118 within the IVM guest needs to grant the host OS 116 access to some of its exclusive memory pages (for example, for I / O purposes). To facilitate this, in an embodiment, the MAC component 204 permits the IVM guest to change host visibility on a per-page basis for exclusive memory pages. In one example, the MAC component 204 exposes to the IVM guest an API that permits the IVM guest to call the hypervisor 107 to control host visibility for its exclusive memory pages (for example, via a call from a guest enlightenment 119, such as a driver operating within the guest OS 118). In an embodiment, when the IVM guest grants or removes host visibility from an exclusive memory page, the MAC component 204 updates the SLAT table 109 and the IOMMU table 110 for the host OS 116 to grant or deny access to the memory page to the host OS 116.

[0033] Regarding the shared read-only memory, the shared read-only memory is defined as the memory of the host OS 116 that is read-only for both the host and one or more VM guests. Thereby, the shared read-only memory is suitable for scenarios such as direct map where the host OS 116 desires to directly map image pages into one or more VM guests. In an embodiment, to map a shared read-only page into a VM guest, the host OS 116 first designates a memory page as read-only by calling a call to notify the hypervisor 107. The host OS 116 then maps the memory page as a shared read-only page into the VM guest. In an embodiment, while mapping a shared read-only memory page into a VM guest, the host OS 116 continues to have read access to that memory page. Thus, in an embodiment, the shared read-only memory page is always visible to the host for read access, and the VM guest cannot change the host visibility attribute for the shared read-only memory page. In an embodiment, the shared read-only memory page can be mapped into multiple VM guests, and it can be mapped at multiple different GPAs within the same VM guest.

[0034] Regarding the shared read-write memory, the shared read-write memory is defined as the memory of the host OS 116 that is read-write for both the host OS 116 and the VM guests. Thus, the shared read-write page is always visible to the host for both read and write access, and the VM guest cannot change the host visibility attribute for the shared read-write page. As will be appreciated, since the host OS 116 can change the content at any time, the VM guest cannot make any assumptions about the content of the shared read-write memory. In an embodiment, the shared read-write memory is used by the host OS 116 to set up a memory area for sharing data between the VM guest and the host OS 116.

[0035] Regarding the GPA integrity control component 205, the GPA integrity control component 205 enables an IVM guest to obtain several guarantees regarding the integrity and behavior of their GPA space. To guarantee the integrity of the IVM guest's memory, the IVM architecture introduces the concept of "acceptance" for memory pages mapped in the IVM guest's GPA space. Using this acceptance model, an IVM guest accepts a memory page before accessing it. In an embodiment, if an IVM guest attempts to access a memory page that it has not previously accepted, the hypervisor 107 generates a fault in the guest (e.g., on an X64 platform, the hypervisor 107 may generate a #VE exception).

[0036] In an embodiment, the IVM guest performs one or more API calls (e.g., using guest enlistment 119) processed by the GPA integrity control component 205 that specify the GPA to be received and one or more attributes of the GPA that are expected (e.g., indicate the class of memory it expects for the memory pages in the GPA) to receive a memory page. The GPA integrity control component 205 then determines whether the physical memory page mapped by the host OS 116 to the specified GPA meets the criteria of the indicated class of memory and marks that memory page as received (when the GPA meets the criteria of the indicated class of memory) or not received (when the GPA does not meet the criteria of the indicated class of memory). In an embodiment, the GPA integrity control component 205 marks a memory page as received or not received by setting or clearing a flag or bit in the SLAT table 109 for the IVM guest. In one embodiment, a value of 1 indicates received and a value of 0 indicates no reception. Thus, if the IVM guest expects that one class of memory is mapped at a particular GPA, but the host OS 116 actually maps a different class of memory, the reception operation fails and as a result, the memory page is marked as not received. In an embodiment, the hypervisor 107 prohibits the host OS 116 from marking a memory page as received, and thus only the IVM guest can receive a memory page for itself via the GPA integrity control component 205.

[0037] In an embodiment, the GPA integrity control component 205 also prevents the host OS 116 from improperly remapping the pages of the IVM guest, which could result in undetected fraud or unexpected behavior while the IVM guest is using a memory page. For example, whenever the host OS 116 changes which physical memory pages are mapped to the GPA for the IVM guest, the GPA integrity control component 205 sets the acceptance state of the GPA memory page to non-accepted. Thus, if the host OS 116 attempts to remap the GPA from one SPA to a different SPA, the GPA integrity control component 205 clears the acceptance state of the memory page, and any future attempt by the IVM guest to access the GPA will fault.

[0038] As will be appreciated in view of the description herein, this memory acceptance model may not prevent the host OS 116 from improperly changing the GPA space of the IVM guest. However, this memory acceptance model guarantees that the IVM guest will be informed of any unauthorized changes to its GPA space. For example, the IVM guest can receive all of its addressable memory pages during boot and begin using its memory. Then, if the host OS 116 changes the mapping from the SPA to the GPA for the IVM guest, the IVM guest is notified because the next access to the GPA causes a fault. In an embodiment, when the IVM guest desires to allow changes to occur in its GPA space for scenarios such as adding and deleting memory, the acceptance model allows the IVM guest to cooperate with the host OS 116.

[0039] In Example 200, security component 108 also includes memory paging component 206. In an embodiment, memory paging is a special case where the IVM architecture allows the host OS 116 to modify the GPA space of a running IVM guest without cooperation with the guest OS 118. To facilitate memory paging, memory paging component 206 executes a defined paging flow in which the host OS 116 cooperates. In particular, memory paging component 206 records integrity information (e.g., hash, checksum) of the contents of a memory page during page-out, and then uses this integrity information to verify the contents of the memory page during page-in, thereby preventing the host OS 116 from improperly modifying the page contents. In some embodiments, such as when paging a memory page that is not visible to the host (e.g., an exclusive memory page not visible to the host), memory paging component 206 also encrypts the memory page contents during page-out and decrypts the memory page contents of that page during page-in (e.g., using an encryption key specific to the IVM guest).

[0040] In some environments, when a VM guest boots, the host OS injects boot firmware (e.g., UEFI BIOS) into the memory of the VM guest to “boot” that OS within the VM guest. Thus, for the guest OS within the VM guest, the boot process appears substantially the same as it would appear on a physical machine, and the same OS boot loader as on a physical machine can be used within the VM guest. However, the IVM architecture described herein moves the host OS 116 outside the TCB of the IVM guest, and thus the host OS 116 can no longer inject any firmware into the IVM guest because this would not be secure. Further, reliance on the host OS 116 as a source of trust for the purpose of attesting to the startup of the IVM guest cannot be done. The design principle of the IVM guest is that the tenant has complete control over all of the code operating within the IVM guest. Thus, in the IVM architecture described herein, the tenant has control over the firmware operating within its IVM guest. Further, the IVM architecture gives the tenant a way to verify, through measurement and attestation of the firmware, that the firmware loaded into the tenant's IVM guest is the appropriate firmware.

[0041] In Example 200, security component 108 also includes a firmware injection component 207. In an embodiment, the firmware injection component 207 facilitates firmware injection within the IVM architecture and enables different models for injecting boot firmware into the IVM guest. In a first model, the tenant owning the IVM guest relies on the host OS 116 to provide a known good boot firmware image. To secure this first model, the tenant needs to be confident that the boot firmware provided by the host OS 116 is a known good image and that it does not contain malicious / compromised code. In an embodiment, this is achieved by providing an open source boot firmware image built from a public open source repository. This enables the tenant, who desires to rely on the provided boot firmware, to audit the firmware content and accurately know what is included within the boot firmware image. In other embodiments, the tenant owning the IVM guest provides its own boot firmware image to be used for the IVM guest. In an embodiment, to distribute the boot firmware, a defined boot firmware image format includes a binary firmware blob to be loaded into the memory of the IVM guest prior to startup of the IVM guest, metadata specifying, for example, where in the GPA space of the IVM guest the boot firmware image should be loaded, and an offset into the boot firmware image as to where execution should start.

[0042] Figure 3 shows an example 300 of the phases of the IVM guest life cycle. As shown in example 300, the IVM guest life cycle includes a phase 301 of creating a separate guest partition (e.g., guest partition 112), where the virtualization stack 117 calls the API of the hypervisor 107 therein to create the guest partition 112 (IVM guest). During this initialization phase of the IVM guest, the virtualization stack 117 takes conventional steps to initialize the partition using the hypervisor 107, including allocating and assigning physical memory to the IVM guest. In view of the above description of the MAC component 204 and the GPA integrity control component 205, it is understood that all memory pages assigned to the IVM guest have not yet been received by the IVM guest and, thus, these memory pages are not yet accessible by the IVM guest.

[0043] The IVM guest life cycle also includes a phase 302 of obtaining the IVM guest boot firmware (e.g., boot firmware 120). As shown, there is no required ordering between phase 301 and phase 302. In phase 302, the virtualization stack 117 is provided with an initial boot firmware image for the IVM guest to load into memory. This initial boot firmware image includes a boot loader, where the IVM guest starts execution. This initial boot firmware image is an image specified by the owner of the IVM guest or a standard image provided by the host OS 116. This enables the user to specify their own boot firmware image or use a standard boot firmware image provided by the virtualization product or the host.

[0044] The IVM guest life cycle also includes phase 303 which associates the IVM security components with a separate guest partition. In phase 303, the virtualization stack 117 launches an instance of the security component 108 for the IVM guest and associates this instance with the IVM guest. The IVM guest life cycle also includes phase 304 which provides the IVM guest boot firmware to the IVM security components. In phase 304, the virtualization stack 117 provides a boot firmware image to the security component 108 and specifies where in the GPA space of the IVM guest the boot firmware image should be loaded.

[0045] The IVM guest life cycle also includes phase 305 which copies the IVM guest boot firmware to the separate guest memory. In phase 305, the firmware injection component 207 copies the boot firmware image into an appropriate location (e.g., the boot firmware 120) in the GPA space of the IVM guest. Along with this, the firmware injection component 207 (or the GPA integrity control component 205) changes the reception state of the GPA memory pages containing the boot firmware image to "accepted", thus enabling the IVM guest to access these boot firmware image memory pages.

[0046] When the boot firmware is fully established, the virtualization stack 117 indicates to the hypervisor 107 that the IVM guest is now ready to start execution. At this point, the virtualization stack 117 can no longer manipulate the configuration of the IVM guest nor access the exclusive memory of the IVM guest.

[0047] The IVM guest life cycle also includes phase 306 which measures the IVM guest configuration. In phase 306, the configuration attestation component 201 measures the configuration of the IVM guest, including the initial boot firmware image of the IVM guest.

[0048] The IVM guest life cycle also includes phase 307 that starts the execution of the IVM guest. In phase 307, the security component 108 starts the execution of the IVM guest when the initial bootloader of the IVM guest starts. Thus, in this phase, the IVM guest is operating. The memory pages that the IVM guest can access are only the memory pages initialized as part of injecting the initial boot firmware image.

[0049] The IVM guest life cycle also includes phase 308 that manages the IVM guest memory page acceptance model. In phase 308, the IVM guest receives additional memory pages using the API calls passed by the GPA integrity control component 205. In some embodiments, this includes the initial bootloader querying the host OS 116 about the memory configuration information and then receiving the pages based on the memory configuration of the IVM guest reported by the host OS 116. As described with the description of the acceptance model, if there is a discrepancy between what the host OS 116 reports and what the IVM guest can accept, the acceptance fails and this is detected during acceptance.

[0050] Although not explicitly shown, when the IVM guest is stopped, its memory is reused from the hypervisor 107 by the virtualization stack 117. As part of the reuse, the MAC component 204 wipes the content of all exclusive memory pages of the IVM guest before giving the host OS 116 access to the memory content.

[0051] Next, with reference to FIG. 4, which shows a flowchart of an exemplary method 400 for separating VM guest resources (e.g., guest partition 112) from a host OS (e.g., host OS 116 within host partition 111), the operation of computer architecture 100 will be described. In an embodiment, instructions for implementing method 400 are encoded as computer-executable instructions (e.g., security component 108) stored on a computer storage medium (e.g., storage medium 104) that are executable by a processor (e.g., processor 102) to cause a computer system (e.g., hardware 101) to execute method 400.

[0052] Next, several methods and method acts will be referred to in the following description. Method acts may be described in several orders and may be shown in a flowchart as being performed in a particular order, but unless specifically stated otherwise, or unless an act depends on another act being completed before that act is performed, no particular ordering is required unless necessary.

[0053] Referring to FIG. 4, method 400 includes an act 401 of receiving a guest memory page acceptance request. In some embodiments, act 401 includes receiving an acceptance request from a guest partition corresponding to a separated VM guest (IVM guest). In an embodiment, the acceptance request specifies (1) a guest memory page mapped in the GPA space of the guest partition and (2) a memory page visibility class. In one example, GPA integrity control component 205 receives an API call from guest partition 112 (e.g., originating from guest enlightenment 119) that requests to accept a memory page (e.g., by referring to the GPA of the memory page) with an expected memory page visibility class (e.g., exclusive visibility, shared read-only visibility, shared read-write visibility).

[0054] Method 400 also includes an act 402 of determining whether the mapped physical memory page meets the memory page visibility class required. In some embodiments, act 402 includes the step of determining whether the physical memory page mapped to the guest memory page meets the memory page visibility class. In one example, GPA integrity control component 205 determines what physical memory page maps to the guest memory page indicated by the IVM guest, what memory page visibility class the IVM guest expects, and whether the physical memory page meets that memory page visibility class.

[0055] As shown, act 402 includes act 403 when the memory page visibility class is exclusive visibility (e.g., when the memory page visibility class is an exclusive visibility class), and includes act 406 when the required memory page visibility class is shared visibility (e.g., when the memory page visibility class is a shared read-only visibility class or when the memory page visibility class is a shared read-write visibility class).

[0056] When the required memory page visibility class is exclusive visibility (act 403), method 400 includes act 404 of verifying guest exclusivity (via SLAT). In an embodiment, act 404 includes the step of verifying that a physical memory page is exclusively mapped to a guest memory page via one or more guest SLATs. For example, as described, MAC component 204 requires that exclusive memory pages of an IVM guest be mapped / owned by only a single VM guest at a time (e.g., within SLAT table 109) and that exclusive memory pages of the IVM guest be mapped to only a single GPA of the IVM guest (e.g., within SLAT table 109) to ensure the privacy and integrity of the exclusive memory. Thus, in some embodiments, GPA integrity control component 205 verifies that each of these conditions holds for the physical memory pages mapped to the required guest memory pages.

[0057] When the required memory page visibility class is exclusive visibility (act 403), method 400 also includes act 405 of verifying that no host is accessing (via SLAT). In an embodiment, act 405 includes the step of verifying, via a host OS SLAT, that the host OS has been denied access to the physical memory page. For example, as described, MAC component 204 enforces host OS visibility by controlling SLAT table 109 for host OS 116. Thus, when host OS 116 allocates a physical memory page and assigns it to an IVM guest for exclusive use by the IVM guest, MAC component 204 updates SLAT table 109 for host OS 116 to prevent host OS 116 from accessing the memory page.

[0058] Although not shown in FIG. 4, as described, MAC component 204 can also enforce host OS visibility to memory pages by controlling the IOMMU table 110 for the DMA device. Thus, some embodiments of act 403 further include verifying that the DMA device has been denied access to a physical memory page via the host OS IOMMU table.

[0059] As described with the explanation of exclusive visibility, the guest OS 118 within the IVM guest may need to give the host OS 116 access to some of its exclusive memory pages (e.g., for I / O purposes), and to facilitate this, there are cases where the MAC component 204 allows the IVM guest to change host visibility on a page-by-page basis for exclusive memory pages. Thus, some embodiments of method 400 further include receiving a visibility change request from the guest partition, the visibility change request including an indication of a guest memory page, and updating the host OS SLAT to give the host OS access to the physical memory page.

[0060] In embodiments where the required memory page visibility class is a shared visibility, such as shared read-only visibility or shared read-write visibility (act 403), method 400 includes act 407 of verifying (via the SLAT) host shared access. In some embodiments, the memory page visibility class is the shared read-only visibility class, and act 407 includes verifying that the physical memory page satisfies the memory page visibility class, including verifying that the host OS has been given read-only access to the physical memory page via the host OS SLAT. In other embodiments, the memory page visibility class is the shared read-write visibility class, and act 407 includes verifying that the physical memory page satisfies the memory page visibility class, including verifying that the host OS has been given read-write access to the physical memory page via the host OS SLAT.

[0061] Depending on the result of act 402, method 400 includes act 408 of receiving a memory page (when act 402 determines that the mapped physical memory page meets the memory page visibility class required for the memory page), or act 409 of rejecting a memory page (when act 402 determines that the mapped physical memory page does not meet the memory page visibility class required for the memory page). In some embodiments, act 408 includes setting the page acceptance instruction for the guest memory page from a non-accepted state to an accepted state based on the fact that the physical memory page mapped to the guest memory page meets the memory page visibility class. In some embodiments, act 409 includes setting the page acceptance instruction for the guest memory page to a non-accepted state based on the fact that the physical memory page mapped to the guest memory page does not meet the memory page visibility class.

[0062] As a result of method 400, the IVM guest accepts the physical memory page mapped to the specified guest memory page only when the physical memory page meets the excluded memory page visibility class. In this way, the IVM guest is made aware of the security implications of using the specified guest memory page, such as whether the content of the guest memory page is exclusive to the IVM guest or whether the content of the guest memory page can be read and / or written by the host OS 116 and / or another VM guest. This gives the IVM guest the ability to separate its data from the host OS 116.

[0063] As described above, the GPA integrity control component 205 prevents the host OS 116 from improperly remapping the memory pages of the IVM guest while the IVM guest is using them. This protection occurs when the host OS 116 sets the acceptance state of the memory page to non-accepted when it changes the physical memory page that the GPA maps for the IVM guest. Thus, in some embodiments, method 400 further includes detecting that a guest memory page has been mapped to a different physical memory page, and setting the page acceptance indication for the guest memory page to a non-accepted state.

[0064] As described above, in embodiments where the IVM guest attempts to access a memory page that it has not previously accepted, the hypervisor 107 generates a fault into the guest (e.g., on an X64 platform, this could be a #VE exception). Thus, in some embodiments, method 400 also includes detecting access by the guest partition to an address covered by a guest memory page before receiving an acceptance request, and generating a page fault based on the page acceptance indication for the guest memory page being in a non-accepted state.

[0065] As described, the memory paging component 206 performs a defined paging flow where the memory paging component 206 records integrity information (e.g., hash, checksum) of the content of a memory page during page out by the host OS 116, and then uses this integrity information to verify the content of the page during page in by the host OS 116, thereby preventing the host OS 116 from improperly modifying the page content. Thus, in some embodiments, method 400 includes recording integrity information about the content of a physical memory page based on receiving a page out request from the host OS that identifies the physical memory page, and using the integrity information to verify the content of the physical memory page based on receiving a page in request from the host OS that includes an indication of the physical memory page.

[0066] Further, as described, the memory paging component 206 may also encrypt the memory page content during page out and decrypt the memory page content of that page during page in. Thus, in some embodiments, method 400 includes encrypting the content of a physical memory page based on receiving a page out request from the host OS, and decrypting the content of the physical memory page based on receiving a page in request from the host OS.

[0067] As described, the firmware injection component 207 facilitates firmware injection within the IVM architecture. As described with phase 305 of the IVM guest life cycle, the firmware injection component 207 copies the boot firmware image into an appropriate location within the GPA space of the IVM guest, and the firmware injection component 207 (or the GPA integrity control component 205) then changes the state of the GPA memory pages containing the boot firmware image to receptive, thereby enabling the IVM guest to access these boot firmware image memory pages. Thus, in some embodiments, method 400 further includes, prior to receiving a receptivity request, populating one or more guest memory pages within the GPA space using guest boot firmware, and for each memory page among the one or more guest memory pages, setting a corresponding page receptivity indication to a receptive state.

[0068] As described, in an embodiment, as part of unmapping an exclusive memory page from an IVM guest, the MAC component 204 wipes the content of the memory page (e.g., by zeroing the memory page, by writing a pattern of bits to the memory page, by writing random bits to the memory page, by deleting the encryption key associated with the memory page). Thus, in some embodiments, the method 400 also includes the step of wiping the content of a physical memory page based on at least one of the guest memory page being freed to the host OS or the isolated VM guest being shut down. As described, the processor state isolation component 202 completely isolates the processor state of the IVM guest from the host OS 116 by preventing the host OS 116 from reading or writing to the registers of the IVM guest (including, e.g., the instructions and stack pointer of the IVM guest). Thus, in some embodiments, the method 400 also includes the step of isolating the content of one or more processor registers from the host OS.

[0069] Embodiments of the present disclosure may include or utilize a special purpose or general purpose computer system including computer hardware, such as, for example, one or more processors (e.g., processor 102) and system memory (e.g., memory 103). 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 purpose or special purpose computer system. A computer-readable medium that stores computer-executable instructions and / or data structures is a computer storage medium (e.g., storage medium 104). A computer-readable medium that carries computer-executable instructions and / or data structures is a transmission medium. Thus, by way of example, embodiments of the present disclosure can include at least two distinctly different types of computer-readable media, namely, computer storage media and transmission media.

[0070] A computer storage medium is a physical storage medium that stores computer-executable instructions and / or data structures. The physical storage medium includes 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 device, magnetic disk storage device or other magnetic storage device, or any other hardware storage device 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 purpose or special purpose computer system to implement the disclosed functionality.

[0071] A transmission medium can be used to carry program code in the form of computer-executable instructions or data structures and can include a network and / or a data link that can be accessed by a general-purpose or special-purpose computer system. A "network" is defined as one or more data links that enable the transfer of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted to or provided to a computer system via a network or another communication connection (either hardwired, wireless, or a combination of hardwired or wireless), the computer system may consider that connection to be a transmission medium. The above combinations should also be included within the scope of computer-readable media.

[0072] Further, when reaching various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to a computer storage medium (or vice versa). For example, computer-executable instructions or data structures received via a network or a data link are buffered in RAM within a network interface module and then can ultimately be transferred to the computer system RAM and / or to a less volatile computer storage medium in the computer system. Thus, it should be understood that a computer storage medium can also (and even primarily) be included within computer system components that utilize a transmission medium.

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

[0074] It should be understood that the disclosed systems and methods may be implemented in a network computing environment having many types of computer system configurations including, but not limited to, personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, cellular telephones, PDAs, tablets, pagers, routers, switches, and the like. Embodiments of the present disclosure may also be implemented in a distributed system environment where local and remote computer systems, which are linked through a network (either by a hardwired data link, a wireless data link, or a combination of hardwired and wireless data links), both execute tasks. Thus, in a distributed system environment, a computer system may include a plurality of constituent computer systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0075] Also, it will be appreciated that embodiments of the present disclosure may be implemented in a cloud computing environment. The cloud computing environment may be distributed, although this is not essential. When distributed, the cloud computing environment may have components that are internationally distributed within one organization and / or owned across multiple organizations. In this description and the following claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The cloud computing model may be composed of various features such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. The cloud computing model may also be provided 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). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, and hybrid cloud.

[0076] Some embodiments, such as a cloud computing environment, may comprise a system including one or more hosts capable of operating one or more virtual machines. During operation, the virtual machine emulates an operational computing system that supports an OS or one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources extracted from the view of the virtual machines. The hypervisor also provides proper isolation between virtual machines. Thus, from the perspective of any given virtual machine, the virtual machine only interfaces with the appearance of physical resources (e.g., virtual resources), but the hypervisor gives the illusion that the virtual machine is interfacing with physical resources. Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, and the like.

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

[0078] The present disclosure may be implemented in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0079] When introducing elements in the appended claims, the articles "a", "an", "the", and "said" mean that there are one or more elements. The terms "comprising", "including", and "having" are inclusive and mean that there may be additional elements other than the recited elements. Unless otherwise specified, the terms "set", "superset", and "subset" exclude the empty set, and thus, a "set" is defined as a non-empty set, a "superset" is defined as a non-empty superset, and a "subset" is defined as a non-empty subset. Unless otherwise specified, the term "subset" excludes the entirety of its superset (i.e., the superset contains at least one item not included in the subset). Unless otherwise specified, a "superset" may contain at least one additional element and a "subset" may exclude at least one element.

Claims

1. A method implemented in a computer system including a processor for separating resources of a virtual machine (VM) guest from a host operating system (OS), the method comprising: receiving a reception request from a guest partition corresponding to the separated VM guest, the reception request specifying: a guest memory page mapped in a guest physical address (GPA) space of the guest partition; and a memory page visibility class; and setting, based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class, a page reception instruction for the guest memory page from a non-receiving state to a receiving state. The method further including: detecting that the guest memory page is mapped to different physical memory pages; and setting the page reception instruction for the guest memory page to the non-receiving state. The method further including, before receiving the reception request: detecting access by the guest partition to an address covered by the guest memory page; and generating a page fault based on the page reception instruction for the guest memory page being in the non-receiving state. The method further including, before receiving the reception request: populating a guest memory page within the GPA space using guest boot firmware; and setting a corresponding page reception instruction to the receiving state. The method further including: determining that the physical memory page satisfies the memory page visibility class; verifying, via one or more guest second-level address translation (SLAT) tables, that the physical memory page is exclusively mapped to the guest memory page; and verifying, via a host OS SLAT, that the host OS has been denied access to the physical memory page.

2. The method according to claim 1, further comprising: detecting that the guest memory page is mapped to different physical memory pages; and setting the page reception instruction for the guest memory page to the non-receiving state.

3. The method according to claim 1, further comprising, before receiving the reception request: detecting access by the guest partition to an address covered by the guest memory page; and generating a page fault based on the page reception instruction for the guest memory page being in the non-receiving state.

4. The method according to claim 1, further comprising, before receiving the reception request: populating a guest memory page within the GPA space using guest boot firmware; and setting a corresponding page reception instruction to the receiving state.

5. The method according to claim 5, further comprising the step of verifying, via a host OS input / output memory management unit table, that direct memory access devices are denied access to the physical memory page.

7. The method according to claim 5, receiving a visibility change request from the guest partition, the visibility change request including an indication of the guest memory page; updating the host OS SLAT to provide access to the physical memory page to the host OS and further comprising a method.

8. The method according to claim 1, wherein the memory page visibility class is a shared read-only visibility class, the method further comprising the step of determining that the physical memory page meets the memory page visibility class, the step including verifying, via a host OS second-level address translation table, that the host OS is granted read-only access to the physical memory page. Method.

9. The method according to claim 1, wherein the memory page visibility class is a shared read / write visibility class, the method further comprising the step of determining that the physical memory page meets the memory page visibility class, the step including verifying, via a host OS second-level address translation table, that the host OS is granted read / write access to the physical memory page. Method.

10. The method according to claim 1, wiping the content of the physical memory page based on at least one of the guest memory page being freed to the host OS or the isolated VM guest being shut down and further comprising a method.

11. The method according to claim 1, recording integrity information about the content of the physical memory page based on receiving a page-out request from the host OS that identifies the physical memory page; using the integrity information to verify the content of the physical memory page based on receiving a page-in request from the host OS that includes an indication of the physical memory page and further comprising a method.

12. The method according to claim 11, Based on receiving the page-out request from the host OS, encrypting the content of the physical memory page; Based on receiving the page-in request from the host OS, decrypting the content of the physical memory page; A method further comprising.

13. The method according to claim 1, further comprising separating the content of one or more processor registers from the host OS.

14. A computer system for separating resources of a virtual machine (VM) guest from a host operating system (OS), A processor; A computer storage medium storing computer-executable instructions, the computer-executable instructions at least Receiving an acceptance request from a guest partition corresponding to a separated VM guest, the acceptance request A guest memory page mapped in the guest physical address (GPA) space of the guest partition, and A memory page visibility class Receiving an acceptance request that identifies; Based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class, setting the page acceptance instruction for the guest memory page from a non-accepted state to an accepted state; A computer storage medium executable by the processor to cause the computer system to perform; A computer system including.

15. The computer system according to claim 14, wherein the computer-executable instructions at least Detecting that the guest memory page is mapped to a different physical memory page; Setting the page acceptance instruction for the guest memory page to the non-accepted state; A computer system further including instructions executable by the processor to cause the computer system to perform.

Images