Re: [PATCH 1/3] KVM: arm64: Key CPTR_EL2.E0POE propagation on FEAT_S1POE

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] KVM fails to set CPACR_EL1_E0POE in hardware CPTR_EL2 for normal (non-nested) guests, causing all guest EL0 accesses to POR_EL0 to unexpectedly trap to KVM and result in injected UNDEF exceptions.
- [High] KVM breaks host Permission Overlay Extension (POE) usage upon returning from a VHE guest because __deactivate_cptr_traps_vhe() strips CPACR_EL1_E0POE.
--

commit d1828ccf84b404181eed585a3aaf208b36c6b88e
Author: Marc Zyngier <maz@kernel.org>

KVM: arm64: Key CPTR_EL2.E0POE propagation on FEAT_S1POE

We propagate CPTR_EL2.E0POE from a L1 into the L0 configuration, but
we key this on the L1 guest supporting FEAT_S2POE. This is obviously
wrong, as this bit is solely concerned with Stage-1 translation.

Fix this by making the update depend on FEAT_S1POE.

> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 98b2976837b11..4d814ae90613d 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -141,7 +141,7 @@ static inline void __activate_cptr_traps_vhe(struct kvm_vcpu *vcpu)
>  	if (!(SYS_FIELD_GET(CPACR_EL1, ZEN, cptr) & BIT(0)))
>  		val &= ~CPACR_EL1_ZEN;
>  
> -	if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR3_EL1, S2POE, IMP))
> +	if (kvm_has_feat(vcpu->kvm, ID_AA64MMFR3_EL1, S1POE, IMP))
>  		val |= cptr & CPACR_EL1_E0POE;

[Severity: High]
This isn't a bug introduced by this patch, but does this logic apply to
normal guests?

Looking at __activate_cptr_traps_vhe(), normal (non-nested) guests bypass
this nested trap propagation via:

	if (!vcpu_has_nv(vcpu))
		goto write;

As a result, CPACR_EL1_E0POE is never added to the val written to cpacr_el1,
so CPTR_EL2.E0POE is 0. Any guest EL0 access to POR_EL0 will then trap to
EL2. 

Because SYS_POR_EL0 lacks an access callback in sys_reg_descs[] in
arch/arm64/kvm/sys_regs.c, kvm_handle_sys_reg() injects an undefined
instruction exception into the guest, crashing guest applications that rely
on POE.

[Severity: High]
This is a pre-existing issue, but does host POE remain active after running
a VHE guest?

Looking at __deactivate_cptr_traps_vhe() in the same file, the host's
cpacr_el1 is restored with a hardcoded bitmask (FPEN, ZEN, SMEN), and
CPACR_EL1_E0POE is unconditionally stripped:

	u64 val = CPACR_EL1_FPEN;
	
	if (cpus_have_final_cap(ARM64_SVE))
		val |= CPACR_EL1_ZEN;
	if (cpus_have_final_cap(ARM64_SME))
		val |= CPACR_EL1_SMEN;
	
	write_sysreg(val, cpacr_el1);

Since the E0POE bit enabled by the host kernel is overwritten, when the host
returns to userspace, EL0 tasks executing POE instructions will trap to EL2.

Because the host kernel has no hook for POR_EL0 in sys64_hooks, do_el0_sys()
falls back to do_el0_undef(), sending SIGILL and crashing the userspace
task.

>  	val |= cptr & CPTR_EL2_TCPAC;

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