Re: [RFC PATCH v7 19/28] KVM: arm64: VHE: Context switch SPE state

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Writing to PMBSR_EL1 after enabling the SPE profiling buffer via PMBLIMITR_EL1 is CONSTRAINED UNPREDICTABLE and can corrupt hardware events.
- [High] Host SPE sampling control registers (e.g., PMSNEVFR_EL1, PMSDSFR_EL1) can be permanently corrupted by a malicious guest.
--

commit 32125a6226fde42baaf9001e75434e4177067f24
Author: Alexandru Elisei <alexandru.elisei@arm.com>

KVM: arm64: VHE: Context switch SPE state

Save and restore the SPE register state when a VCPU is run. The SPE
resources are shared between the guest and the host (the resources are not
partitioned) so KVM has to save the host state, change the owning
translation regime, and then restore the guest state before entering a
guest.

> diff --git a/arch/arm64/kvm/hyp/vhe/spe-sr.c b/arch/arm64/kvm/hyp/vhe/spe-sr.c
> new file mode 100644
> index 0000000000000..978620ad99fa5
> --- /dev/null
> +++ b/arch/arm64/kvm/hyp/vhe/spe-sr.c
> @@ -0,0 +1,209 @@
[ ... ]
> +static void __kvm_spe_save_sampling_regs(struct kvm *kvm, struct kvm_cpu_context *ctxt)
> +{
> +	/*
> +	 * This is dependent on the VM features, and not the hardware features,
> +	 * even for the host, because (a) guest accesses to PMSNEVFR_EL1 and
> +	 * PMSDSFR_EL1 result in an undefined exception in the guest and (b)
> +	 * they don't affect the guest unless the guest explicitly enables them,
> +	 * and a well-behaved guest shouldn't enable them when the corresponding
> +	 * feature is not advertised.
> +	 */
> +	if (kvm_spe_has_feat_spe_fne(kvm))
> +		ctxt_sys_reg(ctxt, PMSNEVFR_EL1) = read_sysreg_s(SYS_PMSNEVFR_EL1);

[Severity: High]
Does this check of the guest's advertised features (kvm_spe_has_feat_spe_fne)
leave the host's sampling control registers vulnerable to corruption?

If the host physically supports FEAT_SPE_FNE but the KVM VM does not
advertise it, KVM will skip saving and restoring the host's PMSNEVFR_EL1
register. Because MDCR_EL2.TPMS = 0 is cleared on guest entry, these
registers will not trap to EL2.

A malicious guest could execute an msr instruction to PMSNEVFR_EL1 directly,
overwriting the hardware register. When the guest exits, KVM skips restoring
the host's value in __kvm_spe_restore_sampling_regs(), allowing the guest's
malicious configuration to persist in the host execution context.

Could this be checking the host's physical capabilities instead of the VM's
advertised features when saving and restoring host state?

[ ... ]
> +void __kvm_spe_restore_guest_state_vhe(struct kvm_vcpu *vcpu, struct kvm_cpu_context *guest_ctxt)
> +{
> +	u64 pmblimitr, pmbsr;
> +
> +	pmbsr = ctxt_sys_reg(guest_ctxt, PMBSR_EL1);
> +	pmblimitr = ctxt_sys_reg(guest_ctxt, PMBLIMITR_EL1);
> +	if (__kvm_spe_profiling_buffer_enabled(pmblimitr, pmbsr)) {
> +		write_sysreg_s(ctxt_sys_reg(guest_ctxt, PMBPTR_EL1), SYS_PMBPTR_EL1);
> +		isb();
> +		write_sysreg_s(pmblimitr, SYS_PMBLIMITR_EL1);
> +		isb();
> +		/* A buffer management event preserves fields in PMBSR_EL1 */
> +		write_sysreg_s(pmbsr, SYS_PMBSR_EL1);

[Severity: High]
Is it safe to write to PMBSR_EL1 after enabling the SPE profiling buffer via
PMBLIMITR_EL1?

According to the ARM Architecture Reference Manual, when the profiling buffer
is enabled, a direct write to PMBSR_EL1 is constrained unpredictable. This
can corrupt hardware events or lead to unknown exceptions.

In __kvm_spe_restore_host_state_vhe(), the PMBSR_EL1 register is correctly
restored before PMBLIMITR_EL1. Should the guest restoration follow the same
sequence to avoid unpredictable behavior?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903160623.315525-1-alexandru.elisei@arm.com?part=19