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 .
This office action is in response to Applicant’s amendment filed 12/11/2025. Claims 1-20 are pending. Claims 1-2, 4-5, 7-8, 9, 11, 12, 14-16 and 18-19 have been amended.
Claim Rejections - 35 USC § 103
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Viswanathan et al. (US 11599376 B1) in view of Sahita et al. (US 20220214909 A1), hereinafter referred to as Viswanathan and Sahita, respectively.
Regarding Claim 1, Viswanathan discloses A system (Col. 31, Lines 51-52- a computing device that may be used, in accordance with various aspects of the present disclosure. Please note the computing device corresponds to Applicant’s system.) comprising: a processing device (Col. 31, Lines 65-66- The processing element 1004 may comprise at least one processor. Please note the processing element 1004 corresponds to Applicant’s processing device.); and a memory device including instructions that are executable by the processing device for causing the processing device to perform operations (Col. 32, Lines 2-10-The storage element 1002 can include one or more different types of memory […] may be used for program instructions for execution by the processing element 1004. Please note the storage element 1002 including memory used for program instructions for execution by the processing element 1004 corresponds to Applicant’s memory device including instructions executable by the processing device for causing the processing device to perform operations.) comprising:
detecting, by a guest kernel of a virtual machine (VM), an attempt by a device driver running on a first virtual central processing unit (vCPU) to perform a write operation, wherein the first vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that applications 204 using drivers 210 to access the file system 208 of the KVM guest kernel 206 via the vCPU0 corresponds to Applicant’s guest kernel of a VM detecting an attempt by a device driver running on a first vCPU to perform a write operation, as it is known in the art that a common operation of a file system is a write operation, which can be detected by a kernel as part of its function as known in the art.) has a first virtual machine privilege level (VMPL) that prohibits the write operation (Col. 22, Lines 54-60-VM manager 168, installer service 170, key service 174, and/or permission service 172 may have elevated privileges associated with their respective functions. In various examples, processors may include different modes that allow the operating system to execute at different privilege levels. Tasks may be tagged with a corresponding privilege level. Please note that a corresponding privilege level for a particular task, i.e., a write operation, within a VM corresponds to Applicant’s first VMP that prohibits the write operation.);
Viswanathan does not explicitly disclose discloses and wherein the write operation corresponds to a particular kernel memory address for the guest kernel; in response to detecting the write operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel; in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed; determining, by the second vCPU executing the predefined code, that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the write operation should be allowed, enabling the first vCPU to perform the write operation; and based on the first vCPU being enabled to perform the write operation, executing, by the device driver running on the first vCPU, the write operation
However, Sahita discloses and wherein the write operation corresponds to a particular kernel memory address for the guest kernel ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. Please note that memory access being requested that is associated with a write command that includes a targeted GVA (guest virtual address) corresponds to Applicant’s write operation corresponding to a particular kernel memory address for the guest kernel.),
in response to detecting the write operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel ([0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs.; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering an exit to a hypervisor associated with the guest kernel in response to detecting the write operation prohibited by the first VMPL, as the specified permissions corresponding to the first VMPL could initially exclude write permissions, i.e., prohibit those operations, causing the exit to the hypervisor.),
in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed ([0079] Virtual machine 410 includes a guest user application 412, a virtual CPU 414, guest kernel 420, and secure guest kernel 450. Guest kernel 420 and secure guest kernel 450 may be running in a guest operating system (not shown). Guest kernel 420 is illustrated with legacy paging structures 422 and HLAT paging structures 424, similar to legacy paging structures 122 and HLAT paging structures 124 shown in guest kernel 120 of FIG. 1. With a secure guest kernel in virtualized environment 400, however, HLAT paging structures 424 may be provisioned and maintained as secure HLAT paging structures 454 by secure guest kernel 450. HLAT paging structures 454 can be mapped with read/write permissions in secure legacy paging structures 452 of secure guest kernel 450.; [0108] At 810, the hypervisor initiates a boot process for a guest operating system (OS) (e.g., 116) of the VM. At 812, a guest kernel (e.g., 120) or a secure guest kernel (e.g., 450) allocates memory for HLAT paging structures for the guest OS. Please note that the hypervisor initiating a boot process for a guest operating system that has a guest kernel alongside a virtual CPU 414 corresponds to Applicant’s launching a second vCPU with a second VMPL that has different permissions from the first VMPL in response to the exit, because the hypervisor has control after the exit, and is capable of launching a second vCPU, and since it may have different read/write permissions mapped to its paging structures, this corresponds to having a second VMPL. Furthermore, the inherent mechanism of the system to check whether the permissions allow for write operations to occur corresponds to Applicant’s second vCPU being configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed.);
determining, by the second vCPU executing the predefined code, that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the write operation should be allowed, enabling the first vCPU to perform the write operation ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. At 504, processor 160 determines whether the targeted GVA of the memory access request 502 is in a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Please note that processor 160 determining whether the targeted GVA is in a PLR corresponds to Applicant’s determining by the second vCPU executing the predefined code that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel, as it uses a processor to determine that a restricted range of memory addresses, the PLR, does not comprise the particular kernel memory address of the GVA, i.e., it falls outside that range. Furthermore, as it is a prerequisite that the write permissions are present for the operation to be able to be performed, this corresponds to being in response to the second vCPU determining that the write operation should be allowed and enabling the first vCPU to perform the write operation.);
and based on the first vCPU being enabled to perform the write operation, executing, by the device driver running on the first vCPU, the write operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s executing the write operation by the device driver running the first vCPU based on the first vCPU being enabled to perform the write operation, as the memory access request corresponding to the write operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the range of kernel memory and has write permission. Furthermore, it is known in the art that a memory access request such as a write operation may require a device driver and a processor to be carried out, such as the vCPU previously disclosed by Viswanathan.).
Viswanathan and Sahita are both considered to be analogous to the claimed invention because they are in the same field of managing virtual machines that implement guest kernels. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Viswanathan to incorporate the teachings of Sahita to modify the virtual machine system with vCPUs and a guest kernel with privilege levels to exit to a hypervisor associated with the guest kernel in response to detecting the write operation, determining that a range of kernel memory of the guest kernel does not comprise the particular kernel memory address, and executing the write operation, allowing for improved management of access to memory by virtual machines and thus improved system security, as described in Sahita.
Regarding Claim 2, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein enabling the first vCPU to perform the write operations involves: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the write operations.): modifying, by the guest kernel, a write access corresponding to the particular kernel memory address with respect to the first VMPL to enable the device driver to execute the write operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132.; [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that modifying the write permission that the legacy paging structure 122 has such that the guest kernel 120 can write to it and later allowing for a traditional EPT page walk fulfilling a memory access request 502 corresponds to Applicant’s modifying a write access corresponding to the particular kernel memory address with respect to the first VMPL by the guest kernel to enable the device driver to execute the write operation. This is because the write access is modified for the guest kernel with respect to the permissions for the page corresponding to the first VMPL to enable the device driver (known in the art to be a means by which a memory access request can be completed) to execute the write operation, since it now has the required permissions for that particular page containing the GVA.).
Regarding Claim 3, Viswanathan-Sahita as described in Claim 2, Sahita further discloses wherein modifying the write access further comprises: designating the particular kernel memory address as being associated with ([0027] A guest operating system (or guest kernel) of a virtual machine manages guest virtual addresses (GVAs) for data and code associated with the processes running in the virtual machine. Please note that a GVA for data and code managed by a guest kernel that is associated with processes running in the virtual machine corresponds to Applicant’s designating a particular kernel memory address, in this case, the GVA, as being associated with the guest kernel.); and executing an instruction to modify the write access to the particular kernel memory address with respect to the first VMPL ([0027] GVAs (or GLAs) are translated to respective guest physical addresses (GPAs); [0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking GPAs (which are translated from respective GVAs) obtained during a legacy page walk with write permissions corresponds to Applicant’s modifying the write access to the particular kernel memory address with respect to the first VMPL, as it modifies the write access of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL),
Viswanathan further discloses the device driver in a kernel data structure of the guest kernel (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers.)
wherein the instruction involves accessing a permissions database associated with the first VMPL (Col. 18, Lines 13-19-Permission data may be stored by permission service 172 […] the permissions of permission service 172 may define which primitives are accessible by a particular application. Please note that a particular application accessing the permission data stored by permission service 172 corresponds to Applicant’s instruction involving accessing a permissions database associated with the first VMPL, as storing permission data means that the permission service 172 must have an internal data structure corresponding to a database, which would include all the permissions used throughout the system, including those associated with the first VMPL.) and modifying the permissions database to enable the write access of the first vCPU with the first VMPL (Col. 26, Lines 5-11- In some embodiments, permissions may include identification of hardware resources accessible by an application and/or process of an application […] permission service 172 may authenticate whether or not an application (or a process thereof) has been granted a particular permission. Please note that the permissions including identification of hardware resources accessible by the process of an application and authenticating whether it has been granted a particular permission corresponds to Applicant’s modifying the permissions database to enable the write access of the first vCPU with the first VMPL, as the vCPU, running the process of the application, would request access to hardware resources, i.e., write access, and have the permission to do so modified by the permissions service 172 in authentication within its permissions data, corresponding to doing so with the first VMPL.).
Regarding Claim 4, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein the exit is a first exit and the operations further comprise, after enabling the first vCPU to perform the write operation: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk.; [0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the write operations. Additionally, the VM exit that may be triggered if a permission fault occurs when attempting to generate a GPA 512 corresponds to Applicant’s exit being a first exit, as it is the first possible instance in which a VM exit may occur in this sequence.): and based on the interrupt request, triggering, by the guest kernel, a second exit to the hypervisor ([0090] a VM exit may be reported to the hypervisor 130 if a permission fault occurs; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering a second exit to the hypervisor by the guest kernel based on the interrupt request, as the exit to the hypervisor could be caused by an interrupt request that is a result of a permission fault, such as stated below by Viswanathan. Furthermore, as this VM exit may occur under separate circumstances from the aforementioned VM exit that may occur when attempting to generate a GPA 512, this corresponds to it being a second exit.), wherein the hypervisor is configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the write operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s hypervisor being configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the write operation, as the memory access request corresponding to the write operation is carried out in response to determining that it has the privileges to operate on that address, corresponding to using the first VMPL; furthermore it is known in the art that a memory access request such as a write operation may require a processor to be carried out, such as the vCPU previously disclosed by Viswanathan. As control was passed to the hypervisor, this corresponds to the hypervisor being configured to re-launch the first vCPU in response to the second exit.).
Viswanathan further discloses outputting, by the second vCPU, an interrupt request (Col. 22, Lines 60-64- If a task attempts to access a resource or execute a privileged instruction, the processor(s) may determine whether the task has the appropriate privilege level. If not, a protection fault interrupt may be generated to prevent the task from performing the action. Please note the processor determining whether the task has the appropriate privilege level and generating a protection fault interrupt corresponds to Applicant’s outputting an interrupt request by the second vCPU.)
Regarding Claim 5, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein the restricted range of kernel memory is a first range of kernel memory ([0088] a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Such addresses could include, for example, kernel code. Please note that the PLR which is a range of memory addresses including kernel code corresponds to Applicant’s restricted range of kernel memory being a first range of kernel memory.),
and wherein determining that the particular kernel memory address falls outside the restricted range of kernel memory further comprises: determining, by accessing the kernel data structure, that the particular kernel memory address of the write operation attempted by the first device driver is associated with a second range of kernel memory assigned to a second device driver ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s determining that the particular kernel memory address falls outside the restricted range of kernel memory by accessing the kernel data structure that the particular kernel memory address of the write operation is associated with a second range of kernel memory corresponding to a second device driver. This is because the operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the restricted range of kernel memory, meaning that the GVA is outside of the range of the PLR, i.e., has an address that is associated with a second range of kernel memory different from the PLR, and therefore may correspond to a second device driver if it is used by another process of a VM that has the correct permissions.); and in response to determining that the particular kernel memory address is assigned to the second device driver, transmitting an error code to the first device driver, wherein the error code is configured to restrict write access of the first device driver to the second range of kernel memory ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that generating a page fault exception if a permission fault occurs when the targeted GVA is not in PLR corresponds to Applicant’s error code being transmitted to the first device driver that is configured to restrict write access of the first device driver to the second range of kernel memory in response to determining the particular kernel memory address is assigned to the second device driver. This is because the GVA not being in the PLR means it is in a second range of kernel memory, which generates a page fault exception corresponding to an error code that is transmitted, which restricts write access to the second range as it occurs due to a permission fault, meaning it must target an address in a second range outside the first.).
Viswanathan further discloses and the device driver is a first device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s first device driver.), and wherein the operations further comprise, subsequent to launching the second vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that a second virtual processor of the vcpuN virtual processors of the KVM guest corresponds to Applicant’s second vCPU that has been launched, as it must necessarily be launched to be able to be utilized by the KVM, and prior to carrying out operations.);
identifying a kernel data structure included in the guest kernel, wherein the kernel data structure is configured to map kernel memory to a respective device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel mapping kernel memory to a respective device driver, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers that is mapped to its memory.),
Regarding Claim 6, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein the operations further comprise, prior to detecting the write operation attempted by the device driver: assigning, by the guest kernel, the first VMPL to the device driver, wherein the first VMPL is configured to prevent the device driver from executing the write operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking legacy paging structures 122 with only read permissions corresponds to Applicant’s assigning the first VMPL to the device driver by the guest kernel prior to detecting the write operation to prevent the device driver from executing the write operation, as it modifies the write access of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL, and does so to prevent writing by the guest kernel, which uses virtualized drivers to access memory. Furthermore, this occurs prior to attempting to conduct a write operation, since the permission must be checked first, and therefore must have an assigned value.); transmitting, by the guest kernel, a vCPU request including the first VMPL to the hypervisor, wherein in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that a system application of guest kernel 120 sending a memory access request 502 containing a targeted GVA that is compared to the permissions of the legacy paging structures corresponds to Applicant’s transmitting a vCPU request by the guest kernel including the first VMPL to the hypervisor, where in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL. This is because the memory access request 502 being transmitted corresponds to the vCPU request as it is necessarily carried out by a processor associated with the guest kernel, and in response to receiving the request, the permissions associated with the page of the request are checked, and thus it is determined that the vCPU is associated with the first VMPL of the task that is requesting he memory access.);
Viswanathan further discloses and in response to determining that the first vCPU is associated with the first VMPL, executing, by the guest kernel, the device driver using the first vCPU (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver; furthermore, since the KVM guest has emulated hardware, this corresponds to executing the device driver using the first vCPU, which is associated with the first VMPL, as defined by Sahita above.).
Regarding Claim 7, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein the operations further comprise, prior to determining that the particular kernel memory address falls outside the restricted range of kernel memory: determining, by the second vCPU using a data structure, a codebase identifier associated with a trusted code base (TCB) that is configured to determine allowability of the write operation to the particular kernel memory address ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132.; [0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. Please note that the permissions associated with the legacy paging structures 122 that are to be accessed as part of the memory access request 502 corresponds to Applicant’s accessing a data structure to determine a codebase identifier associated with a TCB configured to determine allowability of the write operation to the particular kernel memory address. The legacy paging structure 122 corresponds to Applicant’s codebase identifier associated with a TCB, as it may contain protected code of the PLR, and is a data structure used by the hypervisor 130 to determine whether the write operation is allowable at the address based on the associated permissions. Furthermore, it is known in the art that this operation in a computer system must be done with a processor; therefore, this corresponds to the second vCPU. This process occurs prior to performing the page walk that is based upon the determination of whether the GVA is in the PLR because the permissions must be checked before fulfilling the request; therefore, this corresponds to doing so prior to determining that the particular kernel memory address falls outside the restricted range of kernel memory.),
Viswanathan further discloses using, by the second vCPU, the codebase identifier to obtain the TCB (Col. 10, Lines 58-61- The code of the host kernel 118 is typically loaded into a protected kernel space in memory 104 that is protected from access by application programs and/or from other non-critical components of the host operating system.; Col. 11, Lines 3-7- In various examples, the host kernel 118 controls access to memory 104 using virtual addressing. Virtual addressing refers to making a physical memory address appear to be another address called the “virtual address. Please note that the host kernel being loaded into a protected kernel space in memory 104 protected from access by application programs and controlling access to memory 104 using virtual addressing corresponds to Applicant’s codebase identifier being used by the second vCPU to obtain the TCB, as the guest kernel could use virtual addresses corresponding to codebase identifiers to access the protected kernel space containing the code of the host kernel, corresponding to the TCB.);
and executing, by the second vCPU, the TCB to determine whether the first vCPU should be allowed to perform the write operation, wherein the TCB serves as the predefined code (Col. 10, Lines 58-67-The code of the host kernel 118 is typically loaded into a protected kernel space in memory 104 that is protected from access by application programs and/or from other non-critical components of the host operating system. The host kernel 118 controls access to the one or more processors 102 (e.g., thread scheduling, etc.) […] and handles interrupts in the protected kernel space within memory 104. Please note that the host kernel controlling access to the one or more processors 102 and handling interrupts in the protected kernel space within memory 104 corresponds to Applicant’s executing the TCB to determine whether the first vCPU should be allowed to perform the write operation by the second vCPU, i.e., that which is executing the host kernel for access control, wherein the TCB serves as the predefined code, i.e., the protected kernel space within memory containing host kernel code.).
Regarding Claim 8, Viswanathan discloses A method (Col. 34, Lines 11-12- The flowcharts and methods described herein show the functionality and operation of various implementations. Please note the methods showing the functionality of the implementation of the reference correspond to Applicant’s method.) comprising:
detecting, by a guest kernel of a virtual machine (VM), an attempt by a device driver running on a first virtual central processing unit (vCPU) to perform a write operation, wherein the first vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that applications 204 using drivers 210 to access the file system 208 of the KVM guest kernel 206 via the vCPU0 corresponds to Applicant’s guest kernel of a VM detecting an attempt by a device driver running on a first vCPU to perform a write operation, as it is known in the art that a common operation of a file system is a write operation, which can be detected by a kernel as part of its function as known in the art.) has a first virtual machine privilege level (VMPL) that prohibits the write operation (Col. 22, Lines 54-60-VM manager 168, installer service 170, key service 174, and/or permission service 172 may have elevated privileges associated with their respective functions. In various examples, processors may include different modes that allow the operating system to execute at different privilege levels. Tasks may be tagged with a corresponding privilege level. Please note that a corresponding privilege level for a particular task, i.e., a write operation, within a VM corresponds to Applicant’s first VMP that prohibits the write operation.);
Viswanathan does not explicitly disclose discloses and wherein the write operation corresponds to a particular kernel memory address for the guest kernel; in response to detecting the write operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel; in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed; determining, by the second vCPU executing the predefined code, that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the write operation should be allowed, enabling the first vCPU to perform the write operation; and based on the first vCPU being enabled to perform the write operation, executing, by the device driver running on the first vCPU, the write operation
However, Sahita discloses and wherein the write operation corresponds to a particular kernel memory address for the guest kernel ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. Please note that memory access being requested that is associated with a write command that includes a targeted GVA (guest virtual address) corresponds to Applicant’s write operation corresponding to a particular kernel memory address for the guest kernel.),
in response to detecting the write operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel ([0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs.; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering an exit to a hypervisor associated with the guest kernel in response to detecting the write operation prohibited by the first VMPL, as the specified permissions corresponding to the first VMPL could initially exclude write permissions, i.e., prohibit those operations, causing the exit to the hypervisor.),
in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed ([0079] Virtual machine 410 includes a guest user application 412, a virtual CPU 414, guest kernel 420, and secure guest kernel 450. Guest kernel 420 and secure guest kernel 450 may be running in a guest operating system (not shown). Guest kernel 420 is illustrated with legacy paging structures 422 and HLAT paging structures 424, similar to legacy paging structures 122 and HLAT paging structures 124 shown in guest kernel 120 of FIG. 1. With a secure guest kernel in virtualized environment 400, however, HLAT paging structures 424 may be provisioned and maintained as secure HLAT paging structures 454 by secure guest kernel 450. HLAT paging structures 454 can be mapped with read/write permissions in secure legacy paging structures 452 of secure guest kernel 450.; [0108] At 810, the hypervisor initiates a boot process for a guest operating system (OS) (e.g., 116) of the VM. At 812, a guest kernel (e.g., 120) or a secure guest kernel (e.g., 450) allocates memory for HLAT paging structures for the guest OS. Please note that the hypervisor initiating a boot process for a guest operating system that has a guest kernel alongside a virtual CPU 414 corresponds to Applicant’s launching a second vCPU with a second VMPL that has different permissions from the first VMPL in response to the exit, because the hypervisor has control after the exit, and is capable of launching a second vCPU, and since it may have different read/write permissions mapped to its paging structures, this corresponds to having a second VMPL. Furthermore, the inherent mechanism of the system to check whether the permissions allow for write operations to occur corresponds to Applicant’s second vCPU being configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed.);
determining, by the second vCPU executing the predefined code, that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the write operation should be allowed, enabling the first vCPU to perform the write operation ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. At 504, processor 160 determines whether the targeted GVA of the memory access request 502 is in a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Please note that processor 160 determining whether the targeted GVA is in a PLR corresponds to Applicant’s determining by the second vCPU executing the predefined code that the write operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel, as it uses a processor to determine that a restricted range of memory addresses, the PLR, does not comprise the particular kernel memory address of the GVA, i.e., it falls outside that range. Furthermore, as it is a prerequisite that the write permissions are present for the operation to be able to be performed, this corresponds to being in response to the second vCPU determining that the write operation should be allowed and enabling the first vCPU to perform the write operation.);
and based on the first vCPU being enabled to perform the write operation, executing, by the device driver running on the first vCPU, the write operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s executing the write operation by the device driver running the first vCPU based on the first vCPU being enabled to perform the write operation, as the memory access request corresponding to the write operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the range of kernel memory and has write permission. Furthermore, it is known in the art that a memory access request such as a write operation may require a device driver and a processor to be carried out, such as the vCPU previously disclosed by Viswanathan.).
Viswanathan and Sahita are both considered to be analogous to the claimed invention because they are in the same field of managing virtual machines that implement guest kernels. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Viswanathan to incorporate the teachings of Sahita to modify the virtual machine system with vCPUs and a guest kernel with privilege levels to exit to a hypervisor associated with the guest kernel in response to detecting the write operation, determining that a range of kernel memory of the guest kernel does not comprise the particular kernel memory address, and executing the write operation, allowing for improved management of access to memory by virtual machines and thus improved system security, as described in Sahita.
Regarding Claim 9, Viswanathan-Sahita as described in Claim 8, Sahita further discloses enabling the first vCPU to perform the write operation by: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the write operations.): modifying, by the guest kernel, a write access corresponding to the particular kernel memory address with respect to the first VMPL to enable the device driver to execute the write operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132.; [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that modifying the write permission that the legacy paging structure 122 has such that the guest kernel 120 can write to it and later allowing for a traditional EPT page walk fulfilling a memory access request 502 corresponds to Applicant’s modifying a write access corresponding to the particular kernel memory address with respect to the first VMPL by the guest kernel to enable the device driver to execute the write operation. This is because the write access is modified for the guest kernel with respect to the permissions for the page corresponding to the first VMPL to enable the device driver (known in the art to be a means by which a memory access request can be completed) to execute the write operation, since it now has the required permissions for that particular page containing the GVA.).
Regarding Claim 10, Viswanathan-Sahita as described in Claim 9, Sahita further discloses wherein modifying the write access further comprises: designating the particular kernel memory address as being associated with ([0027] A guest operating system (or guest kernel) of a virtual machine manages guest virtual addresses (GVAs) for data and code associated with the processes running in the virtual machine. Please note that a GVA for data and code managed by a guest kernel that is associated with processes running in the virtual machine corresponds to Applicant’s designating a particular kernel memory address, in this case, the GVA, as being associated with the guest kernel.); and executing an instruction to modify the write access to the particular kernel memory address with respect to the first VMPL ([0027] GVAs (or GLAs) are translated to respective guest physical addresses (GPAs); [0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking GPAs (which are translated from respective GVAs) obtained during a legacy page walk with write permissions corresponds to Applicant’s modifying the write access to the particular kernel memory address with respect to the first VMPL, as it modifies the write access of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL),
Viswanathan further discloses the device driver in a kernel data structure of the guest kernel (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers.)
wherein the instruction involves accessing a permissions database associated with the first VMPL (Col. 18, Lines 13-19-Permission data may be stored by permission service 172 […] the permissions of permission service 172 may define which primitives are accessible by a particular application. Please note that a particular application accessing the permission data stored by permission service 172 corresponds to Applicant’s instruction involving accessing a permissions database associated with the first VMPL, as storing permission data means that the permission service 172 must have an internal data structure corresponding to a database, which would include all the permissions used throughout the system, including those associated with the first VMPL.) and modifying the permissions database to enable the write access of the first vCPU with the first VMPL (Col. 26, Lines 5-11- In some embodiments, permissions may include identification of hardware resources accessible by an application and/or process of an application […] permission service 172 may authenticate whether or not an application (or a process thereof) has been granted a particular permission. Please note that the permissions including identification of hardware resources accessible by the process of an application and authenticating whether it has been granted a particular permission corresponds to Applicant’s modifying the permissions database to enable the write access of the first vCPU with the first VMPL, as the vCPU, running the process of the application, would request access to hardware resources, i.e., write access, and have the permission to do so modified by the permissions service 172 in authentication within its permissions data, corresponding to doing so with the first VMPL.).
Regarding Claim 11, Viswanathan-Sahita as described in Claim 8, Sahita further discloses wherein the exit is a first exit, and further comprising, after enabling the first vCPU to perform the write operation: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk.; [0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the write operations. Additionally, the VM exit that may be triggered if a permission fault occurs when attempting to generate a GPA 512 corresponds to Applicant’s exit being a first exit, as it is the first possible instance in which a VM exit may occur in this sequence.): and based on the interrupt request, triggering, by the guest kernel, a second exit to the hypervisor ([0090] a VM exit may be reported to the hypervisor 130 if a permission fault occurs; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering a second exit to the hypervisor by the guest kernel based on the interrupt request, as the exit to the hypervisor could be caused by an interrupt request that is a result of a permission fault, such as stated below by Viswanathan. Furthermore, as this VM exit may occur under separate circumstances from the aforementioned VM exit that may occur when attempting to generate a GPA 512, this corresponds to it being a second exit.), wherein the hypervisor is configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the write operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s hypervisor being configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the write operation, as the memory access request corresponding to the write operation is carried out in response to determining that it has the privileges to operate on that address, corresponding to using the first VMPL; furthermore it is known in the art that a memory access request such as a write operation may require a processor to be carried out, such as the vCPU previously disclosed by Viswanathan. As control was passed to the hypervisor, this corresponds to the hypervisor being configured to re-launch the first vCPU in response to the second exit.).
Viswanathan further discloses outputting, by the second vCPU, an interrupt request (Col. 22, Lines 60-64- If a task attempts to access a resource or execute a privileged instruction, the processor(s) may determine whether the task has the appropriate privilege level. If not, a protection fault interrupt may be generated to prevent the task from performing the action. Please note the processor determining whether the task has the appropriate privilege level and generating a protection fault interrupt corresponds to Applicant’s outputting an interrupt request by the second vCPU.)
Regarding Claim 12, Viswanathan-Sahita as described in Claim 8, Sahita further discloses wherein the restricted range of kernel memory is a first range of kernel memory ([0088] a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Such addresses could include, for example, kernel code. Please note that the PLR which is a range of memory addresses including kernel code corresponds to Applicant’s restricted range of kernel memory being a first range of kernel memory.),
and wherein determining that the particular kernel memory address falls outside the restricted range of kernel memory further comprises: determining, by accessing the kernel data structure, that the particular kernel memory address of the write operation attempted by the first device driver is associated with a second range of kernel memory assigned to a second device driver ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s determining that the particular kernel memory address falls outside the restricted range of kernel memory by accessing the kernel data structure that the particular kernel memory address of the write operation is associated with a second range of kernel memory corresponding to a second device driver. This is because the operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the restricted range of kernel memory, meaning that the GVA is outside of the range of the PLR, i.e., has an address that is associated with a second range of kernel memory different from the PLR, and therefore may correspond to a second device driver if it is used by another process of a VM that has the correct permissions.); and in response to determining that the particular kernel memory address is assigned to the second device driver, transmitting an error code to the first device driver, wherein the error code is configured to restrict write access of the first device driver to the second range of kernel memory ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that generating a page fault exception if a permission fault occurs when the targeted GVA is not in PLR corresponds to Applicant’s error code being transmitted to the first device driver that is configured to restrict write access of the first device driver to the second range of kernel memory in response to determining the particular kernel memory address is assigned to the second device driver. This is because the GVA not being in the PLR means it is in a second range of kernel memory, which generates a page fault exception corresponding to an error code that is transmitted, which restricts write access to the second range as it occurs due to a permission fault, meaning it must target an address in a second range outside the first.).
Viswanathan further discloses and the device driver is a first device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s first device driver.), and wherein the method further comprises, subsequent to launching the second vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that a second virtual processor of the vcpuN virtual processors of the KVM guest corresponds to Applicant’s second vCPU that has been launched, as it must necessarily be launched to be able to be utilized by the KVM, and prior to carrying out operations.);
identifying a kernel data structure included in the guest kernel, wherein the kernel data structure is configured to map kernel memory to a respective device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel mapping kernel memory to a respective device driver, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers that is mapped to its memory.),
Regarding Claim 13, Viswanathan-Sahita as described in Claim 8, Sahita further discloses wherein the operations further comprise, prior to detecting the write operation attempted by the device driver: assigning, by the guest kernel, the first VMPL to the device driver, wherein the first VMPL is configured to prevent the device driver from executing the write operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking legacy paging structures 122 with only read permissions corresponds to Applicant’s assigning the first VMPL to the device driver by the guest kernel prior to detecting the write operation to prevent the device driver from executing the write operation, as it modifies the write access of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL, and does so to prevent writing by the guest kernel, which uses virtualized drivers to access memory. Furthermore, this occurs prior to attempting to conduct a write operation, since the permission must be checked first, and therefore must have an assigned value.); transmitting, by the guest kernel, a vCPU request including the first VMPL to the hypervisor, wherein in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that a system application of guest kernel 120 sending a memory access request 502 containing a targeted GVA that is compared to the permissions of the legacy paging structures corresponds to Applicant’s transmitting a vCPU request by the guest kernel including the first VMPL to the hypervisor, where in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL. This is because the memory access request 502 being transmitted corresponds to the vCPU request as it is necessarily carried out by a processor associated with the guest kernel, and in response to receiving the request, the permissions associated with the page of the request are checked, and thus it is determined that the vCPU is associated with the first VMPL of the task that is requesting he memory access.);
Viswanathan further discloses and in response to determining that the first vCPU is associated with the first VMPL, executing, by the guest kernel, the device driver using the first vCPU (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver; furthermore, since the KVM guest has emulated hardware, this corresponds to executing the device driver using the first vCPU, which is associated with the first VMPL, as defined by Sahita above.).
Regarding Claim 14, Viswanathan-Sahita as described in Claim 8, Sahita further discloses wherein the operations further comprise, prior to determining that the particular kernel memory address falls outside the restricted range of kernel memory: determining, by the second vCPU using a data structure, a codebase identifier associated with a trusted code base (TCB) that is configured to determine allowability of the write operation to the particular kernel memory address ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132.; [0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. Please note that the permissions associated with the legacy paging structures 122 that are to be accessed as part of the memory access request 502 corresponds to Applicant’s accessing a data structure to determine a codebase identifier associated with a TCB configured to determine allowability of the write operation to the particular kernel memory address. The legacy paging structure 122 corresponds to Applicant’s codebase identifier associated with a TCB, as it may contain protected code of the PLR, and is a data structure used by the hypervisor 130 to determine whether the write operation is allowable at the address based on the associated permissions. Furthermore, it is known in the art that this operation in a computer system must be done with a processor; therefore, this corresponds to the second vCPU. This process occurs prior to performing the page walk that is based upon the determination of whether the GVA is in the PLR because the permissions must be checked before fulfilling the request; therefore, this corresponds to doing so prior to determining that the particular kernel memory address falls outside the restricted range of kernel memory.),
Viswanathan further discloses using, by the second vCPU, the codebase identifier to obtain the TCB (Col. 10, Lines 58-61- The code of the host kernel 118 is typically loaded into a protected kernel space in memory 104 that is protected from access by application programs and/or from other non-critical components of the host operating system.; Col. 11, Lines 3-7- In various examples, the host kernel 118 controls access to memory 104 using virtual addressing. Virtual addressing refers to making a physical memory address appear to be another address called the “virtual address. Please note that the host kernel being loaded into a protected kernel space in memory 104 protected from access by application programs and controlling access to memory 104 using virtual addressing corresponds to Applicant’s codebase identifier being used by the second vCPU to obtain the TCB, as the guest kernel could use virtual addresses corresponding to codebase identifiers to access the protected kernel space containing the code of the host kernel, corresponding to the TCB.);
and executing, by the second vCPU, the TCB to determine whether the first vCPU should be allowed to perform the write operation, wherein the TCB serves as the predefined code (Col. 10, Lines 58-67-The code of the host kernel 118 is typically loaded into a protected kernel space in memory 104 that is protected from access by application programs and/or from other non-critical components of the host operating system. The host kernel 118 controls access to the one or more processors 102 (e.g., thread scheduling, etc.) […] and handles interrupts in the protected kernel space within memory 104. Please note that the host kernel controlling access to the one or more processors 102 and handling interrupts in the protected kernel space within memory 104 corresponds to Applicant’s executing the TCB to determine whether the first vCPU should be allowed to perform the write operation by the second vCPU, i.e., that which is executing the host kernel for access control, wherein the TCB serves as the predefined code, i.e., the protected kernel space within memory containing host kernel code.).
Regarding Claim 15, Viswanathan discloses A non-transitory computer-readable medium comprising program code executable by a processing device for causing the processing device to perform operations (Col. 34, Lines 34-38- Also, any logic or application described herein that comprises software or code can be embodied in any non-transitory computer-readable medium or memory for use by or in connection with an instruction execution system such as a processing component in a computer system. Please note that the application being embodied in a non-transitory computer-readable medium for use in connection with a processing component corresponds to Applicant’s non-transitory computer-readable medium comprising program code executable by a processing device for causing the processing device to perform operations.) comprising: detecting, by a guest kernel of a virtual machine (VM), an attempt by a device driver running on a first virtual central processing unit (vCPU) to perform an operation, wherein the first vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that applications 204 using drivers 210 to access the file system 208 of the KVM guest kernel 206 via the vCPU0 corresponds to Applicant’s guest kernel of a VM detecting an attempt by a device driver running on a first vCPU to perform an operation, as it is known in the art that a common operation of a file system is a write operation, which can be detected by a kernel as part of its function as known in the art.) has a first virtual machine privilege level (VMPL) that prohibits the operation (Col. 22, Lines 54-60-VM manager 168, installer service 170, key service 174, and/or permission service 172 may have elevated privileges associated with their respective functions. In various examples, processors may include different modes that allow the operating system to execute at different privilege levels. Tasks may be tagged with a corresponding privilege level. Please note that a corresponding privilege level for a particular task, i.e., an operation, within a VM corresponds to Applicant’s first VMP that prohibits the operation.);
Viswanathan does not explicitly disclose discloses and wherein the write corresponds to a particular kernel memory address for the guest kernel; in response to detecting the operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel; in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the operation attempted by the device driver should be allowed; determining, by the second vCPU executing the predefined code, that the operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the operation should be allowed, enabling the first vCPU to perform the operation; and based on the first vCPU being enabled to perform the operation, executing, by the device driver running on the first vCPU, the operation
However, Sahita discloses and wherein the operation corresponds to a particular kernel memory address for the guest kernel ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. Please note that memory access being requested that is associated with a write command that includes a targeted GVA (guest virtual address) corresponds to Applicant’s operation corresponding to a particular kernel memory address for the guest kernel.),
in response to detecting the operation prohibited by the first VMPL, triggering, by the guest kernel, an exit to a hypervisor associated with the guest kernel ([0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs.; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering an exit to a hypervisor associated with the guest kernel in response to detecting the operation prohibited by the first VMPL, as the specified permissions corresponding to the first VMPL could initially exclude write permissions, i.e., prohibit those operations, causing the exit to the hypervisor.),
in response to the exit, launching, by the hypervisor a second vCPU with a second VMPL that has different permissions than the first VMPL, wherein the second vCPU is configured to execute predefined code for determining whether the operation attempted by the device driver should be allowed ([0079] Virtual machine 410 includes a guest user application 412, a virtual CPU 414, guest kernel 420, and secure guest kernel 450. Guest kernel 420 and secure guest kernel 450 may be running in a guest operating system (not shown). Guest kernel 420 is illustrated with legacy paging structures 422 and HLAT paging structures 424, similar to legacy paging structures 122 and HLAT paging structures 124 shown in guest kernel 120 of FIG. 1. With a secure guest kernel in virtualized environment 400, however, HLAT paging structures 424 may be provisioned and maintained as secure HLAT paging structures 454 by secure guest kernel 450. HLAT paging structures 454 can be mapped with read/write permissions in secure legacy paging structures 452 of secure guest kernel 450.; [0108] At 810, the hypervisor initiates a boot process for a guest operating system (OS) (e.g., 116) of the VM. At 812, a guest kernel (e.g., 120) or a secure guest kernel (e.g., 450) allocates memory for HLAT paging structures for the guest OS. Please note that the hypervisor initiating a boot process for a guest operating system that has a guest kernel alongside a virtual CPU 414 corresponds to Applicant’s launching a second vCPU with a second VMPL that has different permissions from the first VMPL in response to the exit, because the hypervisor has control after the exit, and is capable of launching a second vCPU, and since it may have different read/write permissions mapped to its paging structures, this corresponds to having a second VMPL. Furthermore, the inherent mechanism of the system to check whether the permissions allow for write operations to occur corresponds to Applicant’s second vCPU being configured to execute predefined code for determining whether the operation attempted by the device driver should be allowed.);
determining, by the second vCPU executing the predefined code, that the operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel in response to the second vCPU determining that the operation should be allowed, enabling the first vCPU to perform the operation ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. At 504, processor 160 determines whether the targeted GVA of the memory access request 502 is in a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Please note that processor 160 determining whether the targeted GVA is in a PLR corresponds to Applicant’s determining by the second vCPU executing the predefined code that the operation should be allowed based on the particular kernel memory address falling outside a restricted range of kernel memory for the guest kernel, as it uses a processor to determine that a restricted range of memory addresses, the PLR, does not comprise the particular kernel memory address of the GVA, i.e., it falls outside that range. Furthermore, as it is a prerequisite that the write permissions are present for the operation to be able to be performed, this corresponds to being in response to the second vCPU determining that the operation should be allowed and enabling the first vCPU to perform the operation.);
and based on the first vCPU being enabled to perform the operation, executing, by the device driver running on the first vCPU, the operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s executing the operation by the device driver running the first vCPU based on the first vCPU being enabled to perform the operation, as the memory access request corresponding to the operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the range of kernel memory and has write permission. Furthermore, it is known in the art that a memory access request, i.e., an operation, may require a device driver and a processor to be carried out, such as the vCPU previously disclosed by Viswanathan.).
Viswanathan and Sahita are both considered to be analogous to the claimed invention because they are in the same field of managing virtual machines that implement guest kernels. Therefore, it would have been obvious to someone of ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Viswanathan to incorporate the teachings of Sahita to modify the virtual machine system with vCPUs and a guest kernel with privilege levels to exit to a hypervisor associated with the guest kernel in response to detecting the operation, determining that a range of kernel memory of the guest kernel does not comprise the particular kernel memory address, and executing the operation, allowing for improved management of access to memory by virtual machines and thus improved system security, as described in Sahita.
Regarding Claim 16, Viswanathan-Sahita as described in Claim 15, Sahita further discloses enabling the first vCPU to perform the operation involves: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the operations.): modifying, by the guest kernel, a permission corresponding to the particular kernel memory address with respect to the first VMPL to enable the device driver to execute the operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132.; [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that modifying the write permission that the legacy paging structure 122 has such that the guest kernel 120 can write to it and later allowing for a traditional EPT page walk fulfilling a memory access request 502 corresponds to Applicant’s modifying a permission corresponding to the particular kernel memory address with respect to the first VMPL by the guest kernel to enable the device driver to execute the operation. This is because the write access, i.e., permission, is modified for the guest kernel with respect to the permissions for the page corresponding to the first VMPL to enable the device driver (known in the art to be a means by which a memory access request can be completed) to execute the operation, since it now has the required permissions for that particular page containing the GVA.).
Regarding Claim 17, Viswanathan-Sahita as described in Claim 16, Sahita further discloses wherein modifying the permission further comprises: designating the particular kernel memory address as being associated with ([0027] A guest operating system (or guest kernel) of a virtual machine manages guest virtual addresses (GVAs) for data and code associated with the processes running in the virtual machine. Please note that a GVA for data and code managed by a guest kernel that is associated with processes running in the virtual machine corresponds to Applicant’s designating a particular kernel memory address, in this case, the GVA, as being associated with the guest kernel.); and executing an instruction to modify the permission to the particular kernel memory address with respect to the first VMPL ([0027] GVAs (or GLAs) are translated to respective guest physical addresses (GPAs); [0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking GPAs (which are translated from respective GVAs) obtained during a legacy page walk with write permissions corresponds to Applicant’s modifying the permission to the particular kernel memory address with respect to the first VMPL, as it modifies the write access, i.e., permission of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL),
Viswanathan further discloses the device driver in a kernel data structure of the guest kernel (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers.)
wherein the instruction involves accessing a permissions database associated with the first VMPL (Col. 18, Lines 13-19-Permission data may be stored by permission service 172 […] the permissions of permission service 172 may define which primitives are accessible by a particular application. Please note that a particular application accessing the permission data stored by permission service 172 corresponds to Applicant’s instruction involving accessing a permissions database associated with the first VMPL, as storing permission data means that the permission service 172 must have an internal data structure corresponding to a database, which would include all the permissions used throughout the system, including those associated with the first VMPL.) and modifying the permissions database to enable the operation of the first vCPU with the first VMPL (Col. 26, Lines 5-11- In some embodiments, permissions may include identification of hardware resources accessible by an application and/or process of an application […] permission service 172 may authenticate whether or not an application (or a process thereof) has been granted a particular permission. Please note that the permissions including identification of hardware resources accessible by the process of an application and authenticating whether it has been granted a particular permission corresponds to Applicant’s modifying the permissions database to enable the operation of the first vCPU with the first VMPL, as the vCPU, running the process of the application, would request access to hardware resources, i.e., to perform operations, and have the permission to do so modified by the permissions service 172 in authentication within its permissions data, corresponding to doing so with the first VMPL.).
Regarding Claim 18, Viswanathan-Sahita as described in Claim 15, Sahita further discloses wherein the exit is a first exit and the operations further comprise, after enabling the first vCPU to perform the operation: ([0030] Additionally, each HLAT paging structure may be marked with a limited write permission (e.g., paging-write also referred to as ‘PW’) via the EPT PTEs for these HLAT paging structures. This limited write permission enables a CPU to set or unset certain bits in the PTEs of the HLAT paging structures that are accessed during a page walk.; [0090] For example, the HLATP 144 can be used at 508 to identify the root of HLAT paging structures 510 (e.g., HLAT paging structures 124) and the page walk may proceed through the HLAT paging structures 510, which may generate a GPA 512, or potentially a page fault exception and a VM exit if a terminal or permission fault occurs. Please note that the limited write permission marked to HLAT paging structures enabling a CPU to set bits in the PTEs of the HLAT paging structures during a page walk corresponds to Applicant’s first vCPU being enabled to perform the operations. Additionally, the VM exit that may be triggered if a permission fault occurs when attempting to generate a GPA 512 corresponds to Applicant’s exit being a first exit, as it is the first possible instance in which a VM exit may occur in this sequence.): and based on the interrupt request, triggering, by the guest kernel, a second exit to the hypervisor ([0090] a VM exit may be reported to the hypervisor 130 if a permission fault occurs; [0107] control passed to the hypervisor via a VM exit. Please note that passing control to the hypervisor 130 if a permission fault occurs via a VM exit corresponds to Applicant’s triggering a second exit to the hypervisor by the guest kernel based on the interrupt request, as the exit to the hypervisor could be caused by an interrupt request that is a result of a permission fault, such as stated below by Viswanathan. Furthermore, as this VM exit may occur under separate circumstances from the aforementioned VM exit that may occur when attempting to generate a GPA 512, this corresponds to it being a second exit.), wherein the hypervisor is configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the operation ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s hypervisor being configured to respond to the second exit by re-launching the first vCPU with the first VMPL to complete the operation, as the memory access request corresponding to the operation is carried out in response to determining that it has the privileges to operate on that address, corresponding to using the first VMPL; furthermore it is known in the art that a memory access request such as a write operation, an instance of an operation, may require a processor to be carried out, such as the vCPU previously disclosed by Viswanathan. As control was passed to the hypervisor, this corresponds to the hypervisor being configured to re-launch the first vCPU in response to the second exit.).
Viswanathan further discloses outputting, by the second vCPU, an interrupt request (Col. 22, Lines 60-64- If a task attempts to access a resource or execute a privileged instruction, the processor(s) may determine whether the task has the appropriate privilege level. If not, a protection fault interrupt may be generated to prevent the task from performing the action. Please note the processor determining whether the task has the appropriate privilege level and generating a protection fault interrupt corresponds to Applicant’s outputting an interrupt request by the second vCPU.)
Regarding Claim 19, Viswanathan-Sahita as described in Claim 15, Sahita further discloses wherein the restricted range of kernel memory is a first range of kernel memory ([0088] a protected linear range (PLR), which is a range of memory addresses that are protected by processing circuitry. Such addresses could include, for example, kernel code. Please note that the PLR which is a range of memory addresses including kernel code corresponds to Applicant’s restricted range of kernel memory being a first range of kernel memory.),
and wherein determining that the particular kernel memory address falls outside the restricted range of kernel memory further comprises: determining, by accessing the kernel data structure, that the particular kernel memory address of the operation attempted by the first device driver is associated with a second range of kernel memory assigned to a second device driver ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR, or is not otherwise designated for HLAT protection (e.g., by selected bits in the GVA), then a traditional EPT page walk may be performed. Please note that determining that the targeted GVA of the memory access request 502 is not in the PLR and subsequently performing a traditional EPT page walk corresponds to Applicant’s determining that the particular kernel memory address falls outside the restricted range of kernel memory by accessing the kernel data structure that the particular kernel memory address of the operation is associated with a second range of kernel memory corresponding to a second device driver. This is because the operation is carried out in response to determining that the targeted GVA corresponding to the particular guest memory address is not in the PLR corresponding to the restricted range of kernel memory, meaning that the GVA is outside of the range of the PLR, i.e., has an address that is associated with a second range of kernel memory different from the PLR, and therefore may correspond to a second device driver if it is used by another process of a VM that has the correct permissions.); and in response to determining that the particular kernel memory address is assigned to the second device driver, transmitting an error code to the first device driver, wherein the error code is configured to restrict access of the first device driver to the second range of kernel memory ([0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that generating a page fault exception if a permission fault occurs when the targeted GVA is not in PLR corresponds to Applicant’s error code being transmitted to the first device driver that is configured to restrict access of the first device driver to the second range of kernel memory in response to determining the particular kernel memory address is assigned to the second device driver. This is because the GVA not being in the PLR means it is in a second range of kernel memory, which generates a page fault exception corresponding to an error code that is transmitted, which restricts write access to the second range as it occurs due to a permission fault, meaning it must target an address in a second range outside the first.).
Viswanathan further discloses and the device driver is a first device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s first device driver.), and wherein the operations further comprise, subsequent to launching the second vCPU (Col. 13, Lines 16-20-The applications 204 may access the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). In the example depicted in FIG. 2, the KVM guest has virtual processors vcpu0 . . . vcpuN. Please note that a second virtual processor of the vcpuN virtual processors of the KVM guest corresponds to Applicant’s second vCPU that has been launched, as it must necessarily be launched to be able to be utilized by the KVM, and prior to carrying out operations.);
identifying a kernel data structure included in the guest kernel, wherein the kernel data structure is configured to map kernel memory to a respective device driver (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver in a kernel data structure of the guest kernel mapping kernel memory to a respective device driver, as the guest kernel 206 must necessarily have a kernel data structure for the virtualized drivers that is mapped to its memory.),
Regarding Claim 20, Viswanathan-Sahita as described in Claim 15, Sahita further discloses wherein the operations further comprise, prior to detecting the operation attempted by the device driver: assigning, by the guest kernel, the first VMPL to the device driver, wherein the first VMPL is configured to prevent the device driver from executing the operation ([0043] Hypervisor 130 may mark legacy paging structures 122 with read/write permission, such that the guest kernel 120 can both read from and write to the legacy paging structures 122. EPT paging structures 132 that map the GPAs obtained during a legacy page walk may also be marked with read/write permissions so that hypervisor 130 can both read from and write to the EPT paging structures 132. Please note that marking legacy paging structures 122 with only read permissions corresponds to Applicant’s assigning the first VMPL to the device driver by the guest kernel prior to detecting the operation to prevent the device driver from executing the operation, as it modifies the write access of the guest kernel to legacy paging structures 122 with respect to the specified permissions marked by the hypervisor, corresponding to being with respect to the first VMPL, and does so to prevent writing by the guest kernel, which uses virtualized drivers to access memory. Furthermore, this occurs prior to attempting to conduct an operation, since the permission must be checked first, and therefore must have an assigned value.); transmitting, by the guest kernel, a vCPU request including the first VMPL to the hypervisor, wherein in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL ([0088] For example, memory access may be requested by a guest user application 112, a system application of guest operating system 116, or a system application of guest kernel 120, for example. A memory access request 502 could be associated with, for example, a read or write command that includes HLATP 144, legacy paging structure pointer 142, EPTP 146, and the targeted GVA for the memory access. [0089] If it is determined that the targeted GVA received in the memory access request 502 is not in the PLR […] the page walk may proceed through the legacy paging structures 520, which may generate a GPA 522, or potentially a page fault exception and VM exit if a terminal or permission fault occurs. Please note that a system application of guest kernel 120 sending a memory access request 502 containing a targeted GVA that is compared to the permissions of the legacy paging structures corresponds to Applicant’s transmitting a vCPU request by the guest kernel including the first VMPL to the hypervisor, where in response to receiving the vCPU request, the hypervisor is configured to determine that the first vCPU is associated with the first VMPL. This is because the memory access request 502 being transmitted corresponds to the vCPU request as it is necessarily carried out by a processor associated with the guest kernel, and in response to receiving the request, the permissions associated with the page of the request are checked, and thus it is determined that the vCPU is associated with the first VMPL of the task that is requesting he memory access.);
Viswanathan further discloses and in response to determining that the first vCPU is associated with the first VMPL, executing, by the guest kernel, the device driver using the first vCPU (Col. 13, Lines 16-20-the KVM guest kernel 206 (including a file system 208 and/or virtualized drivers 210 to access the emulated hardware of the KVM guest 202). Please note that virtualized drivers 210 of the KVM guest kernel 206 correspond to Applicant’s device driver; furthermore, since the KVM guest has emulated hardware, this corresponds to executing the device driver using the first vCPU, which is associated with the first VMPL, as defined by Sahita above.).
Response to Arguments
Applicant's arguments filed 12/11/2025 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
The independent claims have been amended to clarify the sequence of events as well as the relationships between various components. For example, Claim 1 was amended to clarify that the “first vCPU has a first virtual machine privilege level (VMPL) that prohibits the write operation,” the guest kernel triggers an exit to the hypervisor in response to detecting the write operation prohibited by the first VMPL, and the hypervisor launches a second vCPU in response to the exit (associated with the first vCPU). It also additionally clarifies that the second vCPU is “configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed.” Therefore, the rejections under 35 U.S.C. 103 for all claims should be withdrawn.
Regarding A, the examiner respectfully disagrees. Though the changes in the independent claims may clarify the sequence of events and the relationships between various components, they are not sufficient to overcome to overcome the prior art.
As stated above, Sahita discloses in [0090] that the specified permissions corresponding to the first VMPL could initially exclude write permissions, i.e., prohibit those operations, causing the exit to the hypervisor in response to detecting that the operation is prohibited. Furthermore, as stated above, Sahita states in [0079] that the hypervisor initiating a boot process for a guest operating system that has a guest kernel alongside a virtual CPU 414 corresponds to Applicant’s launching a second vCPU in response to the exit associated with the first vCPU, because the hypervisor has control after the exit, and is capable of launching a second vCPU, and since it may have different read/write permissions mapped to its paging structures, this corresponds to having a second VMPL and makes it distinct from the first. The inherent mechanism of the system to check whether the permissions allow for write operations to occur corresponds to Applicant’s second vCPU being configured to execute predefined code for determining whether the write operation attempted by the device driver should be allowed.
Therefore, the recited features can be found in the cited combination of references, and independent Claim 1 remains rejected under 35 U.S.C. 103 for the reasons stated above, and the combinations cited would have been obvious to a person of ordinary skill in the art prior to the effective filing date of the application. Additionally, independent Claims 8 and 15 contain similar limitations to rejected Independent Claim 1 and do not add limitations that overcome the rejection; therefore, they likewise remain rejected, as do the dependent Claims 2-7, 9-14 and 16-20, since they depend on rejected claims. The rejections under 35 U.S.C. 103 are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lee et al. (US 20090210888 A1) discloses a virtual machine running on top of a hypervisor with a guest virtual machine kernel driver, where the virtual machine driver is run in an environment where there is a hosting process running in a section of the virtual machine’s kernel protected address space, as well as passing control of interrupts (see [0004-0005, 0015, 0033-0037]).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARAZ T AKBARI whose telephone number is (571)272-4166. The examiner can normally be reached Monday-Thursday 9:30am-7:30pm ET.
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, April Blair can be reached at (571)270-1014. 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.
/FARAZ T AKBARI/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196