linux-kernel - Re: [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter

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: <87ikrzstt1.wl-maz@kernel.org>
Date: Wed, 04 Dec 2024 09:04:26 +0000
From: Marc Zyngier <maz@...nel.org>
To: Oliver Upton <oliver.upton@...ux.dev>
Cc: kvmarm@...ts.linux.dev,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Mingwei Zhang <mizhang@...gle.com>,
	Colton Lewis <coltonlewis@...gle.com>,
	Raghavendra Rao Ananta <rananta@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 05/14] KVM: arm64: Always allow fixed cycle counter

On Tue, 03 Dec 2024 22:32:38 +0000,
Oliver Upton <oliver.upton@...ux.dev> wrote:
> 
> On Tue, Dec 03, 2024 at 09:32:10PM +0000, Marc Zyngier wrote:
> > On Tue, 03 Dec 2024 19:32:11 +0000,
> > Oliver Upton <oliver.upton@...ux.dev> wrote:
> > > 
> > > The fixed CPU cycle counter is mandatory for PMUv3, so it doesn't make a
> > > lot of sense allowing userspace to filter it. Only apply the PMU event
> > > filter to *programmed* event counters.
> > 
> > But that's a change in ABI, isn't it? We explicitly say in the
> > documentation that the cycle counter can be filtered by specifying
> > event 0x11.
> 
> Yeah... A bit of a dirty shortcut I took because I don't like the ABI,
> but distaste isn't enough to break it :)
> 
> > More importantly, the current filtering works in terms of events, and
> > not in terms of counters.
> > 
> > Instead of changing the ABI, how about simply not supporting filtering
> > on such non-compliant HW? Surely that would simplify a few things.
> 
> Yeah, that sounds reasonable. Especially if we allow programmable event
> counters where the event ID space doesn't match the architecture.

Another thing I have been wondering is if a slightly better approach
would be to move some of the handling to the PMU driver itself, and
let it emulate PMUv3 if it can. This would allow conversion of event
numbers in situ rather than polluting the PMUv3 code in KVM.

	M.

-- 
Without deviation from the norm, progress is not possible.