DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication filed on 10/24/2024.
Status of claims in the instant application:
Claims 1-20 are pending.
Priority
This application claims benefit of 63/592,916 filed on 10/24/2023.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 01/21/2025, 05/10/2025 and 02/05/2026 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 10/24/2024 have been inspected, and it’s in compliance with MPEP 608.02.
Specification
Specification filed on 10/24/2024 has been inspected and it’s in compliance with MPEP 608.01.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
Claims 1 and 14 recites, “A system comprising: … a virtual machine monitor configured to virtualize the physical computer hardware of …”
Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Examiner has investigated the disclosure of the instant (Published US 20250130958 A1) application and finds the following for the place holder term (a virtual machine monitor) identified above:
Para [0057]: The virtual machine monitor 104 is a software and/or hardware component that virtualizes the physical computer hardware of the hardware platform 102. The virtual machine monitor 104 allocates and manages physical resources of the hardware platform 102 to run one or more virtualized instances of a computer (i.e., virtual machines) on the hardware platform 102. The underlying computing device(s) (e.g., the hardware platform 102) utilized by a virtual machine monitor to instantiate virtual machines is often referred to as a “host.” In contrast, an individual virtual machine instantiated using the hardware platform 102 is often referred to as a “guest.” In the context of the system 100, the virtual machine monitor 104 allocates and manages physical resources of the hardware platform 102, such as the processing unit 114, the embedded security processor 116, the memory 118, and/or the memory controller 120 to instantiate and/or manage one or more virtual machines. A virtual machine monitor is also referred to as a “hypervisor,” examples of which are a Type 1 Hypervisor (e.g., a bare-metal hypervisor) and a Type-2 Hypervisor (e.g., a hosted hypervisor).
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f), applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1 and 13 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 8 of copending Application No. 18/926095 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims if the instant application are just a broader version of the claims of the reference application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Reference Application (18/926095)
1. A system comprising: a hardware platform comprising physical computer hardware, the physical computer hardware including at least one compute unit and at least one memory; a virtual machine monitor configured to virtualize the physical computer hardware of the hardware platform to instantiate a plurality of framework-secure virtual machines; and a root framework-secure virtual machine instantiated by the virtual machine monitor, the root framework-secure virtual machine configured to control access to the at least one memory by the plurality of framework-secure virtual machines.
1. A system comprising: a hardware platform comprising physical computer hardware, the physical computer hardware including one or more processing units and one or more memories; a virtual machine monitor configured to virtualize the physical computer hardware of the hardware platform to instantiate a plurality of framework-secure virtual machines; and a root framework-secure virtual machine instantiated by the virtual machine monitor, the root framework-secure virtual machine configured to control access to the hardware platform by the plurality of framework-secure virtual machines instantiated by the virtual machine monitor.
13. The system of claim 1, wherein the root framework-secure virtual machine is configured to execute at least one command, on behalf of the plurality of framework-secure virtual machines, that involves access to a memory page that is private to at least one of the plurality of framework-secure virtual machines.
8. The system of claim 1, wherein the one or more memories include an isolated memory region that is accessible to the root framework-secure virtual machine and inaccessible to the plurality of framework-secure virtual machines.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 6-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20160299851 A1 to Mattson et al. (hereinafter “Mattson”) in view of Pub. No.: US 20140380009 A1 to Lemay et al. (hereinafter “Lemay”).
Regarding Claim 1. Mattson discloses a A system (Mattson, Abstract, FIG. 1: … A hypervisor provides a guest operating system with a plurality of protection domains, including a root protection domain and one or more secure protection domains, and mechanisms for controlling the transitions between the protection domains …) comprising:
a hardware platform comprising physical computer hardware, the physical computer hardware including at least one compute unit and at least one memory (Mattson, Para [0042]: … The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like … One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media …);
a virtual machine monitor configured to virtualize the physical computer hardware of the hardware platform to instantiate a plurality of framework-secure virtual machines (Mattson, Para [0014, 0017, 0027, 0029], Claim 19, FIG. 2: … In FIG. 1, the virtualized host server system is depicted as host 100. Host 100 is built on an underlying hardware computing platform comprising one or more computer systems, each of which may be a desktop computer, laptop computer, tablet computer, mobile device such as a smart phone, server grade computer system, or any other suitable hardware computing platform, including systems based on different variations of the well-known ARM or x86 architecture platforms. Host 100 is configured to execute virtualization software 114 that provides execution support for one or more guest virtual machines (VMs) 120 … virtualization software 114 includes virtual machine monitors (VMMs) 149, which operate in the privileged context of virtualization software 114 and provide the virtual system support, such as emulated physical devices (e.g., virtual CPUs and virtual system memory), for their respective VMs …); and
a root framework-secure virtual machine instantiated by the virtual machine monitor (Mattson, Para [0025, 0027, 0029], Claim 19, FIG. 2: … The conceptual diagram depicted in FIG. 2 illustrates a simplified embodiment where one virtual CPU for VM 120 is executing in the secure protection domain or the root protection domain. However, in the embodiments, multiple virtual CPUs support execution of VM 120, and one or more virtual CPUs may be executing in the secure protection domain while one or more other virtual CPUs are executing in the root protection domain … secure NPTs 221 and root NPTs 222 are created from original NPTs that provided a complete mapping from the guest physical memory to the host physical memory … all data that are stored in secure protection domain region 230 are not mapped in the root protection domain and are only accessible to code executing in the secure protection domain such as GI driver 139. As such, confidential information can be stored in secure protection domain region 230 …), [the root framework-secure virtual machine configured to control access to the at least one memory by the plurality of framework-secure virtual machines].
However, Mattson does not explicitly teach, but Lemay from same or similar field of endeavor teaches:
“the root framework-secure virtual machine configured to control access to the at least one memory by the plurality of framework-secure virtual machines (Lemay, Para [0021, Claim 36]: … VMM module 106 (also referred to as a hypervisor) provides management and/or hosting of one or more VM guests 108a, 108b . . . 108n. VMM 106 executes in VMX root mode which is the highest privileged mode associated with processor 102. VM guests 108 execute in modes of lower privilege (i.e., non VMX root mode) which may include, for example, ring 0 (or supervisor) mode and ring 3 (or user) mode. Ring 0 privilege mode is a reduced privilege mode relative to VMX root mode (i.e., the privilege mode associated with the VMM) and ring 3 privilege mode is yet a further reduced privilege mode relative to ring 0 mode … Although VM guests may share the same host physical memory, the VMM protects the physical memory through EPT based mappings between guest physical memory addresses and host physical memory addresses. The EPTs provide a second layer of paging structures (below the conventional OS page table layer) that are controlled by the VMM as illustrated and described in greater detail in connection with FIG. 6 below. VM guests may be configured to provide an EPT editor view, as will also be described in greater detail below. The EPT editor enables secure access to and modification of selected EPTs (and thus access to memory views associated with those EPTs) to trusted guest software executing in ring 0 mode, for example guest OS kernel components, without requiring a transition to VMX root mode through relatively less efficient VM calls and VM exits. This may improve the performance of applications that require larger or more frequent EPT modifications …).”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lemay into the teachings of Mattson, because it discloses that, “The performance improvements provided by the EPT editor may allow for the application of views to monitor and restrict access to sensitive data and regions of the computer system, such as, for example, memory mapped I/O (MMIO) regions (and the devices associated therewith), page tables and the Windows.TM. registry. The application of views to MMIO access may be used to protect sensor inputs and actuator outputs of the computer system, providing for more secure I/O. Improved anti-malware systems may be implemented based on these capabilities (Lemay, Para [0025])”.
Regarding Claim 2. The combination of Mattson-Lemay discloses the system of claim 1, Mattson further discloses, “wherein the at least one memory includes a guest page table that includes a plurality of entries, each of the plurality of entries corresponding to at least one memory page loaded by the root framework-secure virtual machine or one of the plurality of framework-secure virtual machines (Mattson, FIG. 2, Para [0023, 0027]: … IG. 2 is a schematic diagram of memory mappings employed in the embodiments to isolate a secure protection domain from the root protection domain. In FIG. 2, multiple memory mappings are shown but they can be divided into two types. The first type, labeled as gV.fwdarw.gP mapping, is a mapping from the guest virtual memory space to the guest physical memory space. The gV.fwdarw.gP mapping is managed by guest OS 132 and is encoded in guest page tables (gPTs). As in physical computer systems, the guest page tables are provided per process in the embodiments. The second type, labeled as gP.fwdarw.hP mapping, is a mapping from the guest physical memory space to the host physical memory space. The gP.fwdarw.hP mapping is managed by virtualization software 114, in particular VMM 149, and is encoded in nested page tables (NPTs) (also known as “extended page tables”) … On the other hand, if the validation at step 314 is successful, at step 318, secure NPTs 221 and root NPTs 222 are created from original NPTs that provided a complete mapping from the guest physical memory to the host physical memory. In particular, the mappings of guest physical memory addresses corresponding to the executable code and data regions of GI driver 139 are moved into the secure NPTs 221 and the other mappings are moved into the root NPTs 222. In addition, at step 320, secure guest page tables are created from original guest page tables and stored in secure protection domain region 230. In particular, the original guest page table entries that point to guest physical memory pages that are mapped by secure NPTs 221 to secure protection domain region 230 are moved into secure guest page tables, shown in FIG. 2 as gPTs 233 …).”
Regarding Claim 6. The combination of Mattson-Lemay discloses the system of claim 1, Mattson further discloses, “wherein the at least one memory includes a nested page table that includes a plurality of entries, each of the plurality of entries mapping a guest physical address to a system physical address for a memory page Mattson further discloses (Mattson, Para [0012]: … According to one or more embodiments, the hypervisor provides the guest operating system with a plurality of protection domains, including a root protection domain and one or more secure protection domains, and mechanisms for controlling the transitions between protection domains. The guest physical memory region of a secure protection domain, which is mapped to host physical memory by secure nested page tables, stores secure guest code (e.g., guest introspection driver code) and data, and guest page tables for the secure guest code. When executing secure guest code, the guest page tables stored in the secure protection domain region are used for guest virtual to guest physical address translations, and the secure nested page tables are used for guest physical to host physical address translations …).”
Regarding Claim 7. The combination of Mattson-Lemay discloses the system of claim 6, Lemay further discloses, “wherein the at least one compute unit walks the nested page table to identify the system physical address for the memory page in response to a request from the root framework-secure virtual machine to access the memory page, wherein the memory page is a private memory page of the root framework-secure virtual machine (Lemay; Abstract, Claim 30: … this disclosure provides systems, methods and computer readable media for a protected memory view in a virtual machine (VM) environment enabling nested page table access by trusted guest software outside of VMX root mode. The system may include an editor module configured to provide access to a nested page table structure, by operating system (OS) kernel components and by user space applications within a guest of the VM, wherein the nested page table structure is associated with one of the protected memory views … A system to provide protected memory views in a virtual machine (VM) environment, said system comprising: … a page handling processor configured to secure said access by maintaining security information in said nested page table structure, said security information comprising: a first indicator configured to override permission bits of said nested page table structure and to indicate that a guest physical address (GPA) page address associated with said nested page table structure is a root level paging structure, said root level paging structure permitted to be processed by said page handling processor; a second indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a non-root level paging structure, said non-root level paging structure permitted to be processed by said page handling processor; and a third indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a read-only mode paging structure …)”.
The motivation to further combine Lemay remains same as in claim 1.
Regarding Claim 8. The combination of Mattson-Lemay discloses the system of claim 6, Lemay further discloses, “wherein the at least one compute unit does not walk the nested page table to identify the system physical address for the memory page in response to a request from the root framework-secure virtual machine to access the memory page, wherein the memory page is a private memory page of one of the plurality of framework-secure virtual machines (Lemay; Claim 30: … a page handling processor configured to secure said access by maintaining security information in said nested page table structure, said security information comprising: a first indicator configured to override permission bits of said nested page table structure and to indicate that a guest physical address (GPA) page address associated with said nested page table structure is a root level paging structure, said root level paging structure permitted to be processed by said page handling processor; a second indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a non-root level paging structure, said non-root level paging structure permitted to be processed by said page handling processor; and a third indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a read-only mode paging structure …)”.
The motivation to further combine Lemay remains same as in claim 1.
Regarding Claim 9. The combination of Mattson-Lemay discloses the system of claim 8, Mattson further discloses, “wherein the request from the root framework-secure virtual machine comprises a request from the virtual machine monitor to manage the memory page on behalf of the one of the plurality of framework-secure virtual machines (Mattson, Para [0026], FIG. 1-2: … FIG. 3 depicts a flow diagram of method steps for initializing the secure protection domain when the secure guest code and data loaded into memory, according to an embodiment. These steps are carried out by VMM 149 when it is notified through a hypercall that GI driver 139 has been loaded into guest physical memory of VM 120. The hypercall includes parameters that identify guest virtual addresses of the executable code and data regions of GI driver 139. Upon receiving this notification, at step 310, VMM 149 marks the page table entries of the memory locations that store the code and data of GI driver 139 to be read-only, so that no other guest thread running on other virtual CPUs can modify the memory state of the executable code and data regions of GI driver 139. Then, at step 312, VMM 149 issues a request to a service appliance 170 through multiplexer 159 to validate the executable code and data regions of GI driver 139 by comparing them against known valid signatures … ).”
Regarding Claim 10. The combination of Mattson-Lemay discloses the system of claim 1, Lemay further discloses, “wherein the at least one memory includes a reverse mapping table that includes a plurality of entries, each of the plurality of entries including a system physical address and at least one identifier of a guest permitted to access the system physical address, wherein the guest is the root framework-secure virtual machine or one of the plurality of framework-secure virtual machines (Lemay; Para [0048], FIG. 5: … At operation 502, the active EPTP for a particular view is retrieved by reading it from the active EPTP list. A recursive function is then invoked that operates as follows, using the EPTP as the initial entry. At operation 504, a reverse mapping is performed from the host physical address for the table (as derived from the entry provided as a parameter) to a guest virtual address. At operation 506, the entry in the table corresponding to the target guest physical address is retrieved. If the entry is a leaf entry, as determined at operation 508, then at operation 512, the host physical address referenced by the entry is calculated. At operation 510, the transform function is invoked on the entry …)”.
The motivation to further combine Lemay remains same as in claim 1.
Regarding Claim 11. The combination of Mattson-Lemay discloses the system of claim 10, Lemay further discloses, “wherein the at least one compute unit is configured to verify, using the reverse mapping table, that the root framework-secure virtual machine is permitted to access a system physical address of the at least one memory that stores a memory page in response to a request from the root framework-secure virtual machine to access the memory page, wherein the memory page is a private memory page of the root framework-secure virtual machine (Lemay; Para [0048], FIG. 5: … At operation 502, the active EPTP for a particular view is retrieved by reading it from the active EPTP list. A recursive function is then invoked that operates as follows, using the EPTP as the initial entry. At operation 504, a reverse mapping is performed from the host physical address for the table (as derived from the entry provided as a parameter) to a guest virtual address. At operation 506, the entry in the table corresponding to the target guest physical address is retrieved. If the entry is a leaf entry, as determined at operation 508, then at operation 512, the host physical address referenced by the entry is calculated. At operation 510, the transform function is invoked on the entry …)”.
The motivation to further combine Lemay remains same as in claim 10.
Regarding Claim 12. The combination of Mattson-Lemay discloses the system of claim 10, Lemay further discloses, “wherein the root framework-secure virtual machine is configured to verify, using the reverse mapping table, that one of the plurality of framework-secure virtual machines is permitted to access a system physical address of the at least one memory that stores a memory page in response to a request from the one of the plurality of framework-secure virtual machines to access the memory page, wherein the memory page is a private memory page of the one of the plurality of framework-secure virtual machines (Lemay; Para [0048], FIG. 5: … At operation 502, the active EPTP for a particular view is retrieved by reading it from the active EPTP list. A recursive function is then invoked that operates as follows, using the EPTP as the initial entry. At operation 504, a reverse mapping is performed from the host physical address for the table (as derived from the entry provided as a parameter) to a guest virtual address. At operation 506, the entry in the table corresponding to the target guest physical address is retrieved. If the entry is a leaf entry, as determined at operation 508, then at operation 512, the host physical address referenced by the entry is calculated. At operation 510, the transform function is invoked on the entry …)”.
The motivation to further combine Lemay remains same as in claim 10.
Regarding Claim 13. The combination of Mattson-Lemay discloses the system of claim 1, Lemay further discloses, “wherein the root framework-secure virtual machine is configured to execute at least one command, on behalf of the plurality of framework-secure virtual machines, that involves access to a memory page that is private to at least one of the plurality of framework-secure virtual machines (Lemay; Para [0041]: … The EPT editor may be configured to accept commands from other code in the kernel and from userspace applications. Commands from either of these origins may use a Syscall-style interface to communicate the commands to the EPT editor. Syscall interfaces are typically used by operating systems to allow a less privileged ring, for example ring 3, to communicate with a more privileged ring, for example ring 0 …)”..
The motivation to further combine Lemay remains same as in claim 1.
Regarding Claim 14. Mattson discloses A system (Mattson, Abstract, FIG. 1: … A hypervisor provides a guest operating system with a plurality of protection domains, including a root protection domain and one or more secure protection domains, and mechanisms for controlling the transitions between the protection domains …) comprising:
physical computer hardware (Mattson, Para [0042]: … The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like … One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media …) including:
at least one compute unit (Mattson, Para [0016, 0042]: … The hardware subsystems may include, without limitation, computational resources including one or more processing units (e.g., CPUs) and system memory (referred to herein as “host physical memory,” which is 202 in FIG. 2), mass storage, a networking in interface, input/output interfaces, a display controller, and power management functions … The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like … One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media …); and
a memory storing a guest page table and a nested page table ((Mattson, Para [0012]: … According to one or more embodiments, the hypervisor provides the guest operating system with a plurality of protection domains, including a root protection domain and one or more secure protection domains, and mechanisms for controlling the transitions between protection domains. The guest physical memory region of a secure protection domain, which is mapped to host physical memory by secure nested page tables, stores secure guest code (e.g., guest introspection driver code) and data, and guest page tables for the secure guest code. When executing secure guest code, the guest page tables stored in the secure protection domain region are used for guest virtual to guest physical address translations, and the secure nested page tables are used for guest physical to host physical address translations );
a virtual machine monitor configured to virtualize the physical computer hardware and instantiate a root framework-secure virtual machine and at least one framework-secure virtual machine (Mattson, Para [0014, 0017, 0027, 0029], Claim 19, FIG. 2: … In FIG. 1, the virtualized host server system is depicted as host 100. Host 100 is built on an underlying hardware computing platform comprising one or more computer systems, each of which may be a desktop computer, laptop computer, tablet computer, mobile device such as a smart phone, server grade computer system, or any other suitable hardware computing platform, including systems based on different variations of the well-known ARM or x86 architecture platforms. Host 100 is configured to execute virtualization software 114 that provides execution support for one or more guest virtual machines (VMs) 120 … virtualization software 114 includes virtual machine monitors (VMMs) 149, which operate in the privileged context of virtualization software 114 and provide the virtual system support, such as emulated physical devices (e.g., virtual CPUs and virtual system memory), for their respective VMs …); and
However, Mattson does not explicitly teach, but Lemay from same or similar field of endeavor teaches:
“the system configured to service a request to access a page in the memory by:
walking the nested page table using the at least one compute unit responsive to the page in the memory being a private memory page of the root framework-secure virtual machine (Lemay; Abstract, Claim 30: … this disclosure provides systems, methods and computer readable media for a protected memory view in a virtual machine (VM) environment enabling nested page table access by trusted guest software outside of VMX root mode. The system may include an editor module configured to provide access to a nested page table structure, by operating system (OS) kernel components and by user space applications within a guest of the VM, wherein the nested page table structure is associated with one of the protected memory views … A system to provide protected memory views in a virtual machine (VM) environment, said system comprising: … a page handling processor configured to secure said access by maintaining security information in said nested page table structure, said security information comprising: a first indicator configured to override permission bits of said nested page table structure and to indicate that a guest physical address (GPA) page address associated with said nested page table structure is a root level paging structure, said root level paging structure permitted to be processed by said page handling processor; a second indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a non-root level paging structure, said non-root level paging structure permitted to be processed by said page handling processor; and a third indicator configured to override permission bits of said nested page table structure and to indicate that said GPA page address is a read-only mode paging structure …); or
not walking the nested page table responsive to the page in the memory being a private memory page of the at least one framework-secure virtual machine.”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lemay into the teachings of Mattson, because it discloses that, “The performance improvements provided by the EPT editor may allow for the application of views to monitor and restrict access to sensitive data and regions of the computer system, such as, for example, memory mapped I/O (MMIO) regions (and the devices associated therewith), page tables and the Windows.TM. registry. The application of views to MMIO access may be used to protect sensor inputs and actuator outputs of the computer system, providing for more secure I/O. Improved anti-malware systems may be implemented based on these capabilities (Lemay, Para [0025])”.
Regarding Claim 20. Mattson discloses A method comprising: receiving, by a hardware platform comprising physical computer hardware, a request to access a memory page from a root framework-secure virtual machine loaded onto the hardware platform (Mattson, Para [0014, 0017, 0027, 0029], Claim 19, FIG. 2: … In FIG. 1, the virtualized host server system is depicted as host 100. Host 100 is built on an underlying hardware computing platform comprising one or more computer systems, each of which may be a desktop computer, laptop computer, tablet computer, mobile device such as a smart phone, server grade computer system, or any other suitable hardware computing platform, including systems based on different variations of the well-known ARM or x86 architecture platforms. Host 100 is configured to execute virtualization software 114 that provides execution support for one or more guest virtual machines (VMs) 120 … virtualization software 114 includes virtual machine monitors (VMMs) 149, which operate in the privileged context of virtualization software 114 and provide the virtual system support, such as emulated physical devices (e.g., virtual CPUs and virtual system memory), for their respective VMs …); and
However, Mattson does not explicitly teach, but Lemay from same or similar field of endeavor teaches:
“granting the request to access the memory page by:
responsive to the memory page being a private memory page of the root framework-secure virtual machine, walking a nested page table to identify a system physical address for the memory page and performing a reverse mapping table check using at least one compute unit of the physical computer hardware (Lemay, Para [0026, 0044, 0048]: … In some embodiments, the EPT editor view is created, during initialization, to protect the data structures needed for the operation of the EPT editor and to grant the editor access to the EPTs created by the VMX root mode software during initialization as well as access to the EPT pointer (EPTP) list. Additionally, other trusted views, which are allowed to invoke the EPT editor view, are also configured to permit invocation of the EPT editor view through the VMFUNC instruction set architecture (ISA) … At operation 414, a check is performed to determine which specific routine is to be invoked and to prepare for that invocation. If the initialization routine is selected, operation 416, then a VM call is performed at operation 418 to request that the VMFUNC instruction be enabled. At operation 420, prior to invoking any of the Syscall operations, the VMFUNC instruction is used to switch to the EPT editor view … At operation 502, the active EPTP for a particular view is retrieved by reading it from the active EPTP list. A recursive function is then invoked that operates as follows, using the EPTP as the initial entry. At operation 504, a reverse mapping is performed from the host physical address for the table (as derived from the entry provided as a parameter) to a guest virtual address. At operation 506, the entry in the table corresponding to the target guest physical address is retrieved. If the entry is a leaf entry, as determined at operation 508, then at operation 512, the host physical address referenced by the entry is calculated. At operation 510, the transform function is invoked on the entry …); or
responsive to the memory page being a private memory page of a framework-secure virtual machine other than the root framework-secure virtual machine, performing the reverse mapping table check using the root framework-secure virtual machine independent of walking the nested page table.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lemay into the teachings of Mattson, because it discloses that, “The performance improvements provided by the EPT editor may allow for the application of views to monitor and restrict access to sensitive data and regions of the computer system, such as, for example, memory mapped I/O (MMIO) regions (and the devices associated therewith), page tables and the Windows.TM. registry. The application of views to MMIO access may be used to protect sensor inputs and actuator outputs of the computer system, providing for more secure I/O. Improved anti-malware systems may be implemented based on these capabilities (Lemay, Para [0025])”.
Claims 3-5 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20160299851 A1 to Mattson et al. (hereinafter “Mattson”) in view of Pub. No.: US 20140380009 A1 to Lemay et al. (hereinafter “Lemay”) as applied to claim 3 above, and further in view of Pub. No.: US 20190102323 A1 to Durham et al. (hereinafter “Durham”).
Regarding Claim 3. The combination of Mattson-Lemay discloses the system of claim 2, however it does not explicitly teach, but Durham from same or similar field of endeavor teaches:
“wherein each of the plurality of entries include a C-bit having a value that indicates whether a memory page is:
Shared (Durham, Para [0044]: … FIG. 9 shows an example of the format of the extended page tables (EPTs). When running in a guest mode, a VMCS may include an extended page table pointer (EPTP) that translates a Guest Physical Address (GPA) to a host physical address (HPA, or physical address). The CPU will select the KeyID associated with currently executing guest and append it to the physical address. In some embodiments, TME may translate the aliased physical memory into a same physical memory location (e.g., using the address and v-bit in the tweak) … The v-bit may be specified in the EPTEs such that the guest may decide which of its pages are shared as read only (e.g., v-bit=0) or kept private (e.g., v-bit=1) …); or
private to the root framework-secure virtual machine or one of the plurality of framework-secure virtual machines.”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Durham into the combined teachings of Mattson-Lemay, because it discloses that, “code may be shared between an encrypted VM and VMM such that the VM provides its own VMExit handler. For example, the VM may configure its VMCS to point to its exit handler in the v-bit space where the VMM may see/verify the guest provided exit handler code/data (e.g., the VM provided exit handler may include code as well as the VMM page table, stack, ISRs, IDT, GDT, IST, etc. specified in the VMCS host state area). Accordingly, following verification the VMM may trust that the VMCS it loads will have a secure exit handler (e.g., by providing approved handler code to the tenant owning the VM), and the tenant may be assured that the exit handler that only the tenant loads into their protected memory will perform actions on behalf of the tenant, such as securely saving (encrypting, integrity protecting, etc.) GPRs, XMM registers, and other CPU state before transitioning to code paths controlled exclusively by the VMM … (Durham, Para [0049])”.
Regarding Claim 4. The combination of Mattson-Lemay discloses the system of claim 2, however it does not explicitly teach, but Durham from same or similar field of endeavor teaches:
“wherein each of the plurality of entries include a T-bit having a value that indicates whether a memory page is:
private to the root framework-secure virtual machine (Durham, Para [0044]: … FIG. 9 shows an example of the format of the extended page tables (EPTs). When running in a guest mode, a VMCS may include an extended page table pointer (EPTP) that translates a Guest Physical Address (GPA) to a host physical address (HPA, or physical address). The CPU will select the KeyID associated with currently executing guest and append it to the physical address. In some embodiments, TME may translate the aliased physical memory into a same physical memory location (e.g., using the address and v-bit in the tweak) … The guest may also specify a c-bit which may select that the VMM's KeyID=0 is used. For example, the c-bit may determine whether or not a page of memory is to be encrypted, or (in some other embodiments) encrypted with the VMM's key. Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched …); or
private to one of the plurality of framework-secure virtual machines.”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Durham into the combined teachings of Mattson-Lemay, because it discloses that, “Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched … (Durham, Para [0044])”.
Regarding Claim 5. The combination of Mattson-Lemay-Durham discloses the system of claim 4, Lemay further discloses, “wherein each of the plurality of entries in the guest page table include a mapping of a guest virtual address to a guest physical address for the memory page (Lemay, Para [0022]: … Although VM guests may share the same host physical memory, the VMM protects the physical memory through EPT based mappings between guest physical memory addresses and host physical memory addresses. The EPTs provide a second layer of paging structures (below the conventional OS page table layer) that are controlled by the VMM as illustrated and described in greater detail in connection with FIG. 6 below. VM guests may be configured to provide an EPT editor view, as will also be described in greater detail below. The EPT editor enables secure access to and modification of selected EPTs (and thus access to memory views associated with those EPTs) to trusted guest software executing in ring 0 mode, for example guest OS kernel components, without requiring a transition to VMX root mode through relatively less efficient VM calls and VM exits. This may improve the performance of applications that require larger or more frequent EPT modifications …)”, and Durham further discloses, “wherein the at least one compute unit uses the guest physical address for the memory page as a system physical address for the memory page based on the T-bit indicating that the memory page is private to one of the plurality of framework-secure virtual machines (Durham, Para [0041, 0045]: … FIG. 9 shows an example of the format of the extended page tables (EPTs). When running in a guest mode, a VMCS may include an extended page table pointer (EPTP) that translates a Guest Physical Address (GPA) to a host physical address (HPA, or physical address). The CPU will select the KeyID associated with currently executing guest and append it to the physical address. In some embodiments, TME may translate the aliased physical memory into a same physical memory location (e.g., using the address and v-bit in the tweak) using the KeyID to select the memory encryption key. In guest mode, the CPU may set the v-bit to the value specified in the extended page table entry (EPTE) (e.g., 0 or 1) where v-bit is a new bit value in the EPTE format. As a guest is launched within a particular KeyID, the CPU may force the KeyID in the physical addresses on the bus (e.g. the KeyID is not specified in the extended page table entries). For example, in guest mode the CPU may set the KeyID to the same KeyID as the launched (e.g., running) VM. Accordingly, the KeyIDs may not be specified in the guest mode paging structures (e.g., the EPTE physical address may not include the KeyID). The v-bit may be specified in the EPTEs such that the guest may decide which of its pages are shared as read only (e.g., v-bit=0) or kept private (e.g., v-bit=1). The guest may also specify a c-bit which may select that the VMM's KeyID=0 is used. For example, the c-bit may determine whether or not a page of memory is to be encrypted, or (in some other embodiments) encrypted with the VMM's key. Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched. Alternatively, in other embodiments, the guest's OS page tables may also specify v-bit and c-bit overriding the EPT values …).”
The motivation to further combine Lemay remains same as in claim 1.
The motivation to further combine Durham remains same as in claim 4.
Regarding Claim 15. The combination of Mattson-Lemay discloses the system of claim 14, however it does not explicitly teach, but Durham from same or similar field of endeavor teaches:
“wherein the guest page table includes a plurality of entries, each of the plurality of entries including a C-bit having a value that indicates whether a memory page is:
Shared (Durham, Para [0044]: … FIG. 9 shows an example of the format of the extended page tables (EPTs). When running in a guest mode, a VMCS may include an extended page table pointer (EPTP) that translates a Guest Physical Address (GPA) to a host physical address (HPA, or physical address). The CPU will select the KeyID associated with currently executing guest and append it to the physical address. In some embodiments, TME may translate the aliased physical memory into a same physical memory location (e.g., using the address and v-bit in the tweak) … The v-bit may be specified in the EPTEs such that the guest may decide which of its pages are shared as read only (e.g., v-bit=0) or kept private (e.g., v-bit=1) …); or
private to the root framework-secure virtual machine or the at least one framework-secure virtual machine.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Durham into the combined teachings of Mattson-Lemay, because it discloses that, “code may be shared between an encrypted VM and VMM such that the VM provides its own VMExit handler. For example, the VM may configure its VMCS to point to its exit handler in the v-bit space where the VMM may see/verify the guest provided exit handler code/data (e.g., the VM provided exit handler may include code as well as the VMM page table, stack, ISRs, IDT, GDT, IST, etc. specified in the VMCS host state area). Accordingly, following verification the VMM may trust that the VMCS it loads will have a secure exit handler (e.g., by providing approved handler code to the tenant owning the VM), and the tenant may be assured that the exit handler that only the tenant loads into their protected memory will perform actions on behalf of the tenant, such as securely saving (encrypting, integrity protecting, etc.) GPRs, XMM registers, and other CPU state before transitioning to code paths controlled exclusively by the VMM … (Durham, Para [0049])”.
Regarding Claim 16. The combination of Mattson-Lemay discloses the system of claim 14, however it does not explicitly teach, but Durham from same or similar field of endeavor teaches:
“[wherein the guest page table includes a plurality of entries], each of the plurality of entries including a T-bit having a value that indicates whether a memory page is:
private to the root framework-secure virtual machine (Durham, Para [0044]: … FIG. 9 shows an example of the format of the extended page tables (EPTs). When running in a guest mode, a VMCS may include an extended page table pointer (EPTP) that translates a Guest Physical Address (GPA) to a host physical address (HPA, or physical address). The CPU will select the KeyID associated with currently executing guest and append it to the physical address. In some embodiments, TME may translate the aliased physical memory into a same physical memory location (e.g., using the address and v-bit in the tweak) … The guest may also specify a c-bit which may select that the VMM's KeyID=0 is used. For example, the c-bit may determine whether or not a page of memory is to be encrypted, or (in some other embodiments) encrypted with the VMM's key. Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched …) – Note: Mattson already discloses guest page table includes a plurality of entries (Mattson, Para [0027]: secure guest page tables are created from original guest page tables and stored in secure protection domain region 230. In particular, the original guest page table entries that point to guest physical memory pages that are mapped by secure NPTs 221 to secure protection domain region 230 are moved into secure guest page tables, shown in FIG. 2 as gPTs 233); or
private to the at least one framework-secure virtual machine.”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Durham into the combined teachings of Mattson-Lemay, because it discloses that, “Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched … (Durham, Para [0044])”.
Regarding Claim 17. The combination of Mattson-Lemay-Durham discloses the system of claim 16, Durham further discloses, “wherein the system is configured to identify that the page in the memory is the private memory page of the root framework-secure virtual machine responsive to the value of the T-bit being zero (Durham, Para [0044, 0048], FIG. 11: … The guest may also specify a c-bit which may select that the VMM's KeyID=0 is used. For example, the c-bit may determine whether or not a page of memory is to be encrypted, or (in some other embodiments) encrypted with the VMM's key. Because the paging structure is verifiable by the VMM before launching the guest, the VMM may still ensure that its memory is protected by the extended page table mappings before the VM is launched. Alternatively, in other embodiments, the guest's OS page tables may also specify v-bit and c-bit overriding the EPT values … Turning now to FIG. 11, a method 130 of handling a page miss by the PMH may include the CPU walking through the paging structures (e.g., starting from EPTP) at block 131. The guest paging structure entries as walked by the PMH determine the value of v-bit for each memory page accessed by the running VM. The method 130 may then determine if the paging structure is misconfigured at block 132 and, if so, may proceed to VMExit at block 133. Otherwise, the method 130 may proceed to read leaf EPT entries to get the physical address, c-bit, and v-bit at block 135. The method 130 may then determine the value of c-bit at block 135. If c-bit is 1 at block 135, the method 130 may set KeyID=0 and v-bit=0 in the physical address (PA) and load the physical address translation in the TLB at block 136 …)”.
The motivation to further combine Durham remains same as in claim 16.
Regarding Claim 18. The combination of Mattson-Lemay-Durham discloses the system of claim 16, Durham further discloses, “wherein the system is configured to identify that the page in the memory is the private memory page of the at least one framework-secure virtual machine responsive to the value of the T-bit being one (Durham, Para [0044, 0048], FIG. 11: … The method 130 may then determine the value of c-bit at block 135. If c-bit is 1 at block 135, the method 130 may set KeyID=0 and v-bit=0 in the physical address (PA) and load the physical address translation in the TLB at block 136. Otherwise, the method 130 may proceed to determine the ASID tag assigned to the current key domain at block 137 …)”.
The motivation to further combine Durham remains same as in claim 16.
Regarding Claim 19. The combination of Mattson-Lemay-Durham discloses the system of claim 16, Lemay further discloses, “the memory further storing a reverse mapping table (Lemay, Para [0058]: … In some embodiments, hash tables may be used to perform reverse mappings from host physical addresses to the corresponding guest virtual addresses with increased efficiency …), wherein the system is further configured to service the request to access the page in the memory (Lemay, Para [0001, 0048, 0006], FIG. 6: … The present disclosure relates to a protected memory view for nested page table access by virtual machine guests, and more particularly, to a protected memory view for extended page table (EPT) access by trusted guest software executing outside of virtual-machine extensions (VMX) root mode …) by:
the at least one compute unit performing a reverse mapping check using the reverse mapping table responsive to the page in the memory being the private memory page of the root framework-secure virtual machine (Lemay, Para [0048]: … At operation 502, the active EPTP for a particular view is retrieved by reading it from the active EPTP list. A recursive function is then invoked that operates as follows, using the EPTP as the initial entry. At operation 504, a reverse mapping is performed from the host physical address for the table (as derived from the entry provided as a parameter) to a guest virtual address. At operation 506, the entry in the table corresponding to the target guest physical address is retrieved. If the entry is a leaf entry, as determined at operation 508, then at operation 512, the host physical address referenced by the entry is calculated. At operation 510, the transform function is invoked on the entry …); or
the root framework-secure virtual machine performing the reverse mapping check using the reverse mapping table responsive to the page in the memory being a private memory page of the at least one framework-secure virtual machine.
The motivation to further combine Lemay remains same as in claim 14.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20090222816 A1; Mansell; et al.: Mansell discloses data processing apparatus and method for controlling access to secure memory by virtual machines executing on processing circuitry. The processing circuitry executes hypervisor software to support the execution of multiple virtual machines on the processing circuitry. A memory system is provided for storing data for access by the processing circuitry, the memory system comprising secure memory for storing secure data and non-secure memory for storing non-secure data, the secure memory only being accessible via a secure access request. Address translation circuitry is responsive to an access request issued by a current virtual machine specifying a virtual address, to perform an address translation process to identify a physical address in the memory, and to cause a modified access request to be issued to the memory system specifying the physical address. A trusted virtual machine identifier is maintained and managed by the hypervisor software, with the hypervisor software setting the trusted virtual machine identifier if the current virtual machine is to be trusted to access the secure memory. Accordingly, in response to the access request issued by the current virtual machine, the address translation circuitry is only able to cause the modified access request to be issued as a secure access request specifying a physical address within the secure memory if the trusted virtual machine identifier is set. By such an approach, the hypervisor software is able to support multiple virtual machines at least some of which have access to secure memory under conditions controlled by the hypervisor software.
The present invention relates to a data processing apparatus and method for controlling access to secure memory by virtual machines executing on processing circuitry of the data processing apparatus.
US 20200201786 A1; OUZIEL et al.: OUZIEL discloses hardware support for the co-existence of restricted and non-restricted encryption keys on a computing system. Such hardware support may comprise a processor having a core, a hardware register to store a bit range to identify a number of bits, of physical memory addresses, that define key identifiers (IDs) and a partition key ID identifying a boundary between non-restricted and restricted key IDs. The core may allocate at least one of the non-restricted key IDs to a software program, such as a hypervisor. The core may further allocate a restricted key ID to a trust domain whose trust computing base does not comprise the software program. A memory controller coupled to the core may allocate a physical page of a memory to the trust domain, wherein data of the physical page of the memory is to be encrypted with an encryption key associated with the restricted key ID.
US 20230098117 A1; WANG et al.: WANG discloses TLB poisoning attacks that take advantage of security issues of translation lookaside buffer (TLB) management on SEV processors in Secure Encrypted Virtualization (SEV) virtual machines (VMs). In various embodiments, a hypervisor may poison TLB entries between two processes of a SEV VM to compromise the integrity and confidentiality of the SEV VM. Variants of TLB poisoning attacks and end-to-end attacks are shown to be successful on both Advanced Micro Devices (AMD) SEV and SEV-Encrypted State (SEV-ES). Countermeasures for thwarting TLB poisoning attacks include hardware-enforced TLB flush processes and re-exec schemes that, among other things, prevent attackers from manipulating TLB entries and causing a privileged victim process to execute malicious code in an attempt to bypass a password authentication.
The present disclosure relates generally to computer security. More particularly, the present disclosure relates to attacks on SEV processors by an untrusted hypervisor and appropriate countermeasures.
US 8090919 B2; Sahita et al.: Sahita discloses A system and method for high performance secure access to a trusted platform module on a hardware virtualization platform. The virtualization platform including Virtual Machine Monitor (VMM) managed components coupled to the VMM. One of the VMM managed components is a TPM (Trusted Platform Module). The virtualization platform also includes a plurality of Virtual Machines (VMs). Each of the virtual machines includes a guest Operating System (OS), a TPM device driver (TDD), and at least one security application. The VMM creates an intra-partition in memory for each TDD such that other code and information at a same or higher privilege level in the VM cannot access the memory contents of the TDD. The VMM also maps access only from the TDD to a TPM register space specifically designated for the VM requesting access. Contents of the TPM requested by the TDD are stored in an exclusively VMM-managed protected page table that provides hardware-based memory isolation for the TDD.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434