Re: [PATCH v2] KVM: x86: Restrict saved GPA writes to hardware write faults

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Read-modify-write (RMW) instructions on unmapped MMIO pages will crash SEV guests because the emulated write phase lacks authorization, forcing an impossible software page table walk.
--

commit 2459e3d7bfb5a32b95970716f7650879e8b5d707
Author: Kyle Zeng <kylebot@openai.com>

KVM: x86: Restrict saved GPA writes to hardware write faults

This patch modifies KVM's instruction emulator to carry hardware write-fault
information and restricts the reuse of a saved GPA for writes only when the
hardware reported a write access. It introduces an access mask to authorize
writes based on the initial hardware fault or fall back to a full
translation if unauthorized.

> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 79468ddfe4736..aa5deb7c73aa2 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5088,8 +5088,13 @@ static int emulator_read_write_onepage(unsigned long addr, void *val,
>  	 * Note, this cannot be used on string operations since string
>  	 * operation using rep will only have the initial GPA from the NPF
>  	 * occurred.
> +	 *
> +	 * The guest may have changed the instruction since the fault.  Reuse
> +	 * the GPA for writes only if hardware reported a write access;
> +	 * otherwise, recheck permissions for the decoded access.
>  	 */
> -	if (ctxt->gpa_available && emulator_can_use_gpa(ctxt) &&
> +	if ((ctxt->gpa_access & (write ? ACC_WRITE_MASK : ACC_READ_MASK)) &&
> +	    emulator_can_use_gpa(ctxt) &&

[Severity: High]
Will this break the write phase of read-modify-write (RMW) instructions for
SEV guests?

If a SEV guest executes an RMW instruction (like OR [mem], reg) on an
unmapped MMIO page, the hardware triggers a Nested Page Fault (NPF) on the
initial read access. KVM will set gpa_access to ACC_READ_MASK.

When the emulator attempts the write phase, it appears this check will fail
because ACC_WRITE_MASK is not set. This causes emulator_read_write_onepage()
to fall back to vcpu_mmio_gva_to_gpa().

Does this fallback attempt a software page table walk that will fail on
encrypted guest page tables, resulting in a spurious #PF and crashing the
SEV guest?

>  	    (addr & ~PAGE_MASK) == (ctxt->gpa_val & ~PAGE_MASK)) {
>  		gpa = ctxt->gpa_val;
>  		ret = vcpu_is_mmio_gpa(vcpu, addr, gpa, write);

[ ... ]

> @@ -6454,7 +6459,10 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
>  
>  		/* With shadow page tables, cr2 contains a GVA or nGPA. */
>  		if (vcpu->arch.mmu->root_role.direct) {
> -			ctxt->gpa_available = true;
> +			/* A write fault can require a read for RMW emulation. */
> +			ctxt->gpa_access = ACC_READ_MASK;
> +			if (emulation_type & EMULTYPE_PF_WRITE)
> +				ctxt->gpa_access |= ACC_WRITE_MASK;

[Severity: High]
Does this limit gpa_access too strictly for read faults on RMW instructions?

As mentioned above, if an instruction naturally faults on its first (read)
access, it will only get ACC_READ_MASK here. This seems to be the root cause
that later prevents the write phase from reusing the GPA during MMIO
emulation.

>  			ctxt->gpa_val = cr2_or_gpa;
>  		}
>  	} else {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828235840.63227-1-kylebot@openai.com?part=1