Re: [PATCH v3 1/5] KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] KVM injects an External Abort instead of a Permission Fault when a guest accesses a read-only memslot via VNCR with guest stage-1 write protections.
--

commit be3537f8a87d3f507b2b54b34084b37b1630155a
Author: Oliver Upton <oupton@kernel.org>
KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR

This commit updates KVM to cache the writability of the PFN in the VNCR
TLB to constrain the resulting fixmap permissions. It also promotes VNCR
permission faults to a Synchronous External Abort (SEA) when the guest
attempts to write to a read-only endpoint.

Link: https://lore.kernel.org/kvm/20260608082603.16AEC1F00893@smtp.kernel.org/

> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 3a5571c3c1142..903ccabca78c5 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
[ ... ]
> @@ -1401,7 +1402,7 @@ static int kvm_translate_vncr(struct kvm_vcpu *vcpu, bool *is_gmem)
>  	if (!*is_gmem) {
>  		pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
>  					&writable, &page);
> -		if (is_error_noslot_pfn(pfn) || (write_fault && !writable))
> +		if (is_error_noslot_pfn(pfn))
>  			return -EFAULT;

[Severity: High]
This is a pre-existing issue, but does this leak host memory configuration
to the guest by incorrectly prioritizing an External Abort over a Permission
Fault?

When a guest takes a VNCR write fault, this code unconditionally requests
FOLL_WRITE from __kvm_faultin_pfn() without checking if the guest's
stage-1 page tables actually permit writes (vt->wr.pw).

If the backing host memslot is read-only, __kvm_faultin_pfn() fails and KVM
returns -EFAULT, which ultimately causes KVM to inject a guest External Abort
(ESR_ELx_FSC_EXTABT). Architecturally, if the guest's stage-1 translation
lacks write permission, the guest should receive a Stage-1 Permission Fault
regardless of the host's physical memory permissions.

Could this cause unexpected guest panics if the guest OS relies on handling
Permission Faults gracefully before the host RO mapping is enforced?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260618234207.1063941-1-oupton@kernel.org?part=1