All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev
Subject: Re: [PATCH v11 19/21] KVM: arm64: PMU: Implement fixed-counters-only emulation
Date: Tue, 22 Sep 2026 00:13:14 -0700	[thread overview]
Message-ID: <arIqigtOgVjQlaSG@kernel.org> (raw)
In-Reply-To: <0d065881-3d12-4750-973d-5ff6f3e10a91@rsg.ci.i.u-tokyo.ac.jp>

On Tue, Sep 22, 2026 at 02:59:04PM +0900, Akihiko Odaki wrote:
> On 2026/09/20 20:40, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] kvm: arm64: PMU: host DoS via unprivileged user triggering TAINT_CPU_OUT_OF_SPEC
> > --
> > 
> > commit d0f716fd067877dc7eca2170bb877659746aae89
> > Author: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> > KVM: arm64: PMU: Implement fixed-counters-only emulation
> > 
> > This commit adds a PMUv3 emulation mode that exposes only fixed event
> > counters to the guest. It recreates the underlying host perf event dynamically
> > if the vCPU thread migrates to a different physical CPU. If the destination
> > CPU lacks a registered PMU implementation, it warns and adds a kernel taint.
> > 
> > > diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c
> > > --- a/arch/arm64/kvm/pmu-emul.c
> > > +++ b/arch/arm64/kvm/pmu-emul.c
> > [ ... ]
> > > @@ -811,6 +812,32 @@ static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> > >   	pmc->perf_event = event;
> > >   }
> > > +/**
> > > + * kvm_pmu_create_perf_event - create a perf event for a counter
> > > + * @pmc: Counter context
> > > + */
> > > +static void kvm_pmu_create_perf_event(struct kvm_pmc *pmc)
> > > +{
> > > +	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
> > > +	struct arm_pmu *arm_pmu = vcpu->kvm->arch.arm_pmu;
> > > +
> > > +	if (kvm_pmu_fixed_counters_only(vcpu->kvm)) {
> > > +		do {
> > > +			arm_pmu = kvm_pmu_probe_armpmu(READ_ONCE(vcpu->cpu));
> > > +
> > > +			if (!arm_pmu) {
> > > +				pr_warn_once("kvm: Unsupported PMU variation detected.\n");
> > > +				add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> > 
> > [Severity: High]
> > Can this allow an unprivileged user to intentionally crash the host?
> > 
> > An unprivileged user could create a VM with fixed-counters-only enabled,
> > and then use sched_setaffinity to force the vCPU thread to migrate
> > to a physical CPU that does not have a probed PMU (like an asymmetric core or
> > late-added CPU).
> > 
> > When the vCPU runs, kvm_pmu_create_perf_event() will detect the missing
> > PMU and call add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK). If the host
> > is configured with panic_on_taint enabled, this triggers a direct kernel
> > panic.
> > 
> > Is there a way to return an error to userspace instead of adding a taint
> > based on user-controlled thread affinity?
> 
> The commit message currently says:
> 
> > Registered pPMUs must cover every CPU on which fixed-counters-only
> > emulation runs.
> 
> This wording may suggest that partial PMU coverage is supported, with
> userspace responsible for keeping vCPUs on covered CPUs. Under that
> interpretation, returning an error so userspace can adjust affinity
> would make sense.
> 
> The intended requirement, however, is that registered pPMUs cover every
> CPU. We do not intend to add complexity to either KVM or userspace to
> support partial coverage. The taint indicates an unsupported host
> configuration.
> 
> If another revision is needed, I will remove "on which
> fixed-counters-only emulation runs" to make that requirement explicit.
> 
> I believe all other concerns raised by reviewers and Sashiko have now
> been addressed.

Yeah, folks that use panic_on_warn and panic_on_taint get to suffer the
consequences. So please ignore the Sashiko feedback here.

Thanks,
Oliver

  reply	other threads:[~2026-09-22  7:13 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 11:15 [PATCH v11 00/21] KVM: arm64: PMU: Use multiple host PMUs Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 01/21] KVM: arm64: Serialize repeated vCPU initialization Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 02/21] KVM: arm64: PMU: Stop updating MDCR_EL2.HPMN Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 03/21] KVM: arm64: PMU: Freeze counter count after first run Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 04/21] KVM: arm64: selftests: Test SET_NR_COUNTERS " Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 05/21] KVM: arm64: PMU: Mask EL2-reserved bits on guest bitmap reads Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 06/21] KVM: arm64: PMU: Keep implemented counter mask EL-independent Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 07/21] KVM: arm64: PMU: Preserve EL2 bitmap state during migration Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 08/21] Revert "KVM: arm64: PMU: Reload when resetting" Akihiko Odaki
2026-09-22  6:43   ` Oliver Upton
2026-09-22  7:05     ` Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 09/21] KVM: arm64: PMU: Recreate events after MDCR_EL2 changes Akihiko Odaki
2026-09-22  6:54   ` Oliver Upton
2026-09-22  8:51     ` Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 10/21] KVM: arm64: PMU: Recreate events after PMCR_EL0 changes Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 11/21] KVM: arm64: PMU: Recreate events after userspace event writes Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 12/21] tools headers: Use u* types for bitfield helpers Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 13/21] KVM: arm64: selftests: Cover PMU state in MDCR_EL2 Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 14/21] arm64: errata: Require Apple IMPDEF PMUv3 traps on all CPUs Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 15/21] KVM: arm64: Don't clear vcpu->cpu in kvm_arch_vcpu_put() Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 16/21] KVM: arm64: PMU: Protect the list of PMUs with RCU Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 17/21] KVM: arm64: PMU: Pass the pPMU to kvm_map_pmu_event() Akihiko Odaki
2026-09-20 11:15 ` [PATCH v11 18/21] KVM: arm64: PMU: Pass the target CPU to kvm_pmu_probe_armpmu() Akihiko Odaki
2026-09-20 11:16 ` [PATCH v11 19/21] KVM: arm64: PMU: Implement fixed-counters-only emulation Akihiko Odaki
2026-09-20 11:40   ` sashiko-bot
2026-09-22  5:59     ` Akihiko Odaki
2026-09-22  7:13       ` Oliver Upton [this message]
2026-09-20 11:16 ` [PATCH v11 20/21] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY Akihiko Odaki
2026-09-22  7:11   ` Oliver Upton
2026-09-22  9:13     ` Akihiko Odaki
2026-09-20 11:16 ` [PATCH v11 21/21] KVM: arm64: selftests: Test PMU_V3_FIXED_COUNTERS_ONLY Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arIqigtOgVjQlaSG@kernel.org \
    --to=oupton@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.