linux-hardening - Re: [PATCH RFC] KVM: arm64: PMU: Use multiple host PMUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z9sSMJAlf7cQ5viu@linux.dev>
Date: Wed, 19 Mar 2025 11:51:28 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Marc Zyngier <maz@...nel.org>
Cc: Akihiko Odaki <akihiko.odaki@...nix.com>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Kees Cook <kees@...nel.org>,
	"Gustavo A. R. Silva" <gustavoars@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
	devel@...nix.com
Subject: Re: [PATCH RFC] KVM: arm64: PMU: Use multiple host PMUs

On Wed, Mar 19, 2025 at 06:38:38PM +0000, Marc Zyngier wrote:
> On Wed, 19 Mar 2025 11:51:21 +0000, Akihiko Odaki <akihiko.odaki@...nix.com> wrote:
> > What about setting the flag automatically when a user fails to pin
> > vCPUs to CPUs that are covered by one PMU? There would be no change if
> > a user correctly pins vCPUs as it is. Otherwise, they will see a
> > correct feature set advertised to the guest and the cycle counter
> > working.
> 
> How do you know that the affinity is "correct"? VCPU affinity can be
> changed at any time. I, for one, do not want my VMs to change
> behaviour because I let the vcpus bounce around as the scheduler sees
> fit.
> 
> Honestly, this is not a can of worm I want to open. We already have a
> pretty terrible userspace API for the PMU, let's not add to the
> confusion. *If* we are going down the road of presenting a dumbed-down
> PMU to the guest, it has to be an explicit buy-in from userspace.

I also have a very strong distaste for the crappy UAPI we have around a
'default' PMU. At the same time I do recognize this hurts practical
usecases since some VMMs can't be bothered to configure the vPMU / vCPU
pinning correctly.

I'm at least willing to plug my nose and do the following:

 1) When the VMM does not specify a vPMU type:

   - We continue to present the 'default' PMU (including event counters)
     to the VM

   - KVM ensures that the fixed CPU cycle counter works on any PMUv3
     implementation in the system, even if it is different from the
     default

   - Otherwise, event counters will only count on the default
     implementation and will not count on different PMUs

 2) Implement your suggestion of a UAPI where the VMM can select a PMU
    that only has the CPU cycle counter and works on any PMUv3
    implementation.

Either way KVM will need to have some special case handling of the fixed
CPU cycle counter. That'd allow users to actually run Windows *now* and
provide a clear mechanism for userspace to present a less-broken vPMU if
it cares.

Thanks,
Oliver