linux-kernel - Re: [PATCH v5 10/24] KVM: arm64: Set up FGT for Partitioned PMU

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: <aUH1nZB83m62kkUH@kernel.org>
Date: Tue, 16 Dec 2025 16:13:17 -0800
From: Oliver Upton <oupton@...nel.org>
To: Colton Lewis <coltonlewis@...gle.com>
Cc: kvm@...r.kernel.org, pbonzini@...hat.com, corbet@....net,
	linux@...linux.org.uk, catalin.marinas@....com, will@...nel.org,
	maz@...nel.org, oliver.upton@...ux.dev, mizhang@...gle.com,
	joey.gouly@....com, suzuki.poulose@....com, yuzenghui@...wei.com,
	mark.rutland@....com, shuah@...nel.org,
	gankulkarni@...amperecomputing.com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev, linux-perf-users@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v5 10/24] KVM: arm64: Set up FGT for Partitioned PMU

On Fri, Dec 12, 2025 at 08:51:34PM +0000, Colton Lewis wrote:
> > The other reason for doing this is kvm_pmu_fgt_bits() assumes a
> > 'positive' trap polarity, even though there are several cases where FGTs
> > have a 'negative' priority (i.e. 0 => trap).
> 
> For the bits I was concerned with they all had positive polarity, except
> for the dedicated instruction counter. (Side note: Why would ARM do
> this?)

Old software on new hardware, you don't want the guest to magically get
access to things it shouldn't.

> IIRC the FGT setup I plugged into in previous versions of the patch had
> some icky macros that accounted for polarity. They were confusing and I
> didn't like the effort to understand them.

I'm guessing you're referring to the undef infrastructure (FGUs), which
is a meaningfully load-bearing part of KVM.

> Is there a good reason not to adopt a convetion that 1 => trap for
> kernel code? Reversing the negative polarities immediately before write
> could be easy: Have a bitmap of the negative polarity bits to xor with
> the traps we actually want.

This *significantly* muddies the water around FGTs. I quite like that the
current representation matches the architecture. NV forces KVM to deal
with the native representations anyway.

Thanks,
Oliver