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] [day] [month] [year] [list]

Message-ID: <20250506145705.GB1246@willie-the-truck>
Date: Tue, 6 May 2025 15:57:05 +0100
From: Will Deacon <will@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Mikołaj Lenczewski <miko.lenczewski@....com>,
	ryan.roberts@....com, suzuki.poulose@....com,
	yang@...amperecomputing.com, corbet@....net,
	catalin.marinas@....com, jean-philippe@...aro.org,
	robin.murphy@....com, joro@...tes.org, akpm@...ux-foundation.org,
	paulmck@...nel.org, mark.rutland@....com, joey.gouly@....com,
	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 Tue, May 06, 2025 at 03:51:59PM +0100, Marc Zyngier wrote:
> On Tue, 06 May 2025 15:25:09 +0100,
> Will Deacon <will@...nel.org> wrote:
> > 
> > On Mon, Apr 28, 2025 at 03:35:14PM +0000, Mikołaj Lenczewski wrote:
> > > The Break-Before-Make cpu feature supports multiple levels (levels 0-2),
> > > and this commit adds a dedicated BBML2 cpufeature to test against
> > > support for, as well as a kernel commandline parameter to optionally
> > > disable BBML2 altogether.
> > > 
> > > This is a system feature as we might have a big.LITTLE architecture
> > > where some cores support BBML2 and some don't, but we want all cores to
> > > be available and BBM to default to level 0 (as opposed to having cores
> > > without BBML2 not coming online).
> > > 
> > > To support BBML2 in as wide a range of contexts as we can, we want not
> > > only the architectural guarantees that BBML2 makes, but additionally
> > > want BBML2 to not create TLB conflict aborts. Not causing aborts avoids
> > > us having to prove that no recursive faults can be induced in any path
> > > that uses BBML2, allowing its use for arbitrary kernel mappings.
> > > Support detection of such CPUs.
> > > 
> > > Signed-off-by: Mikołaj Lenczewski <miko.lenczewski@....com>
> > > Reviewed-by: Suzuki K Poulose <suzuki.poulose@....com>
> > > Reviewed-by: Ryan Roberts <ryan.roberts@....com>
> > > ---
> > >  .../admin-guide/kernel-parameters.txt         |  3 +
> > >  arch/arm64/Kconfig                            | 19 +++++
> > >  arch/arm64/include/asm/cpucaps.h              |  2 +
> > >  arch/arm64/include/asm/cpufeature.h           |  5 ++
> > >  arch/arm64/kernel/cpufeature.c                | 71 +++++++++++++++++++
> > >  arch/arm64/kernel/pi/idreg-override.c         |  2 +
> > >  arch/arm64/tools/cpucaps                      |  1 +
> > >  7 files changed, 103 insertions(+)
> > > 
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index d9fd26b95b34..2749c67a4f07 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -449,6 +449,9 @@
> > >  	arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
> > >  			32 bit applications.
> > >  
> > > +	arm64.nobbml2	[ARM64] Unconditionally disable Break-Before-Make Level
> > > +			2 support
> > 
> > Hmm, I'm not sure we really want this. It opens up the door for folks to
> > pass 'id_aa64mmfr2.bbm=2' without updating the allow-list which feels
> > like it's going to make crashes harder to reason about.
> 
> Passing id_aa64mmfr2.bbm=2 shouldn't have any effect if the HW doesn't
> advertise it already, as you can only downgrade features. Trying to
> upgrade features should leave a nastygram in the kernel log.

Ah, thanks, I was playing around in QEMU and my CPU already had BBML2
so I didn't spot that. In any case, I'd prefer to avoid adding the
option unless we need it -- this thing is driven from an MIDR-based
list and that should be maintained.

Will