Re: [PATCH 19/24] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Silently skipping Accessed/Dirty (A/D) bit updates for guest page tables protected by read-only memory attributes allows KVM to map writable SPTEs without updating the guest's dirty bit, causing silent data corruption in the guest OS.
- [High] When a guest page table walk fails due to a memory attribute read fault, KVM incorrectly reports the original instruction's access type (write/exec) to userspace instead of reporting a read fault on the page table.
- [High] KVM injects a fatal guest Page Fault instead of exiting to userspace when an emulated instruction's page table walk hits a memory attribute read fault.
--

--- Patch [19]: [PATCH 19/24] KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only ---
commit 0ad73786bede76212593913d2d0fa39e55055d34
Author: Nicolas Saenz Julienne <nsaenz@amazon.com>

KVM: x86/mmu: Do not update accessed/dirty if guest PTE is read-only
    
This commit modifies the guest page table walk in KVM's x86 MMU to check if
the guest page table's physical address is writable according to KVM memory
attributes. If not, it marks the PTE as not writable in the guest walker.
This appears to be an optimization to avoid exiting to userspace when guest
page tables are mapped read-only.

> diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h
> index 23d7a7d9769fe..ee5c23d1b77a8 100644
> --- a/arch/x86/kvm/mmu/paging_tmpl.h
> +++ b/arch/x86/kvm/mmu/paging_tmpl.h
> @@ -419,6 +419,9 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
>  			goto error;
>  		}
>  
> +		if (!kvm_mem_attributes_may_write_gfn(vcpu->kvm, gpa_to_gfn(real_gpa)))
> +			walker->pte_writable[walker->level - 1] = false;
> +

[Severity: High]
Does this silently skip Accessed/Dirty (A/D) bit updates for guest page
tables?

When the VMM sets a page table's GPA as read-only via KVM memory attributes,
this sets pte_writable to false. Later, FNAME(update_accessed_dirty_bits)()
uses this flag to handle read-only ROM slots:

		if (unlikely(!walker->pte_writable[level - 1]))
			continue;

Since FNAME(update_accessed_dirty_bits)() reports success by returning 0, KVM
will proceed to map the leaf page as writable in the shadow page table (SPTE).

Could this lead to silent data corruption in the guest OS, since it can then
write to the page without faulting while its own page table is never updated?


[Severity: High]
Does KVM report the incorrect access flags to the VMM when a page table walk
fails due to a memory attribute read fault?

In FNAME(page_fault)(), KVM prepares the exit using fault->gfn = walker.gfn
but passes the original fault object:

		if (walker.memory_attributes_fault) {
			fault->gfn = walker.gfn;
			kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
			return -EFAULT;
		}

This passes the write/exec flags of the instruction attempting to access the
leaf page, rather than the KVM page walker's read access to the guest page
table. Could this confuse the VMM's fault handling logic?


[Severity: High]
Is the memory attribute read fault correctly handled by the instruction
emulator?

When FNAME(walk_addr_generic)() encounters a page table mapped as unreadable,
it sets walker.memory_attributes_fault = true and populates a synthetic #PF in
walker.fault.

In FNAME(gva_to_gpa)():

	r = FNAME(walk_addr_generic)(&walker, vcpu, w, addr, access);

	if (r) {
		gpa = gfn_to_gpa(walker.gfn);
		gpa |= addr & ~PAGE_MASK;
	} else if (exception)
		*exception = walker.fault;

The memory_attributes_fault flag is ignored, and the synthetic #PF is bubbled
up to the emulator, which will blindly inject it into the guest. 

Should this trigger a KVM_EXIT_MEMORY_FAULT instead of injecting a fatal guest
page fault?

>  		ptep_user = (pt_element_t __user *)((void *)host_addr + offset);
>  		if (unlikely(get_user(pte, ptep_user)))
>  			goto error;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716181456.402786-1-pbonzini@redhat.com?part=19