linux-kernel - Re: [RESEND PATCH v6 1/3] arm64: Add BBM Level 2 cpu feature

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: <aB4mVtzLaS-YCzW2@arm.com>
Date: Fri, 9 May 2025 16:59:18 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Will Deacon <will@...nel.org>
Cc: Ryan Roberts <ryan.roberts@....com>,
	Mikołaj Lenczewski <miko.lenczewski@....com>,
	suzuki.poulose@....com, yang@...amperecomputing.com, corbet@....net,
	jean-philippe@...aro.org, robin.murphy@....com, joro@...tes.org,
	akpm@...ux-foundation.org, paulmck@...nel.org, mark.rutland@....com,
	joey.gouly@....com, maz@...nel.org, james.morse@....com,
	broonie@...nel.org, oliver.upton@...ux.dev, baohua@...nel.org,
	david@...hat.com, ioworker0@...il.com, jgg@...pe.ca,
	nicolinc@...dia.com, mshavit@...gle.com, jsnitsel@...hat.com,
	smostafa@...gle.com, kevin.tian@...el.com,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev
Subject: Re: [RESEND PATCH v6 1/3] arm64: Add BBM Level 2 cpu feature

On Fri, May 09, 2025 at 03:28:53PM +0100, Will Deacon wrote:
> On Fri, May 09, 2025 at 03:16:01PM +0100, Ryan Roberts wrote:
> > On 09/05/2025 14:49, Will Deacon wrote:
> > > I wonder if we could treat it like an erratum in some way instead? That
> > > is, invert things so that CPUs which _don't_ have BBML2_NOABORT are
> > > considered to have a "BBM_CONFLICT_ABORT" erratum (which we obviously
> > > wouldn't shout about). Then we should be able to say:
> > > 
> > >   - If any of the early CPUs don't have BBML2_NOABORT, then the erratum
> > >     would be enabled and we wouln't elide BBM.
> > > 
> > >   - If a late CPU doesn't have BBML2_NOABORT then it can't come online
> > >     if the erratum isn't already enabled.
> > 
> > That's exactly the policy that this cludge provides. But it's using the midr to
> > check if the CPU has BBML2_NOABORT. I'm not sure I follow your point about a
> > "BBM_CONFLICT_ABORT" erratum?
> 
> I was hoping that it would mean that each CPU can independently determine
> whether or not they have the erratum and then enable it as soon as they
> detect it. That way, there's no need to iterate over all the early cores.

But then we'll still have to disable the feature if one of the early
CPUs doesn't have it. As a local CPU feature as per the errata handling,
the feature (bug) is advertised if at least one CPU supports it. Here we
kind of need a combination of system (available an all early CPUs) and
local MIDR check.

We might be able to work with two features - one SCOPE_SYSTEM for the
sanitised ID reg and a _negative_ (deny-list) SCOPE_LOCAL_CPU for the
MIDR. Or probably a single CPU-local feature, but negative, that checks
both the ID reg and MIDR, let's call it ARM64_HAS_NO_BBML2_NOABORT. If a
single CPU does not have the ID reg or is on the MIDR deny-list, this
"feature" will be enabled. For late CPUs, if NO_BBML2_NOABORT has been
enabled, they are allowed to miss it (OPTIONAL_FOR_LATE_CPU). However,
if NO_BBML2_NOABORT is cleared, a late CPU is not allowed to have it.

Hmm, if I got the logic right, that's what
ARM64_CPUCAP_LOCAL_CPU_ERRATUM means but we need to negate the feature
to disable the optimisation if at least one CPU is on the deny-list or
missing BBML2.

(or maybe I haven't had enough coffee today)

-- 
Catalin