Re: [PATCH v10 06/20] KVM: arm64: PMU: Preserve EL2 bitmap state during migration

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Guest reads of PMU bitmap registers from EL1/EL0 fail to mask out EL2-reserved counters (HPMN), violating the architectural RAZ requirement and leaking EL2 PMU state.
--

commit 02155ef34a95aa6d00cf6402f40fbdccdad7a563
Author: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>

KVM: arm64: PMU: Preserve EL2 bitmap state during migration

KVM_GET_ONE_REG and KVM_SET_ONE_REG transfer raw vCPU state for
migration. Masking PMU bitmap registers with counters accessible at the
current EL drops EL2-reserved bits when the vCPU is stopped in EL1 or
EL0.

Use the implemented counter mask for these userspace accesses so the
complete bitmap state survives migration. Guest register accesses
continue to use the accessible counter mask.

Closes: https://sashiko.dev/#/patchset/20260720-hybrid-v9-0-2b713ca1b5dc@rsg.ci.i.u-tokyo.ac.jp?part=5

> Use the implemented counter mask for these userspace accesses so the
> complete bitmap state survives migration. Guest register accesses
> continue to use the accessible counter mask.

[Severity: High]
This isn't a bug introduced by this patch, but do the guest register accesses
actually use the accessible counter mask for read paths?

When Nested Virtualization (NV) is active, an L1 hypervisor configures
MDCR_EL2.HPMN to reserve PMU counters for itself. If the L2 guest (running
at vEL1/vEL0) reads the PMU bitmap registers, it should read zero for these
reserved counters to satisfy architectural RAZ requirements.

However, looking at the read paths in arch/arm64/kvm/sys_regs.c, the raw state
is returned without applying the accessible counter mask:

arch/arm64/kvm/sys_regs.c:access_pmcnten() {
    ...
	} else {
		p->regval = __vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
	}
    ...
}

arch/arm64/kvm/sys_regs.c:access_pminten() {
    ...
	} else {
		p->regval = __vcpu_sys_reg(vcpu, PMINTENSET_EL1);
	}
    ...
}

arch/arm64/kvm/sys_regs.c:access_pmovs() {
    ...
	} else {
		p->regval = __vcpu_sys_reg(vcpu, PMOVSSET_EL0);
	}
    ...
}

Could this leak the L1 hypervisor's PMU configuration and overflow state
to the untrusted L2 guest?

> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 44aae52c473d7..42b6705bc21d1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1326,7 +1326,7 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  
>  static int set_pmreg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, u64 val)
>  {
> -	u64 mask = kvm_pmu_accessible_counter_mask(vcpu);
> +	u64 mask = kvm_pmu_implemented_counter_mask(vcpu);
>  
>  	__vcpu_assign_sys_reg(vcpu, r->reg, val & mask);
>  	kvm_make_request(KVM_REQ_RELOAD_PMU, vcpu);
> @@ -1336,7 +1336,7 @@ static int set_pmreg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, u64 va
>  
>  static int get_pmreg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, u64 *val)
>  {
> -	u64 mask = kvm_pmu_accessible_counter_mask(vcpu);
> +	u64 mask = kvm_pmu_implemented_counter_mask(vcpu);
>  
>  	*val = __vcpu_sys_reg(vcpu, r->reg) & mask;
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-hybrid-v10-0-92788053a691@rsg.ci.i.u-tokyo.ac.jp?part=6