Software isolation of virtual machine resources

Abstract

Virtual machine (VM) guest resources are isolated from a host operating system. The computer system receives an acceptance request from a guest partition corresponding to the isolated VM. The accept request identifies a guest memory page in a guest physical address space mapped to the guest partition, and a memory page visibility category. The computer system determines whether a physical memory page mapped to the guest memory page satisfies a memory page visibility category. The computer system sets a page acceptance indication for the guest memory page from an unaccepted state to an accepted state based on the physical memory page satisfying the memory page visibility category.

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 areas, storage resources, etc.) into separate partitions, and executes software in each of those partitions. Thus, 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 a variety of forms, many hypervisors use an architecture that includes a hypervisor that runs in an execution environment different from all other software in the system with direct access to hardware, a host partition that executes a host OS and a 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 therefore the hypervisor grants the host partition a higher level of access to the hypervisor and hardware resources without granting the guest partition access to these.

[0002] Taking Microsoft's HYPER-V as an example, the HYPER-V hypervisor is the bottom layer of the HYPER-V stack. The HYPER-V hypervisor provides basic functions for scheduling and executing virtual processors for VM guests, but it relies on the HYPER-V host stack to implement multiple other aspects of VM guest virtualization. The HYPER-V hypervisor has hardware virtualization capabilities (e.g., second-level address translation (SLAT) processor extensions, such as fast virtualization indexes from ADVANCED MICRO DEVICES, or extended page tables from INTEL; input / output (I / O) memory management unit (IOMMU), which connects the I / O bus that can directly access the memory to the main memory; processor virtualization control), and it provides a set of interfaces to allow the HYPER-V host stack to utilize these virtualization capabilities to manage VM guests. On the other hand, the HYPER-V host stack contains most of the HYPER-V functions. The HYPER-V host stack contains components across the kernel and user modes of the host OS executed within the host partition, as well as common functions for VM guest virtualization (e.g., memory management, VM guest life cycle management, device virtualization).

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

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

[0005] In some aspects, the technology described herein relates to a method for isolating resources of a VM guest from a host OS, the method being implemented at a computer system including a processor, the method comprising: receiving an accept request from a guest partition corresponding to the isolated VM guest, the accept request identifying: a guest memory page mapped to a guest physical address (GPA) space of the guest partition, and a memory page visibility category; and setting a page acceptance indication for the guest memory page from a never-accepted state to an accepted state based on the physical memory page mapped to the guest memory page satisfying the memory page visibility category.

[0006] In some aspects, the technology described herein relates to a computer system for isolating resources of a VM guest from a host OS, comprising: a processor; and a computer storage device storing computer-executable instructions, the instructions being executable by the processor to at least cause the computer system to: receive an accept request from a guest partition corresponding to the isolated VM guest, the accept request identifying: a guest memory page mapped to a GPA space of the guest partition, and a memory page visibility category; and set a page acceptance indication for the guest memory page from an unaccepted state to an accepted state based on a physical memory page mapped to the guest memory page satisfying the memory page visibility category.

[0007] In some aspects, the technology described herein relates to a computer program product, including a computer storage device storing computer executable instructions, the instructions executable by a processor to cause a computer system to isolate resources of a VM guest from a host OS, the computer executable instructions including instructions executable by the processor to at least cause the computer system to: receive an accept request from a guest partition corresponding to the isolated VM guest, the accept request identifying: a guest memory page mapped to a GPA space of the guest partition, and a memory page visibility category; and set a page acceptance indication for the guest memory page from an unaccepted state to an accepted state based on a physical memory page mapped to the guest memory page satisfying the memory page visibility category.

[0008] This Abstract is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This Abstract is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to describe the manner in which 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 rendered by 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:

[0010] Figure 1 An example computer architecture that facilitates software isolation of VM resources is shown;

[0011] Figure 2 An example of an isolated VM (IVM) security component is shown;

[0012] Figure 3 An example of the stages of an IVM guest life cycle is shown; and

[0013] Figure 4 A flow chart of an example method for isolating resources of a VM guest from a host OS is shown. DETAILED DESCRIPTION

[0014] In a cloud computing architecture, a customer's virtual machine guests and the data they operate on are hosted by a cloud provider in a virtualized environment. As cloud computing becomes commonplace, it is increasingly important for cloud providers and their customers to provide strong guarantees around the confidentiality and integrity of the hosted VM guests and their data. For example, being able to provide strong guarantees around the security and privacy of hosted VM guests enables security-conscious customers to migrate their workloads to the cloud. In addition, providing stronger isolation and protection of VM guests can also benefit local customers who manage their own data centers because stronger isolation and protection of VM guests prevents malicious infiltration into the local virtualization structure.

[0015] At least some embodiments described herein are directed to a software-based architecture, referred to herein as an IVM architecture, to provide an IVM guest. The IVM architecture achieves highly secure and confidential computing by completely isolating the VM guest state (e.g., registers, memory) from the host operating system (OS) executed in the host partition and the entity that manages the computing system on which the VM guest is hosted. To achieve the above goals, 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 to ensure the integrity and confidentiality of the IVM guest by limiting which VM guest resources can be accessed by the host OS (and, in turn, the host virtualization stack).

[0016] In addition to these security benefits, in embodiments, the IVM architecture described herein provides the benefit of supporting existing guest OSes (e.g., without requiring changes to the guest OS kernel and boot loader). For example, in embodiments, existing guest OSes can be supported via heuristic OS drivers. Additionally, because it is software-based, the IVM architecture described herein is operable on existing computing hardware. Thus, for example, cloud providers can take advantage of the security benefits described herein without having to wait to develop or purchase new hardware systems designed with hardware-based VM guest isolation.

[0017] Figure 1 An example computer architecture 100 (e.g., including an IVM architecture) that facilitates software isolation of VM guest resources is shown. As shown, the computer architecture 100 includes hardware 101 (e.g., a computer system), which includes a processor 102 (e.g., a single processor or multiple processors), a memory 103 (e.g., a system 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 (e.g., stored on the storage medium 104, and / or stored on a dedicated memory device such as a read-only memory). Although not shown, the hardware 101 may also include other hardware devices, such as a trusted platform module (TPM) for facilitating measured boot features, a network interface (e.g., one or more network interface cards) for interconnecting with one or more other computer systems (via a network), (multiple) video display interfaces, (multiple) user input interfaces, and the like.

[0018] As shown, in the computer architecture 100, the hypervisor 107 is executed directly on the hardware 101. Typically, the hypervisor 107 partitions hardware resources (e.g., processor 102, memory 103, I / O resources) between the host partition 111 executing the host OS 116 and the guest partition 112 executing the guest OS 118 (or, as shown, multiple guest partitions). In the description herein, the term "VM guest" is used to refer to the "guest partition", and the term "IVM guest" is used to indicate when the VM guest is an isolated VM guest running in an isolated guest partition under the IVM architecture described herein. The hypervisor 107 also supports standardized communication between partitions through a bus 113 (e.g., a VM bus). As shown, the host OS 116 includes a virtualization stack 117, which calls the hypervisor 107 through one or more application program interfaces (APIs) to manage VM guest virtualization (e.g., memory management, VM guest life cycle management, device virtualization).

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

[0020] In computer architecture 100, host partition 111 is shown as including a higher trust zone 114 and a lower trust zone 115. Here, host OS 116 operates within lower trust zone 115, and security component 108 operates within higher trust zone 114; thus, in some embodiments, the functionality of security component 108 is partially or fully implemented within higher trust zone 114. In an embodiment, higher trust zone 114 is isolated from lower trust zone 115 based at least on mappings within SLAT table 109 that maps system physical addresses (SPA) to guest physical addresses (GPA) and mappings within an IOMMU translation table (IOMMU table 110). Thus, higher trust zone 114 (and security component 108) are isolated from lower trust zone 115 (and host OS 116 and software executed thereon, such as virtualization stack 117). In one example, the hypervisor 107 is a HYPER-V hypervisor and supports virtualization-based security (VBS) to subdivide partitions into virtual trust levels (VTLs), with a higher trust zone 114 operating under a more privileged VTL 0 and a lower trust zone 115 operating under a less privileged VTL 1.

[0021] In an embodiment, using security component 108, the IVM architecture introduces a new security boundary between the hypervisor 107 and the host OS 116. The new security boundary is shown using a thick line around the lower trust zone 115 and a thick line around the IOMMU 105. In an embodiment, due to the new security boundary, the only components of the computer architecture 100 within the virtualized trusted computing base (TCB) that the IVM guest relies on are the trusted firmware components in the firmware 106, the hypervisor 107, and the components in the higher trust zone 114 of the host partition 111 (if present). In an implementation using the HYPER-V stack and using WINDOWS as the host OS 116, the introduction of the new security boundary reduces the number of lines of code within the virtualized TCB by more than 95% - significantly reducing the potential attack surface. In addition to reducing the size of the virtualized TCB, the IVM architecture described herein also provides a well-defined and scoped security boundary between the virtualized TCB and the rest of the system. The security boundary is defensible and greatly simplifies the verification of the TCB of the virtualized host.

[0022] Consistent with this new security boundary, in computer architecture 100, hypervisor 107 and higher trust zone 114 (including components running therein, such as security component 108) are shown as trusted and within the virtualized TCB, while lower trust zone 115 (including components running therein, such as host OS 116 and virtualization stack 117) are shown as untrusted and outside the virtualized TCB. It is worth noting that in embodiments where host partition 111 lacks separation into higher trust zone 114 and lower trust zone 115 (and, therefore, security component 108 is implemented entirely within hypervisor 107), the entire host partition 111 will be located within the virtualized TCB. In either case, using this new security boundary, host OS 116 is considered untrusted and is located outside the virtualized host TCB. This provides a well-defined and defensible security boundary that strongly isolates IVM guests from host OS 116.

[0023] Additionally, the DMA device behind the IOMMU 105 is shown as being located outside the virtualized TCB, and the firmware 106 is shown as being partially located inside the virtualized TCB and partially located outside the virtualized TCB. In an embodiment, the number of firmware 106 located within the virtualized TCB varies based on whether the computer architecture 100 supports the dynamic root of trust for measurement (D-RTM). On a system utilizing D-RTM, the firmware components within the virtualized TCB can be limited to the microcode of the processor 102 and the firmware used for D-RTM startup. This is because D-RTM provides the ability to eliminate the basic input and output system (BIOS) and runtime firmware components from the virtualized TCB - including, for example, system management mode (SMM) and unified extensible firmware interface (UEFI) runtime services. On a system that does not support D-RTM, the BIOS and runtime firmware components can be located within the virtualized TCB.

[0024] In an embodiment, utilizing the IVM architecture described herein, the hypervisor 107 continues to conventionally allow the host OS 116 to control the allocation of control processors, memory, and I / O resources to the VM guest. This means that the host OS 116 is still responsible for managing the resource usage of the IVM guest, and the host OS 116 can use existing allocation policies to control how many computing resources the IVM guest receives. This also means that the host OS 116 can deny the IVM guest access to resources, and thereby prevent the IVM guest from executing normally, or completely prevent the IVM guest from executing. Therefore, under the IVM architecture, the host OS 116 still maintains control over the resource allocation between the hardware 101. However, with the new security boundaries introduced by the IVM architecture, the hypervisor 107 restricts the host OS 116 from reading or modifying the contents of the IVM guest state. This includes restricting the host OS 116 from accessing the contents of the virtual processor state of the IVM guest, and restricting the host OS 116 from accessing the memory contents of the IVM guest.

[0025] Figure 2 An example 200 of an IVM security component is shown, such as Figure 1 The security component 108 is provided. Figure 2 Each internal component of the security component 108 described in the Figures represents various functionalities that the security component 108 can implement according to various embodiments described herein. However, it should be understood that the described components, including their identities and arrangements, are merely represented as an aid in describing example embodiments of the security component 108. Notably, the internal components of the security component 108 can be distributed between the higher trust zone 114 and / or the hypervisor 107 in various ways.

[0026] In example 200, the security component 108 includes an attestation component 201. In an embodiment, the attestation component 201 provides attestation and key management functionality that enables a party operating the computer architecture 100 (host) to be completely removed from the TCB of the virtualization host. Because the virtualization stack 117 is untrusted, the virtualization stack 117 cannot be relied upon to ensure that the IVM guest is not tampered with before the IVM guest is launched. In addition, the guest OS 118 running inside the IVM guest cannot simply query the hypervisor 107 to determine whether it is securely launched because it can never guarantee that it is running on a secure host. Therefore, in order to securely launch the IVM guest, the remote server is responsible for attesting the launch of the IVM guest, and releasing the secrets of the IVM guest (e.g., encryption keys) to the software running inside the IVM guest. Thus, using the attestation component 201, a tenant operating an IVM guest is able to securely verify the authenticity and security of the virtualization host on which the tenant's IVM guest operates, and the tenant is able to release keys to the virtualization host, and be assured that a party operating the computer architecture 100 is unable to access the keys or read / modify the state of the IVM guest without being detected.

[0027] In example 200, security component 108 also includes processor state isolation component 202. Currently, various hypervisors are responsible for managing the processor state of VM guests and allow the host OS to read and modify the processor state of VM guests for the purpose of emulating devices. In an embodiment, processor state isolation component 202 completely isolates the processor state of the IVM guest from the host OS 116. In particular, processor state isolation component 202 prevents the host OS 116 from reading or writing registers of the IVM guest, including the instructions and stack pointers of the IVM guest.

[0028] In an embodiment, the processor state isolation component 202 also prevents the host OS 116 from setting intercepts for events that may result in the disclosure of sensitive 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 allows synthetic interrupts generated by the host OS 116 for the purpose of paravirtualized communication over the bus 113. However, the processor state isolation component 202 does not allow simulated interrupts or exceptions generated by the host OS 116 because allowing the host OS 116 the ability to generate simulated interrupts or exceptions would present an attack surface because the IVM guest is vulnerable to unexpected interrupts and exceptions at any point during its execution.

[0029] In example 200, security component 108 also includes memory isolation component 203. In an embodiment, memory isolation component 203 separates the memory of the IVM guest from the Figure 1 104. The memory isolation component 203 isolates the components outside the security boundary shown. This includes isolating the IVM guest's memory from the host OS 116, and from the DMA devices behind the IOMMU 105. Additionally, in an embodiment, the memory isolation component 203 protects the integrity of each IVM guest's GPA space (e.g., the address space that the IVM guest considers its own physical address space).

[0030] In the computer architecture 100, the host OS 116 is responsible for memory management (e.g., through the virtualization stack 117). Therefore, the host OS 116 is responsible for allocating physical memory for the IVM guest and assigning physical memory to the VM guest corresponding to the IVM guest (e.g., the guest partition 112). The host OS 116 also controls the GPA space for the IVM guest and determines the location of the mapping page in the GPA space of the IVM guest. However, in order to ensure the isolation and integrity of the IVM guest memory, the memory isolation component 203 enforces a set of rules on the host OS 116 when managing the IVM guest memory. In an embodiment, these rules revolve around memory access control (MAC) and GPA integrity control. Therefore, the memory isolation component 203 is shown to include a MAC component 204 and a GPA integrity control component 205. In an embodiment, the MAC component 204 provides facilities for controlling which parts of the memory that the host OS 116 can access for the IVM guest, and the GPA integrity control component 205 provides facilities that enable the IVM guest to always be ensured of the integrity of its GPA space.

[0031] Referring to the MAC component 204, the IVM architecture introduces the concept of memory page visibility categories for memory pages that have been assigned to the IVM guest. In an embodiment, the MAC component 204 records the host OS visibility for the memory page as one or more per-page host visibility attributes within the SLAT table 109. For memory pages mapped to the GPA space of the IVM guest, these (multiple) per-page host visibility attributes define the amount of access that the host OS 116 is allowed to each memory page. In an embodiment, these memory page visibility categories include exclusive memory, shared read-only memory, and shared read / write memory. In an embodiment, these memory page visibility categories define various attributes surrounding the accessibility and management of memory pages, including (multiple) host visibility attributes of memory pages.

[0032] With reference to exclusive memory, in an embodiment, exclusive memory is physical memory (e.g., within memory 103) that has been allocated by the host OS 116 for exclusive use by the IVM guest. Therefore, conceptually, the IVM guest can be considered to "own" any physical memory page that has been allocated to it as exclusive memory. In an embodiment, the IVM guest obtains full access privileges (e.g., read, write, and execute) to any physical memory page that has been allocated to it as exclusive memory. In an embodiment, the host OS 116 allocates physical memory to be used for the memory of the IVM guest, and then it issues one or more API calls to the hypervisor 107 to assign physical memory for use as the memory of the IVM guest. When the host OS 116 assigns a memory page to the IVM guest as exclusive, the MAC component 204 removes the host OS 116's access to the memory page. This ensures that the contents of the exclusive memory page of the IVM guest are not accessible by the host OS 116. Therefore, the host OS visibility cannot access the exclusive memory page for the IVM guest. In an embodiment, the MAC component 204 enforces host OS visibility by controlling the SLAT table 109 (e.g., host secondary page table) for the host OS 116 and the IOMMU table 110 for the DMA device. Thus, when the host OS 116 allocates a physical memory page and assigns it to an IVM guest for exclusive use by the IVM guest, the MAC component 204 updates the SLAT table 109 for the host OS 116 to prevent the host OS 116 from accessing the memory page, and updates the IOMMU table 110 to prevent the DMA device and its downstream consumers from accessing the memory page.

[0033] In an embodiment, the host OS 116 cannot regain ownership / control of the IVM guest's exclusive memory page until the memory page is successfully unmapped from the IVM guest's GPA space. In an embodiment, as part of unmapping the exclusive memory page from the IVM guest's GPA space, the MAC component 204 erases / clears the contents 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 an encryption key associated with the memory page).

[0034] In an embodiment, MAC component 204 enforces a set of rules to ensure the privacy and integrity of the exclusive memory. In an embodiment, these rules require that an IVM guest's exclusive memory pages are mapped / owned by only a single VM guest at a time, that an IVM guest's exclusive memory pages are mapped to only a single GPA of the IVM guest, that the contents of an IVM guest's exclusive memory pages are erased before the memory pages are released back to host OS 166, and that an IVM guest's exclusive memory pages are erased upon system reset (e.g., reset of the IVM guest).

[0035] As previously described, exclusive memory pages are not visible to the host OS 116 by default. However, in some cases, the guest OS 118 inside 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). To facilitate this, in an embodiment, the MAC component 204 allows the IVM guest to change the host visibility for exclusive memory pages on a page-by-page basis. In an example, the MAC component 204 exposes an API to the IVM guest that allows the IVM guest to call the hypervisor 107 to control the host visibility for its exclusive memory pages (e.g., via (multiple) calls from the guest heuristic 119, such as a driver operating in the guest OS 118). In an embodiment, when the IVM guest grants host visibility to an exclusive memory page, or removes host visibility from a 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 host OS 116 access to the memory page.

[0036] With reference to shared read-only memory, shared read-only memory is defined as a host OS 116 memory that is read-only to both the host and one or more VM guests. This makes shared read-only memory suitable for scenarios similar to direct mapping, in which the host OS 116 wishes to map a mirror page directly into one or more VM guests. In an embodiment, in order to map a shared read-only page into a VM guest, the host OS 116 first specifies the memory page as read-only by calling a call to notify the hypervisor 107. The host OS 116 then maps the memory page into the VM guest as a shared read-only page. In an embodiment, when the shared read-only memory page is mapped into the VM guest, the host OS 116 continues to have read access to the memory page. Therefore, 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 GAPs within the same VM guest.

[0037] With reference to shared read-write memory, shared read-write memory is defined as host OS 116 memory that is read-write to both host OS 116 and VM guests. Thus, shared read-write pages are always visible to the host for both read and write accesses, and the VM guest cannot change the host visibility attribute for shared read-write pages. It will be appreciated that the VM guest cannot make any assumptions about the contents of the shared read-write memory, as the host OS 116 can change the contents at any time. In an embodiment, the shared read-write memory is used by the host OS 116 to set up a memory region for sharing data between the VM guest and the host OS 116.

[0038] Referring to the GPA integrity control component 205, the GPA integrity control component 205 enables the IVM guest to have some guarantees around the integrity and actions of its GPA space. In order to ensure the integrity of the IVM guest's memory, the IVM architecture introduces the concept of "acceptance" for memory pages that are mapped into the IVM guest's GPA space. With this acceptance model, the IVM guest accepts memory pages before accessing them. In an embodiment, if the IVM guest attempts to access a memory page that it has not previously accepted, the hypervisor 107 generates a fault to the guest (e.g., on an X64 platform, the hypervisor 107 may generate a #VE exception).

[0039] In an embodiment, the IVM guest accepts a memory page by issuing one or more API calls (e.g., using guest heuristics 119) processed by the GPA integrity control component 205, specifying the GPA to be accepted and one or more attributes expected by the GPA (e.g., indicating the memory class it expects for the memory page at the GPA). 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 memory class, and marks the memory page as accepted (when the GPA meets the criteria of the indicated memory class) or not accepted (when the GPA does not meet the criteria of the indicated memory class). In an embodiment, the GPA integrity control component 205 marks the memory page as accepted or not accepted 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 accepted and a value of 0 indicates not accepted. Therefore, if the IVM guest expects a memory class to be mapped at a particular GPA, but the host OS 116 has actually mapped a different memory class, the accept operation will fail, resulting in the memory page being marked as not accepted. In an embodiment, hypervisor 107 prohibits host OS 116 from marking memory pages as accepted; therefore, only IVM guests, via GPA integrity control component 205 , can accept memory pages on their own behalf.

[0040] In an embodiment, GPA integrity control component 205 also prevents host OS 116 from maliciously remapping an IVM guest's page while the IVM guest is using the memory page, which could result in undetected corruption or unexpected behavior. For example, whenever host OS 116 changes which physical memory page is mapped to a GPA for an IVM guest, GPA integrity control component 205 sets the accepted state of the GPA memory page to not accepted. Thus, if host OS 116 attempts to remap a GPA from one SPA to a different SPA, GPA integrity control component 205 clears the accepted state of the memory page, and any future attempts by an IVM guest to access the GPA will result in a failure.

[0041] In view of the description herein, it will be appreciated that the memory acceptance model may not prevent the host OS 116 from maliciously modifying the GPA space of the IVM guest; however, the memory acceptance model ensures that the IVM guest is aware of any unauthorized changes to its GPA space. For example, the IVM guest may accept all of its addressable memory pages during boot and begin using its memory. Then, if the host OS 116 changes the SPA to GPA mapping for the IVM guest, the IVM guest will be notified that the next access to the GPA will generate a fault. In an embodiment, the acceptance model allows the IVM guest to collaborate with the host OS 116 when the acceptance model wishes to allow changes to occur in the IVM guest's GPA space for scenarios such as adding and removing memory.

[0042] In example 200, the security component 108 also includes a memory paging component 206. In an embodiment, memory paging is a special case where the IVM architecture allows the host OS 116 to change the GPA space of a running IVM guest without cooperating with the guest OS 118. To facilitate memory paging, the memory paging component 206 executes a defined paging flow in which the host OS 116 cooperates. In particular, the memory paging component 206 records integrity information (e.g., hashes, checksums) of the memory page contents during page outs, and then uses the integrity information to verify the contents of the memory page when the page is called in, which prevents the host OS 116 from maliciously modifying the page contents. In some embodiments, for example, when paging a host-invisible memory page (e.g., an exclusive memory page that is not visible to the host), the memory paging component 206 also encrypts the memory page contents during page outs, and decrypts the memory page contents of the page during page ins (e.g., using an encryption key specific to the IVM guest).

[0043] In some environments, when the VM guest boots, the host OS injects boot firmware (e.g., UEFI BIOS) into the memory of the VM guest to "boot" the OS in the VM guest. Therefore, for the guest OS in the VM guest, the boot process looks basically the same as the boot process on the physical machine, and the same OS boot loader as on the physical machine can be used in the VM guest. However, the IVM architecture described herein removes the host OS 116 from the TCB of the IVM guest, so the host OS 116 can no longer inject any firmware into the IVM guest because it is unsafe. In addition, the host OS 116 is not trusted to act as a root of trust for the startup of the IVM guest for proof purposes. The design principle of the IVM guest is that the tenant has full control over all codes running in the IVM guest. Therefore, in the IVM architecture described herein, the tenant has control over the firmware running inside its IVM guest. In addition, the IVM architecture provides the tenant with a method for verifying that the firmware loaded in its IVM guest is the correct firmware by measuring and proving the firmware.

[0044] In example 200, the 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 allows different models to be used to inject boot firmware into the IVM guest. In the first model, the tenant with the IVM guest relies on the host OS 116 to provide a known good boot firmware image. In order to ensure the security of this first model, the tenant needs to be sure that the boot firmware provided by the host OS 116 is a known good image and 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 allows tenants who want to rely on the provided boot firmware to audit the contents of the firmware and know exactly what is contained in the boot firmware image. In other embodiments, tenants with IVM guests provide their own boot firmware images that are used for IVM guests. In an embodiment, in order to distribute boot firmware, the defined boot firmware image format includes a binary firmware blob loaded into the memory of the IVM guest before the IVM guest is started, and metadata specifying the location of the boot firmware image that should be loaded, for example, in the GPA space of the IVM guest, and the offset of the location where execution should start in the boot firmware image.

[0045] Figure 3An example 300 of stages of an IVM guest life cycle is shown. As shown in the example 300, the IVM guest life cycle includes a stage 301 of creating an isolated guest partition (e.g., guest partition 112), wherein the virtualization stack 117 calls an API of the hypervisor 107 to create the guest partition 112 (IVM guest). During this initialization phase of the IVM guest, the virtualization stack 117 performs conventional steps for initializing the partition with the hypervisor 107, including allocating and assigning physical memory to the IVM guest. In view of the previous description of the MAC component 204 and the GPA integrity control component 205, all memory pages assigned to the IVM guest have not yet been accepted by the IVM guest, and therefore these memory pages are not yet accessible by the IVM guest.

[0046] The IVM guest life cycle also includes a stage 302 of obtaining the IVM guest boot firmware (e.g., boot firmware 120). As shown, no sequencing is required between stage 301 and stage 302. At stage 302, the virtualization stack 117 is provided with an initial boot firmware image for the IVM guest to be loaded into the memory. The initial boot firmware image includes a boot loader, which is the location where the IVM guest begins execution. The initial boot firmware image can be an image specified by the IVM guest owner, or a standard image provided by the host OS 116. This allows users to specify their own boot firmware image, or use a standard boot firmware image provided by a virtualization product or host.

[0047] The IVM guest lifecycle also includes a stage 303 of associating the IVM security component with the isolated guest partition. At stage 303, the virtualization stack 117 launches an instance of the security component 108 for the IVM guest and associates the instance with the IVM guest.

[0048] The IVM guest lifecycle also includes providing the IVM guest boot firmware to the IVM security component at stage 304. At stage 304, the virtualization stack 117 provides the boot firmware image to the security component 108 and specifies the location in the GPA space of the IVM guest where the boot firmware image should be loaded.

[0049] The IVM guest lifecycle also includes a stage 305 of copying the IVM guest boot firmware to the isolated guest memory. At stage 305, the firmware injection component 207 copies the boot firmware image to the appropriate location in the GPA space of the IVM guest (e.g., boot firmware 120). In connection therewith, the firmware injection component 207 (or the GPA integrity control component 205) changes the acceptance state of the GPA memory pages containing the boot firmware image to "accepted", thereby allowing the IVM guest to access these boot firmware image memory pages.

[0050] Once the boot firmware has been fully built, the virtualization stack 117 indicates to the hypervisor 107 that the IVM guest is now ready to begin execution. At this point, the virtualization stack 117 can no longer manipulate the configuration of the IVM guest or access the exclusive memory of the IVM guest.

[0051] The IVM guest lifecycle also includes a stage 306 of measuring the IVM guest configuration. At stage 306, the attestation component 201 measures the configuration of the IVM guest, including the initial boot firmware image of the IVM guest.

[0052] The IVM guest life cycle also includes a stage 307 of starting the IVM guest execution. At stage 307, the security component 108 starts the execution of the IVM guest when the initial boot loader of the IVM guest starts. Therefore, at this stage, the IVM guest is running. The only memory pages that the IVM guest can access are the memory pages that are initialized as part of the injected initial boot firmware image.

[0053] The IVM guest lifecycle also includes a stage 308 of managing the IVM guest memory page acceptance model. At stage 308, the IVM guest accepts the additional memory page using (multiple) API calls handled by the GPA integrity control component 205. In some embodiments, this involves the initial boot loader querying the host OS 116 for memory configuration information and then accepting the page based on the memory configuration of the IVM guest reported by the host OS 116. As noted in the description of the acceptance model, if there is a significant difference between what the host OS 116 reports and what the IVM guest is able to accept, then it will be detected during acceptance because the acceptance will fail.

[0054] Although not explicitly stated, when an IVM guest is stopped, its memory will be reclaimed from the hypervisor 107 by the virtualization stack 117. As part of the reclamation, the MAC component 204 will erase the contents of all IVM guest's exclusive memory pages before granting the host OS 116 access to the memory contents.

[0055] The operation of computer architecture 100 is now related to Figure 4 described, Figure 4 A flow chart of an example method 400 for isolating resources of a VM guest (e.g., guest partition 112) from a host OS (e.g., OS 116 within host partition 111) is shown. In an embodiment, instructions for implementing method 400 are encoded as computer executable instructions (e.g., security component 108) stored on a computer storage device (e.g., storage medium 104), which is executable by a processor (e.g., processor 102) to cause a computer system (e.g., hardware 101) to perform method 400.

[0056] The following discussion now relates to some methods and method actions. Although method actions may be discussed in a particular order, or may be shown in a flowchart as occurring in a particular order, no particular order is required unless otherwise specified, or a particular order is required because an action depends on another action being completed before the action is performed.

[0057] refer to Figure 4 , method 400 includes an act 401 of receiving a guest memory page accept request. In some embodiments, act 401 includes receiving an accept request from a guest partition corresponding to an isolated VM guest (IVM guest). In an embodiment, the accept request identifies (1) a guest memory page mapped into a GPA space of the guest partition, and (2) a memory page visibility category. In an example, the GPA integrity control component 205 receives an API call from a guest partition 112 (e.g., originating from a guest heuristic 119) requesting to accept a memory page (e.g., a GPA of a reference memory page) having a pre-expected memory page visibility category (e.g., exclusive visibility, shared read-only visibility, shared read-write visibility).

[0058] The method 400 also includes an act 402 of determining whether the mapped physical memory page satisfies the requested memory page visibility class. In some embodiments, the act 402 includes determining whether the physical memory page mapped to the guest memory page satisfies the memory page visibility class. In an example, the GPA integrity control component 205 determines the physical memory page mapped to the guest memory page indicated by the IVM guest, the memory page visibility class desired by the IVM guest, and whether the physical memory page satisfies the memory page visibility class.

[0059] As shown, action 402 includes action 403 when the memory page visibility class is exclusive visibility (for example, when the memory page visibility class is an exclusive visibility class), or action 406 when the requested memory page visibility class is shared visibility (for example, 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).

[0060] When the requested memory page visibility category is exclusive visibility (act 403), method 400 includes an act 404 of verifying guest exclusivity (via SLAT). In an embodiment, act 404 includes verifying, via one or more guest SLATs, that the physical memory page is exclusively mapped to the guest memory page. For example, as previously described, MAC component 204 implements a set of rules to ensure privacy and integrity of exclusive memory, including requiring that an exclusive memory page of an IVM guest is mapped / owned by only a single VM guest at a time (e.g., in SLAT table 109), and requiring that an exclusive memory page of an IVM guest is mapped to only a single GPA of the IVM guest (e.g., in SLAT table 109). Therefore, in some embodiments, for a physical memory page that is mapped to a requested guest memory page, GPA integrity control component 205 verifies that each of these conditions is true.

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

[0062] Although not in Figure 4 As shown in FIG. 4 , as previously described, the MAC component 204 can also enhance the host OS visibility to the memory page by controlling the IOMMU table 110 for the DMA device. Therefore, some embodiments of action 403 also include verifying via the host OS IOMMU table that the DMA device is denied access to the physical memory page.

[0063] As mentioned in the description of exclusive visibility, in some cases, 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, the MAC component 204 allows the IVM guest to change the host visibility for the exclusive memory pages on a per-page basis. Therefore, some embodiments of the method 400 also include receiving a visibility change request from the guest partition, the visibility change request including an indication of the guest memory page; and updating the host OS SLAT to grant the host OS access to the physical memory page.

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

[0065] Depending on the result of act 402, method 400 also includes an act 408 of accepting the memory page (when act 402 determines that the mapped physical memory page satisfies the requested memory page visibility class), or an act 409 of rejecting the memory page (when act 402 determines that the mapped physical memory page does not satisfy the requested memory page visibility class). In some embodiments, act 408 includes setting a page acceptance indication for the guest memory page from an unaccepted state to an accepted state based on the physical memory page mapped to the guest memory page satisfying the memory page visibility class. In some embodiments, act 409 includes setting a page acceptance indication for the guest memory page to a not accepted state based on the physical memory page mapped to the guest memory page not satisfying the memory page visibility class.

[0066] As a result of method 400, the IVM guest accepts physical memory pages mapped to the identified guest memory pages only if the physical memory pages satisfy the desired memory page visibility class. In this way, the IVM guest knows the security implications of using the identified guest memory pages, such as by knowing whether the contents of the guest memory page are exclusive to the IVM guest, or whether the contents of the guest memory page can be read and / or written by the host OS 116 and / or another VM guest. This provides the IVM guest with the ability to isolate its data from the host OS 116.

[0067] As previously described, the GPA integrity control component 205 prevents the host OS 116 from maliciously remapping the memory page of the IVM guest when the memory page is being used by the IVM guest. This protection is achieved by setting the accepted state of the memory page to unaccepted when the host OS 116 changes the physical memory page mapped by the GPA for the IVM guest. Therefore, in some embodiments, the method 400 also includes detecting that the guest memory page has been mapped to a different physical memory page; and setting the page acceptance indication for the guest memory page to an unaccepted state.

[0068] As previously described, in embodiments where an IVM guest attempts to access a memory page that was not previously accepted, the hypervisor 107 generates a fault into the guest (e.g., on an X64 platform, this may be a #VE exception). Thus, in some embodiments, the method 400 further includes, prior to receiving the accept request, detecting an access by a guest partition to an address covered by a guest memory page; and generating a page fault based on the page accept indication for the guest memory page being in a not accepted state.

[0069] As discussed, the memory paging component 206 performs a defined paging flow, wherein the memory paging component 206 records integrity information (e.g., hash, checksum) of the memory page content during a host OS 116 page out, and then uses the integrity information to verify the page content on a host OS 116 page in, thereby preventing the host OS 116 from maliciously modifying the page content. Thus, in some embodiments, the method 400 further includes, based on receiving a page out request from the host OS identifying the physical memory page, recording integrity information for the physical memory page content; and based on receiving a page in request from the host OS including an indication of the physical memory page, using the integrity information to verify the content of the physical memory page.

[0070] Additionally, as discussed, the memory paging component 206 may also encrypt the contents of the memory page during a page out, and decrypt the contents of the memory page of the page during a page in. Thus, in some embodiments, the method 400 further includes, based on receiving a page out request from the host OS, encrypting the contents of the physical memory page; and based on receiving a page in request from the host OS, decrypting the contents of the physical memory page.

[0071] As discussed, the firmware injection component 207 facilitates firmware injection within the IVM architecture. As discussed in stage 305 of the IVM guest lifecycle, the firmware injection component 207 copies the boot firmware image to the appropriate location in the GPA space of the IVM guest, and then the firmware injection component 207 (or the GPA integrity control component 205) changes the state of the GPA memory pages that include the boot firmware image to be accepted, thereby allowing the IVM guest to access these boot firmware image memory pages. Therefore, in some embodiments, the method 400 also includes, before receiving the acceptance request: within the GPA space, populating one or more guest memory pages with guest boot firmware; and for each memory page in the one or more guest memory pages, setting the corresponding page acceptance indication to an accepted state.

[0072] As discussed, in an embodiment, as part of unmapping an exclusive memory page from an IVM guest, the MAC component 204 erases the contents of the memory page (e.g., by zeroing the memory page, by writing a bit pattern to the memory page, by writing random bits to the memory page, by deleting an encryption key associated with the memory page). Thus, in some embodiments, the method 400 further includes erasing the contents of the physical memory page based on at least one of: the guest memory page is released to the host OS; or the isolated VM guest is shut down.

[0073] As discussed, processor state isolation component 202 completely isolates the processor state of the IVM guest from host OS 116 by preventing host OS 116 from reading or writing registers of the IVM guest (e.g., including the IVM guest's instructions and stack pointer). Therefore, in some embodiments, method 400 also includes isolating the contents of one or more processor registers from the host OS.

[0074] Embodiments of the present disclosure may include or utilize a dedicated or general-purpose computer system that includes computer hardware (e.g., hardware 101), such as one or more processors (e.g., processor 102) and system memory (e.g., memory 103), as discussed in more detail below. 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 dedicated computer system. A computer-readable medium that stores computer-executable instructions and / or data structures is a computer storage mechanism (e.g., storage mechanism 104). A computer-readable medium that carries computer-executable instructions and / or data structures is a transmission medium. Therefore, as an example, embodiments of the present disclosure may include at least two distinctly different types of computer-readable media: a computer storage device and a transmission medium.

[0075] Computer storage is a physical storage medium that stores 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 hardware storage device(s) that can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[0076] Transmission media can include networks and / or data links, which can be used to carry program code in the form of computer executable instructions or data structures, and can be accessed by general or special computer systems."Network" is defined as one or more data links, which enable electronic data to be transmitted between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system through a network or another communication connection (or a combination of hardwire, wireless or hardwire or wireless), the computer system can be considered as a transmission medium by the connection. The above combination should also be included in the scope of computer-readable media.

[0077] 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 the transmission medium to the computer storage device (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 the computer system RAM and / or a less volatile computer storage device at the computer system. Therefore, it should be understood that the computer storage device can be included in a computer system component that also (or even primarily) utilizes a transmission medium.

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

[0079] Should be understood that disclosed system and method can be implemented in the network computing environment with many types of computer system configurations, including personal computers, desktop computers, notebook computers, message processors, handheld devices, multiprocessor systems, based on microprocessor 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 implemented in a distributed system environment, wherein the local and remote computer systems connected by the network (or by a hardwired data link, a wireless data link, or by a combination of a hardwired and wireless data link) all perform tasks. Therefore, in a distributed system environment, the computer system can include multiple component computer systems. In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0080] It should also be recognized that embodiments of the present disclosure can be implemented in a cloud computing environment. The cloud computing environment can be distributed, although this is not required. In a distributed case, the cloud computing environment can be distributed internationally within an organization, and / or have components owned across multiple organizations. In this specification and the following claims, "cloud computing" is defined as a model that allows on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The cloud computing model can consist of various features, such as on-demand self-service, extensive network access, resource pools, rapid elasticity, customized services, and the like. The cloud computing model can 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). The cloud computing model can also be deployed using different deployment models, such as private clouds, community clouds, public clouds, hybrid clouds, and the like.

[0081] Some embodiments, such as cloud computing environments, may include a system including one or more hosts, each of which is capable of running one or more virtual machines. During operation, the virtual machine simulates an operational computing system, supporting an OS and possibly one or more other applications. In some embodiments, each host includes a hypervisor that simulates virtual resources for the virtual machine using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only interfacing with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, and the like.

[0082] 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 described features or the acts described above, or the order of the acts described above. Instead, the described features and acts are disclosed as example forms of implementing the claims.

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

[0084] When introducing elements in the appended claims, the articles "a", "an", "the", and "said" are intended to mean that there are one or more elements. The terms "comprising", "including", and "having" are intended to be all-inclusive and mean that there may be additional elements in addition to the listed elements. Unless otherwise stated, the terms "set", "superset", and "subset" are intended to exclude empty sets, so 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 stated, the term "subset" excludes all of its supersets (i.e., the superset includes 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 for isolating resources of a virtual machine (VM) guest from a host operating system (OS), the method being implemented at a computer system including a processor, the method comprising: Receiving an accept request from a guest partition corresponding to an isolated VM guest, the accept request identifying: guest memory pages mapped into a guest physical address (GPA) space of the guest partition, and Memory page visibility class; as well as Based on a physical memory page mapped to the guest memory page satisfying the memory page visibility class, a page accept indication for the guest memory page is set from a never accepted state to an accepted state.

2. The method according to claim 1, further comprising: detecting that the guest memory page has been mapped to a different physical memory page; as well as The page acceptance indication for the guest memory page is set to the not accepted state.

3. The method of claim 1 , further comprising, before receiving the acceptance request: detecting access by the guest partition to an address covered by the guest memory page; and A page fault is generated based on the page accept indication for the guest memory page being the not accepted state.

4. The method of claim 1 , further comprising, before receiving the acceptance request: populating guest memory pages within the GPA space using guest boot firmware; and The corresponding page acceptance indication is set to the accepted state.

5. The method according to claim 1, wherein: The memory page visibility class is an exclusive visibility class; as well as The method further includes determining that the physical memory page satisfies the memory page visibility class, comprising: verifying, via one or more guest second-level address translation tables (SLATs), that the physical memory page is exclusively mapped to the guest memory page; as well as The host OS is verified via the host OS SLAT to be denied access to the physical memory page.

6. The method according to claim 5, further comprising: A direct memory access device is verified via a host OS input / output memory management unit table to be denied access to the physical memory page.

7. The method according to claim 5, further comprising: receiving a visibility change request from the guest partition, the visibility change request including an indication of the guest memory page; as well as The host OS SLAT is updated to grant physical memory page access to the host OS.

8. The method according to claim 1, wherein: The memory page visibility class is a shared read-only visibility class; and The method also includes determining that the physical memory page satisfies the memory page visibility class, including verifying via a host OS secondary address translation table that the host OS is granted read-only access to the physical memory page.

9. The method according to claim 1, wherein: The memory page visibility category is a shared read-write visibility category; as well as The method also includes determining that the physical memory page satisfies the memory page visibility class, including verifying via a host OS secondary address translation table that the host OS is granted read and write access to the physical memory page.

10. The method according to claim 1, further comprising: The contents of the physical memory page are erased based on at least one of: The guest memory page is released to the host OS; or The isolated VM guest is shut down.

11. The method according to claim 1, further comprising: recording integrity information for content of the physical memory page based on receiving a page out request from the host OS that identifies the physical memory page; as well as Based on receiving a page-in request from the host OS including an indication of the physical memory page, the contents of the physical memory page are verified using the integrity information.

12. The method according to claim 11, further comprising: encrypting the content of the physical memory page based on receiving the page out request from the host OS; as well as Based on receiving the page-in request from the host OS, the contents of the physical memory page are decrypted.

13. The method according to claim 1, further comprising: The contents of one or more processor registers are isolated from the host OS.

14. A computer system for isolating resources of a virtual machine (VM) guest from a host operating system (OS), comprising: processor, and a computer storage device storing computer executable instructions executable by the processor to at least cause the computer system to: Receiving an accept request from a guest partition corresponding to an isolated VM guest, the accept request identifying: guest memory pages mapped into a guest physical address (GPA) space of the guest partition, and Memory page visibility class; as well as Based on a physical memory page mapped to the guest memory page satisfying the memory page visibility class, a page accept indication for the guest memory page is set from a never accepted state to an accepted state.

15. The computer system of claim 14, wherein the computer executable instructions further comprise the following instructions, the instructions being executable by the processor to at least cause the computer system to: detecting that the guest memory page has been mapped to a different physical memory page; and The page acceptance indication for the guest memory page is set to the not accepted state.

Images