Re: [PATCH v2 09/28] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Nested trap configuration for CPTR_EL2 is evaluated using a stale memory backing store under FEAT_NV2P1, breaking nested virtualization isolation.
--

--- Patch [9]: [PATCH v2 09/28] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present ---
commit c67129a02beeb5d291611085a5d2f889ac9d97e8
Author: Marc Zyngier <maz@kernel.org>

KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present

This patch relaxes the handling of CPTR_EL2 accesses via CPACR_EL1 when
FEAT_NV2P1 is present, stopping the trap of CPACR_EL1. It modifies the
read path to use the hardware SYS_CPACR_EL1 register instead of the
memory backing store for CPTR_EL2.

[ ... ]

> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 6b47d936efb32..1dfc1f88bec82 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -326,7 +326,10 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg)
>  			val |= __vcpu_sys_reg(vcpu, reg) & ~CNTKCTL_VALID_BITS;
>  			return val;
>  		case CPTR_EL2:
> -			return __vcpu_sys_reg(vcpu, reg);
> +			if (cpus_have_final_cap(ARM64_HAS_NV2P1))
> +				return read_sysreg_el1(SYS_CPACR);
> +			else
> +				return __vcpu_sys_reg(vcpu, reg);

[Severity: High]
Since this changes CPTR_EL2 to be read directly from the hardware register
SYS_CPACR under FEAT_NV2P1 (as the memory backing store can be stale without
trapping), will direct readers of the backing store now read stale values?

For example, in arch/arm64/kvm/emulate-nested.c:get_behaviour():

    val = __vcpu_sys_reg(vcpu, tb->index);

And in arch/arm64/kvm/emulate-nested.c:check_cptr_tta():

    u64 val = __vcpu_sys_reg(vcpu, CPTR_EL2);

Because the L1 guest writes to CPACR_EL1 natively without trapping, the
backing store is not synchronously updated. If an L2 guest traps to host
KVM, wouldn't these functions evaluate trap configurations using the stale
memory backing store, potentially bypassing the L1 hypervisor's trap
configurations?

>  		default:
>  			WARN_ON_ONCE(1);
>  		}

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