Re: [PATCH 04/16] KVM: arm64: Advertise ID_AA64ZFR0_EL1 to protected VMs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] KVM: arm64: GPA and GPI exposed without vm_has_ptrauth() in
  pvmid_aa64isar1 [1]
--

commit 2d2ae4f2681e16f1e4bc8fc816b7e7d62dcaf9be
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Advertise ID_AA64ZFR0_EL1 to protected VMs

This commit copies the host's sanitised ID_AA64ZFR0_EL1 register value to
EL2 and exposes its capped feature fields to protected VMs when SVE is
enabled for the guest.

> diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> index 7a0aed1d8b0b3..8456bb44edd52 100644
> --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c

[ ... ]

> @@ -124,6 +125,22 @@ static const struct pvm_ftr_bits pvmid_aa64pfr2[] = {
>  	FEAT_END
>  };
>  
> +static const struct pvm_ftr_bits pvmid_aa64zfr0[] = {
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, SVEver, SVE2p3, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, AES, AES2, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, EltPerm, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, BitPerm, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, BF16, EBF16, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, B16B16, B16MM, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, SHA3, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, SM4, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, I8MM, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, F16MM, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, F32MM, IMP, vm_has_sve),
> +	MAX_FEAT_FUNC(ID_AA64ZFR0_EL1, F64MM, IMP, vm_has_sve),
> +	FEAT_END
> +};
> +
>  static const struct pvm_ftr_bits pvmid_aa64mmfr0[] = {
>  	MAX_FEAT_ENUM(ID_AA64MMFR0_EL1, PARANGE, 40),
>  	MAX_FEAT_ENUM(ID_AA64MMFR0_EL1, ASIDBITS, 16),

[Severity: High]
This problem wasn't introduced by this patch, but should GPA and GPI in
pvmid_aa64isar1[] also be gated on vm_has_ptrauth() [1]?

arch/arm64/kvm/hyp/nvhe/sys_regs.c:pvmid_aa64isar1[] {
	MAX_FEAT(ID_AA64ISAR1_EL1, DPB, DPB2),
	MAX_FEAT_FUNC(ID_AA64ISAR1_EL1, APA, PAuth, vm_has_ptrauth),
	MAX_FEAT_FUNC(ID_AA64ISAR1_EL1, API, PAuth, vm_has_ptrauth),
    ...
	MAX_FEAT(ID_AA64ISAR1_EL1, GPA, IMP),
	MAX_FEAT(ID_AA64ISAR1_EL1, GPI, IMP),
    ...
}

Unlike APA, API, GPA3 and APA3, the GPA and GPI entries use MAX_FEAT()
instead of MAX_FEAT_FUNC(..., vm_has_ptrauth).  On a host with generic
pointer authentication, a protected VM created without pointer
authentication still sees GPA or GPI advertised in ID_AA64ISAR1_EL1 while
HCR_EL2.API and HCR_EL2.APK remain clear, so guest generic PAuth
instructions or key accesses trap to EL2 and inject an UNDEFINED exception
into the guest.

[1] https://sashiko.dev/#/bug/linux-01433c94-7171-4ed8-85e1-6ba36cf8dd5f

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109083205.806619-1-fuad.tabba@linux.dev?part=4