Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see pages 7-10, filed 05/04/2026, with respect to the rejection(s) of claim(s) 1-20 under Hu in view of VMWare have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made over Dong in view of Li (see .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: 245. Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dong et al (US 20110153909-A1), hereinafter Dong, and further in view of Shih-Wei Li et al ("Protecting Cloud Virtual Machines from Hypervisor and Host Operating System Exploits", 2019), hereinafter Li.
Regarding claim 1, Dong teaches:
A method comprising: running, by a host computer system, a hypervisor managing a first virtual machine, wherein the first virtual machine manages a second virtual machine; (See e.g., page [06], paragraph [012], “FIG. 1 includes a block schematic diagram of a conventional layered nested virtualization environment. For example, system 100 includes layer 0 (L0) 115, layer 1 (L1) 110, and layer 2 (L2) 105. VM1 190 and VM2 195 are both located "on" or executed "with" L0 VMM 130. VM1 190 includes application Apps1 120 supported by guest operating system OSI 125. VM2 195 "includes" L1 VMM 160. Thus, system 100 is a nested virtualization environment with, for example, L1 VMM 160 located on or "nested" in L0 VMM 130. L1 VMM 160 is operated "with" lower layer L0 VMM 130. L1 VMM 160 "supports" guest VM20 196 and guest VM21 197, which are respectively running OS20 170/Apps20 180 and OS21 175/Apps21 185.”) The claimed invention uses the virtual machine to manage another virtual machine, performing the functions of a secondary hypervisor.
receiving, by the hypervisor, from a virtual device, a first request to perform a memory access operation with respect to a memory page of the second virtual machine; (See e.g., page [07], paragraph [016], “Arrow 3 leads to L1 VMM 215 (parent of L2 guest 205), which emulates an entity (e.g., guest, operation, event, device driver, device, and the like) such as L2 guest 205 I/O behavior using, for example, any of device model 220, a backend driver complementary to a paravitualized guest device's frontend driver, and the like. Device modeling may help the system interface with various device drivers. For example, device models may translate a virtualized hardware layer/interface from the guest 205 to the underlying devices. The emulation occurs like a normal single layer (non-nested) privileged resource access but with nested virtualization the I/O event (e.g., request) is first trapped by L0 VMM 210, and then L0 VMM 210 bounces the event into L1 VMM 215 if L1 VMM 215 is configured to receive the event. L1 VMM device model 220 may maintain a virtual state (vState) 225 per guest and may ask an L1 OS for I/O event service in a manner similar to what happens with single layer virtualization.”)
and responsive to detecting, by the hypervisor, a page fault with respect to the memory page, performing, by the hypervisor, the memory access operation with respect to the memory page of the second virtual machine. (see e.g., page [08], paragraph [033-035], The TDT register may be a Memory Mapped I/O (MMIO) register but may also be, for example, a Port I/O. L1 VMM 360 may not have direct translation for the MMIO address, which may allow L1 VMM 360 to trap and emulate the guest MMIO access through an exit event (e.g., Page Fault (#PF) VM Exit). Consequently, L0 VMM 330 may not have the translation for the MMIO address, which emulates L1 VMM translation.
In line 14 the access of TDT register triggers a VM Exit (#PF). L0 VMM 330 may obtain the linear address of the #PF (e.g., MMIO access address such as 12_gva) from VM Exit information. In line 15 L0 VMM 330 may walk or traverse the L2 guest page table to convert 12_gva to its L2 guest physical address (e.g., 12_gpa). The L2 guest page table walk or traversal may start from the L2 guest physical address pointed by L2 guest CR3 (e.g., 12_vcr3).
In line 16 L0 VMM 330 may determine whether 12_gpa is an accelerated I/O (i.e., I/O emulation may bypass L1 VMM 215). If 12_gpa is an accelerated I/O then, in line 17, L0 VMM may perform an emulation based on the shared virtual NIC and CPU state information (e.g., vm20_vepro1000_state and vm20-vCPU-state). In line 18 L0 VMM 330 may fetch the L2 virtual NIC device DMA descriptor and perform a translation with the L2_to_L0_p2m table to convert the 12 guest physical address to a real machine physical address. In line 19 L0 VMM 330 may have the transmission payload and transmit the payload in the L0 Host I/O. L0 VMM 330 may also update the vm20_vepro1000_state and vm20-vCPU-state in the shared data. In line 20 the L2 guest may resume.”)
Dong fails to explicitly teach:
responsive to determining, by the hypervisor, that the memory page of the second virtual machine is unavailable in a memory of the first virtual machine, forwarding the first request to the first virtual machine;
However, Li teaches:
responsive to determining, by the hypervisor, that the memory page of the second virtual machine is unavailable in a memory of the first virtual machine, forwarding the first request to the first virtual machine; (see e.g., page [05], paragraph [002], “HypSec ensures that any password or secret used to decrypt the VM disk is not exposed to the hostvisor. Common encrypted disk formats [6,57] use user-provided passwords to protect the decryption keys. HypSec can store the encrypted key files locally or remotely using a cloud provider’s key management service (KMS) [5,58]. The KMS maintains a secret key which is preloaded by administrators into hosts’ TEE secure storage. The corevisor decrypts the encrypted key file using the secret key, and maps the resulting password to VM memory, allowing VMs to obtain the password without exposing it to the hostvisor. The same key scheme is used for VM migration; HypSec encrypts and decrypts the VM state using the secret key from the KMS.”) Applicant’s specification paragraph [047] explains that encrypted memory is unavailable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the system for efficiently running nested virtualization as taught by Dong with the method to prevent exploits on nested virtualization as taught by Li. This modification would be motivated, with a reasonable expectation of success, by a want to retrofit an existing hypervisor to reduce the vectors of attack available (by reducing the amount of “trusted” computing space). See Li, page [02], paragraph [04].
Regarding Claim 2, Dong recites:
The method of claim 1, wherein responsive to detecting the page fault, the hypervisor causes the first virtual machine to make the memory page available in the memory of the first virtual machine. (see e.g., page [08], paragraph [033-034], The TDT register may be a Memory Mapped I/O (MMIO) register but may also be, for example, a Port I/O. L1 VMM 360 may not have direct translation for the MMIO address, which may allow L1 VMM 360 to trap and emulate the guest MMIO access through an exit event (e.g., Page Fault (#PF) VM Exit). Consequently, L0 VMM 330 may not have the translation for the MMIO address, which emulates L1 VMM translation.
[0034] In line 14 the access of TDT register triggers a VM Exit (#PF). L0 VMM 330 may obtain the linear address of the #PF (e.g., MMIO access address such as 12_gva) from VM Exit information. In line 15 L0 VMM 330 may walk or traverse the L2 guest page table to convert 12_gva to its L2 guest physical address (e.g., 12_gpa). The L2 guest page table walk or traversal may start from the L2 guest physical address pointed by L2 guest CR3 (e.g., 12_vcr3).”)
Regarding Claim 3, Li recites:
The method of claim 1, further comprising: maintaining, by the hypervisor, a memory page list, wherein the memory page list comprises a plurality of records, wherein each record of the plurality of records specifies an address of a particular memory page of the second virtual machine, wherein the particular memory page is available in the memory of the first virtual machine. (See e.g., page [10], paragraph [001], “The corevisor allocates hNPTs and VMs’ sNPTs from its protected physical memory and manages the page tables.”) (“See also e.g., page [06], paragraph [06], The hostvisor is only allowed to manage its own page tables (Host PT) and can only translate from host virtual memory addresses (hVAs) to what we call virtualized host physical memory addresses (vhPAs). vhPAs are then in turn translated to hPAs by the Host Nested Page Table (hNPT) maintained by the corevisor.”) The Host Nested Page Table is a page table maintained by the corevisor, which holds records available in the hostvisor. In addition, the vhPA is allocated by the corevisor to VMs.
Regarding Claim 4, Li recites:
The method of claim 3, wherein determining that the memory page of the second virtual machine is not available in the memory of the first virtual machine further comprises: determining that the memory page of the second virtual machine does not match any record of the plurality of records in the memory page list. (See e.g., page [07], paragraph [02] “When a guest OS tries to map a gVA to an unmapped gPA, a nested page fault occurs which traps to the corevisor (step 1). If the corevisor finds that the faulted gPA falls within a valid VM memory region, it then points the NPT Base Register to hNPT(step 2) and switches to the hostvisor to allocate a physical page for the gPA (step 3). The hostvisor allocates a virtualized physical page identified by a vhPA and updates the entry in its vNPT corresponding to the faulting gPA with the allocated vhPA.”) If the gPA is unmapped, that can be considered an “unavailable memory page” as there isn’t a record of it in the physical memory addresses (hence it being unmapped).
Regarding Claim 5, Dong recites:
The method of claim 1, wherein the virtual device is directly controlled by the hypervisor. (See e.g., page [08], paragraph [033], “In line 9 L1 VMM 360 may request to communicate with L0 VMM 330 (e.g., through hypercall H1 or other communication channel) to share a virtual guest state of the NIC device (e.g., vm20_vepro1000_state) and/or CPU. A guest virtual CPU or processor state may include, for example, vm20-vCPU-state, which may correspond to a L2 virtual control register (CR) CR3 such as 12_vCR3 of VM20 396. State information may be shared through, for example, shared memory where both L1 VMM and L0 VMM can see shared states and manipulate those states.”) The virtual NIC device is being considered as the virtual device.
Regarding Claim 6, Li recites:
The method of claim 3, wherein the virtual device is not directly controlled by the hypervisor, and wherein detecting the page fault further comprises: sending the memory page list to the virtual device; and receiving the page fault from the virtual device. (See e.g., page [08], paragraph [01], “Hypervisors provide a virtual interrupt controller interface and trap and emulate VM access to the interface. Virtual devices in the hypervisors can also raise interrupts to the interface.”) This shows both a virtual device not being controlled (by raising its own interrupts instead of being told to do so) and a virtual device being hat provides the interrupt (e.g., page fault) to the hypervisor.
Regarding Claim 7, Dong recites:
The method of claim 1, wherein detecting the page fault causes the first virtual machine to trigger the page fault to load the memory page from a backing store to the memory of the first virtual machine. (See e.g., page [08], paragraph [033], “The TDT register may be a Memory Mapped I/O (MMIO) register but may also be, for example, a Port I/O. L1 VMM 360 may not have direct translation for the MMIO address, which may allow L1 VMM 360 to trap and emulate the guest MMIO access through an exit event ( e.g., Page Fault (#PF) VM Exit). Consequently, LO VMM 330 may not have the translation for the MMIO address, which emulates L1 VMM translation.”) If a memory register is missing, L1 will trigger an exit event (a page fault) which causes it to load (trap) memory information so it can be “translated” by the L1 VMM.
Regarding Claim 8, Li teaches:
The method of claim 1, wherein determining that the memory page of the second virtual machine is unavailable further comprises determining that the memory page is encrypted. (See e.g., page [03], paragraph [03], “We assume VMs use end-to-end encrypted channels to protect their I/O data.”)(See also e.g., page [05], paragraph [02], “The corevisor decrypts the encrypted key file using the secret key, and maps the resulting password to VM memory, allowing VMs to obtain the password without exposing it to the hostvisor.”)
Regarding Claim 9, Dong recites:
The method of claim 8, wherein detecting the page fault causes the first virtual machine to trigger the page fault (See e.g., page [08], paragraph [033], “The TDT register may be a Memory Mapped I/O (MMIO) register but may also be, for example, a Port I/O. L1 VMM 360 may not have direct translation for the MMIO address, which may allow L1 VMM 360 to trap and emulate the guest MMIO access through an exit event ( e.g., Page Fault (#PF) VM Exit). Consequently, LO VMM 330 may not have the translation for the MMIO address, which emulates L1 VMM translation.”)
Li recites: [an interrupt from L0 causes L1] to unencrypt the memory page. (See e.g., page [07], paragraph [05], “The hostvisor uses GET VMSTATE to get access to the encrypted VM page before swapping it out. Later, when the VM page is swapped in, the corevisor unmaps the swapped-in page from hNPT, decrypts the page, and maps it back to the VM’s sNPT.”) The two references do describe the individual parts stated. Dong recites that page fault detected causes the L1 to handle the page fault. Li recites that interrupts, like a page fault, can be used to gain access to information that wouldn’t usually be there, and then decrypts the memory before putting it back.
Regarding Claim 10, Li recites:
The method of claim 8, wherein detecting the page fault is performed responsive to the first virtual machine triggering the page fault to unencrypt the memory page. (See e.g., page [04], paragraph [03], “While the hostvisor has no access to VM data in CPU or memory, it may request the corevisor to provide an encrypted copy of VM data via the GET VM STATE hypercall API.”) (See e.g., page [07], paragraph [05], “The hostvisor uses GET VMSTATE to get access to the encrypted VM page before swapping it out. Later, when the VM page is swapped in, the corevisor unmaps the swapped-in page from hNPT, decrypts the page, and maps it back to the VM’s sNPT.”) The hostvisor (L1 equivalent) sends the request for the encrypted page. The request is received (the equivalent of detecting the page fault), and the page is grabbed, unencrypted, and provided to its destination.
Regarding Claim 11, Dong in view of Li recites:
A system comprising: a memory device; a processing device operatively coupled to the memory device, to perform operations comprising: the method of claim 1. Therefore, it is rejected as being unpatentable over Dong in view of Li for the same reasons provided for claim 1.
Claims 12-16 recite substantially the same limitations as claims 2-6 respectively, applied to the independent claim 11. Therefore, claims 12-16 are rejected as being unpatentable over Dong in view of Li for the same reasons provided for claims 2-6 respectively.
Regarding Claim 17, Dong in view of Li recites:
A non-transitory machine-readable storage medium including instructions that, when accessed by a processing device, cause the processing device to perform operations comprising: the method of claim 1. Therefore, it is rejected as being unpatentable over Dong in view of Li for the same reasons provided for claim 1.
Claims 18-20 recite substantially the same limitations as claims 2-4 respectively, applied to the independent claim 17. Therefore, claims 18-20 are rejected as being unpatentable over Dong in view of Li for the same reasons provided for claims 2-4, respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at (571) 270 - 3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.I.B./ Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights