Re: [PATCH] KVM: arm64: Trap guest MPAM accesses whenever MPAM is implemented

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] KVM fails to trap guest accesses to MPAM registers when the sanitized MPAM capability evaluates to false (e.g., due to `arm64.nompam` boot parameter or asymmetric CPU topologies), allowing the guest to directly access physical host MPAM hardware.
--

commit 4af5e7631ab3a7072311a3251a8c2768e198ef2e
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Trap guest MPAM accesses whenever MPAM is implemented

This patch updates KVM to trap guest accesses to MPAM registers based solely
on the ID registers rather than the ARM64_MPAM capability, which also
requires MPAMEN to be set.

Link: https://lore.kernel.org/all/CA+EHjTxeWxZiuSmnKLGLxTBXP4oJT7-LuffbPAyCSZZ5TW=5Ew@mail.gmail.com/

> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 17b83a2518a8f..36a27692e5cf7 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2501,6 +2501,13 @@ test_has_mpam(const struct arm64_cpu_capabilities *entry, int scope)
>  	return (read_sysreg_s(SYS_MPAM1_EL1) & MPAM1_EL1_MPAMEN);
>  }
>  
> +static bool
> +test_has_mpam_sysregs(const struct arm64_cpu_capabilities *entry, int __unused)
> +{
> +	/* The registers exist whether or not firmware enabled MPAM. */
> +	return detect_ftr_has_mpam();
> +}
> +

[Severity: High]
This isn't a bug introduced by this patch, but it appears to be a
pre-existing issue. Does relying on detect_ftr_has_mpam() here leave the
physical MPAM hardware exposed?

The detect_ftr_has_mpam() function checks the sanitised CPU feature
registers. If the host is booted with the arm64.nompam parameter, or on
systems with asymmetric CPU topologies where the boot CPU lacks MPAM, this
check will evaluate to false even if the physical hardware on the current
CPU implements MPAM.

[ ... ]

> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 1ce7130e25490..8941335724f6b 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -298,7 +298,7 @@ static inline void  __activate_traps_mpam(struct kvm_vcpu *vcpu)
>  	u64 clr = MPAM2_EL2_EnMPAMSM;
>  	u64 set = MPAM2_EL2_TRAPMPAM0EL1 | MPAM2_EL2_TRAPMPAM1EL1;
>  
> -	if (!system_supports_mpam())
> +	if (!system_supports_mpam_sysregs())
>  		return;
>  
>  	/* trap guest access to MPAMIDR_EL1 */

[Severity: High]
This is also part of the pre-existing issue mentioned above. 

When system_supports_mpam_sysregs() returns false due to the sanitised
feature registers, this early return skips setting the TRAPMPAM0EL1 and
TRAPMPAM1EL1 trap bits in SYS_MPAM2_EL2.

Since the hardware traps remain disabled, could this allow a malicious
guest to directly access physical MPAM configuration registers (such as
MPAM0_EL1) and bypass hypervisor isolation? This might allow the guest to
manipulate host cache and memory bandwidth partitioning, potentially
causing a denial of service against the host or other VMs.

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