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 06/05/2026. Claims 1, 3, 8, 10, 15, and 17 have been amended. Claims 2, 9, and 16 have been cancelled. New Claims 21-23 have been added. Therefore, Claims 1, 3-8, 10-15 and 17-23 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/05/2026 has been entered.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-8, 10-15 and 17-23 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:
assigning, by a guest kernel of a virtual machine (VM), a first virtual central processing unit (vCPU) to run a device driver (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 assigning a first virtual central processing unit (vCPU) to run a device driver by a guest kernel of a virtual machine (VM).),
wherein the first vCPU has a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver (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. 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. Please note that processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM, where the processor determines whether a task has the appropriate privilege level to execute a privileged instruction, corresponds to Applicant’s first vCPU having a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver, as, since previously disclosed, the drivers may be used to access the file system, i.e., are used as part of the task instruction execution process.);
detecting, by the guest kernel, an attempt by the device driver running on the first vCPU to perform a write operation (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 detecting an attempt by the device driver running on the 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.)
wherein the first VMPL 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 processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM corresponds to Applicant’s first VMPL 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, 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 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, modifying, by the guest kernel, the first VMPL to allow write access to the particular kernel memory address; and based on the first VMPL being modified to allow the write access to the particular kernel memory address, 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, 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, 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 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 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 ([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.);
in response to the second vCPU determining that the write operation should be allowed, modifying, by the guest kernel, the first VMPL to allow write access 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.; [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 the first VMPL to allow write access to the particular kernel memory address by the guest kernel. 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. 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 based on the first VMPL being modified to allow the write access to the particular kernel memory address, 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 VMPL being modified to allow the write access to the particular kernel memory address, 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 once the first VMPL has been modified. 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 and a first vCPU assigned to run a device driver 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 by a second vCPU with a second VMPL, modifying the first VMPL to allow write access to the particular kernel memory address by the guest kernel in response to the determination, 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 3, Viswanathan-Sahita as described in Claim 1, Sahita further discloses wherein modifying the first VMPL to allow 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:
assigning, by a guest kernel of a virtual machine (VM), a first virtual central processing unit (vCPU) to run a device driver (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 assigning a first virtual central processing unit (vCPU) to run a device driver by a guest kernel of a virtual machine (VM).),
wherein the first vCPU has a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver (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. 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. Please note that processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM, where the processor determines whether a task has the appropriate privilege level to execute a privileged instruction, corresponds to Applicant’s first vCPU having a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver, as, since previously disclosed, the drivers may be used to access the file system, i.e., are used as part of the task instruction execution process.);
detecting, by the guest kernel, an attempt by the device driver running on the first vCPU to perform a write operation (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 detecting an attempt by the device driver running on the 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.)
wherein the first VMPL 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 processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM corresponds to Applicant’s first VMPL 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, 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 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, modifying, by the guest kernel, the first VMPL to allow write access to the particular kernel memory address; and based on the first VMPL being modified to allow the write access to the particular kernel memory address, 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, 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, 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 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 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 ([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.);
in response to the second vCPU determining that the write operation should be allowed, modifying, by the guest kernel, the first VMPL to allow write access 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.; [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 the first VMPL to allow write access to the particular kernel memory address by the guest kernel. 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. 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 based on the first VMPL being modified to allow the write access to the particular kernel memory address, 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 VMPL being modified to allow the write access to the particular kernel memory address, 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 once the first VMPL has been modified. 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 and a first vCPU assigned to run a device driver 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 by a second vCPU with a second VMPL, modifying the first VMPL to allow write access to the particular kernel memory address by the guest kernel in response to the determination, 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 10, Viswanathan-Sahita as described in Claim 8, Sahita further discloses wherein modifying the first VMPL to allow 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:
assigning, by a guest kernel of a virtual machine (VM), a first virtual central processing unit (vCPU) to run a device driver (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 assigning a first virtual central processing unit (vCPU) to run a device driver by a guest kernel of a virtual machine (VM).),
wherein the first vCPU has a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver (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. 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. Please note that processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM, where the processor determines whether a task has the appropriate privilege level to execute a privileged instruction, corresponds to Applicant’s first vCPU having a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver, as, since previously disclosed, the drivers may be used to access the file system, i.e., are used as part of the task instruction execution process.);
detecting, by the guest kernel, an attempt by the device driver running on the first vCPU to perform an operation (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 detecting an attempt by the device driver running on the 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.)
wherein the first VMPL 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 processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM corresponds to Applicant’s first VMPL that prohibits the operation.);
Viswanathan does not explicitly disclose discloses and wherein the operation corresponds to a particular kernel memory address for the guest kernel; in response to detecting the operation, 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, wherein the second vCPU is configured to execute predefined code for determining whether the write operation 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, modifying, by the guest kernel, the first VMPL to allow access to the particular kernel memory address; and based on the first VMPL being modified to allow access to the particular kernel memory address, 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, 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, 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, wherein the second vCPU is configured to execute predefined code for determining whether the operation 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 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 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 ([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.);
in response to the second vCPU determining that the operation should be allowed, modifying, by the guest kernel, the first VMPL to allow access 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.; [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 the first VMPL to allow access to the particular kernel memory address by the guest kernel. This is because the 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. 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 based on the first VMPL being modified to allow the access to the particular kernel memory address, 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 VMPL being modified to allow access to the particular kernel memory address, 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 once the first VMPL has been modified. 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 and a first vCPU assigned to run a device driver 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 by a second vCPU with a second VMPL, modifying the first VMPL to allow access to the particular kernel memory address by the guest kernel in response to the determination, 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 17, Viswanathan-Sahita as described in Claim 15, Sahita further discloses wherein modifying the first VMPL to allow the access to the particular kernel memory address 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 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.).
Regarding Claim 21, Viswanathan-Sahita as described in Claim 1, Sahita further discloses prior to triggering the exit to the hypervisor, storing, by the first vCPU, an exit location associated with the device driver ([0053] A VM exit marks the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control.; [0054] In computing system 105 for example, hypervisor 130 may configure an instruction setting for the platform configuration instruction (e.g., PCONFIG) so that if a platform configuration instruction is to be executed in any code running on VM 110, the instruction will be intercepted and a VM exit will be taken. For example, an intercept bitmap 148 may be populated to indicate that a platform configuration instruction (e.g., PCONFIG) in code executing in VM 110 is to be intercepted and a VM exit is to be taken from VM 110 before the instruction is invoked. Please note that the VM exit marking the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control, and an intercept bitmap being populated to indicate that a VM exit is to be taken from VM 110 before the instruction is invoked corresponds to Applicant’s storing an exit location associated with the device driver by the first vCPU prior to triggering the exit to the hypervisor.);
and subsequent to the first VMPL being modified to allow the write access to the particular kernel memory address, restarting, by the first vCPU, the device driver at the exit location ([0055] During runtime, when a platform configuration instruction is intercepted in code running in VM 110 and a VM exit is taken, hypervisor 130 can evaluate the HIKID specified in the intercepted instruction […] if the HIKIDs do not match, then hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute. Please note that when the intercepted instruction is evaluated after a VM exit is taken, where the hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute, corresponds to Applicant’s restarting, by the first vCPU, the device driver at the exit location subsequent to the first VMPL being modified to allow the write access to the particular kernel memory address.).
Regarding Claim 22, Viswanathan-Sahita as described in Claim 8, Sahita further discloses prior to triggering the exit to the hypervisor, storing, by the first vCPU, an exit location associated with the device driver ([0053] A VM exit marks the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control.; [0054] In computing system 105 for example, hypervisor 130 may configure an instruction setting for the platform configuration instruction (e.g., PCONFIG) so that if a platform configuration instruction is to be executed in any code running on VM 110, the instruction will be intercepted and a VM exit will be taken. For example, an intercept bitmap 148 may be populated to indicate that a platform configuration instruction (e.g., PCONFIG) in code executing in VM 110 is to be intercepted and a VM exit is to be taken from VM 110 before the instruction is invoked. Please note that the VM exit marking the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control, and an intercept bitmap being populated to indicate that a VM exit is to be taken from VM 110 before the instruction is invoked corresponds to Applicant’s storing an exit location associated with the device driver by the first vCPU prior to triggering the exit to the hypervisor.);
and subsequent to the first VMPL being modified to allow the write access to the particular kernel memory address, restarting, by the first vCPU, the device driver at the exit location ([0055] During runtime, when a platform configuration instruction is intercepted in code running in VM 110 and a VM exit is taken, hypervisor 130 can evaluate the HIKID specified in the intercepted instruction […] if the HIKIDs do not match, then hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute. Please note that when the intercepted instruction is evaluated after a VM exit is taken, where the hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute, corresponds to Applicant’s restarting, by the first vCPU, the device driver at the exit location subsequent to the first VMPL being modified to allow the write access to the particular kernel memory address.).
Regarding Claim 23, Viswanathan-Sahita as described in Claim 15, Sahita further discloses prior to triggering the exit to the hypervisor, storing, by the first vCPU, an exit location associated with the device driver ([0053] A VM exit marks the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control.; [0054] In computing system 105 for example, hypervisor 130 may configure an instruction setting for the platform configuration instruction (e.g., PCONFIG) so that if a platform configuration instruction is to be executed in any code running on VM 110, the instruction will be intercepted and a VM exit will be taken. For example, an intercept bitmap 148 may be populated to indicate that a platform configuration instruction (e.g., PCONFIG) in code executing in VM 110 is to be intercepted and a VM exit is to be taken from VM 110 before the instruction is invoked. Please note that the VM exit marking the point at which a transition occurs from the VM currently running and the hypervisor to all the hypervisor to exercise some system control, and an intercept bitmap being populated to indicate that a VM exit is to be taken from VM 110 before the instruction is invoked corresponds to Applicant’s storing an exit location associated with the device driver by the first vCPU prior to triggering the exit to the hypervisor.);
and subsequent to the first VMPL being modified to allow the access to the particular kernel memory address, restarting, by the first vCPU, the device driver at the exit location ([0055] During runtime, when a platform configuration instruction is intercepted in code running in VM 110 and a VM exit is taken, hypervisor 130 can evaluate the HIKID specified in the intercepted instruction […] if the HIKIDs do not match, then hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute. Please note that when the intercepted instruction is evaluated after a VM exit is taken, where the hypervisor 130 may cause VM 110 to resume and allow the intercepted platform configuration instruction to execute, corresponds to Applicant’s restarting, by the first vCPU, the device driver at the exit location subsequent to the first VMPL being modified to allow the access to the particular kernel memory address.).
Response to Arguments
Applicant's arguments filed 06/05/2026 have been fully considered but they are not persuasive.
Applicant’s arguments are summarized as follows:
The independent claims have been amended. Viswanathan-Sahita does not teach the limitations, as amended. Firstly, Viswanathan described virtual processors in association with a KVM guest, which is not the same as assigning a specific vCPU to run a device driver, as recited in the amended independent Claims. Additionally, the VMPL is equated to a privilege level assigned to a task, as recited by Viswanathan, but it is associated with inter-process communication of components within an edge computing system, not virtual processors, and is related to a task, not the first vCPU to control access permissions associated with the driver. Therefore, Viswanathan does not disclose the newly amended limitations “assigning, by a guest kernel of a virtual machine (VM), a first virtual central processing unit (vCPU) to run a device driver, wherein the first vCPU has a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver.” Sahita is also silent as to these limitations, and generally describes its hypervisor modifying permissions associated with paging structures, which is different from the guest kernel modifying the first VMPL corresponding to the first vCPU. Therefore, the rejections under 35 U.S.C. 103 for all claims should be withdrawn.
Regarding A, the examiner respectfully disagrees.
As stated above, Viswanathan from the system of Viswanathan-Sahita discloses the newly added limitations “assigning, by a guest kernel of a virtual machine (VM), a first virtual central processing unit (vCPU) to run a device driver, wherein the first vCPU has a first virtual machine privilege level (VMPL) that controls access permissions associated with the device driver.” This is because, as stated in Col. 13, Lines 16-20, applications 204 using drivers 210 to access the file system 208 of the KVM guest kernel 206 via the vCPU0 corresponds to Applicant’s assigning a first vCPU to run a device driver by a guest kernel of a VM. Additionally, as further stated in Col. 22, Lines 54-60, processors including modes corresponding to privilege levels, where there may be corresponding privilege levels for a particular task, i.e., a write operation, within a VM, where the processor determines whether a task has the appropriate privilege level to execute a privileged instruction, corresponds to Applicant’s first vCPU having a first VMPL that controls access permissions associated with the device driver, as, since previously disclosed, the drivers may be used to access the file system, i.e., are used as part of the task instruction execution process. In effect, the vCPU is indeed used to control the access permissions associated with the driver via its modes corresponding to privilege levels, and for evaluating the permissions for the execution of privileged instructions that it may carry out.
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 3-7, 10-14 and 17-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]).
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
Prosecution Insights