linux-kernel - Re: [PATCH v9 02/30] arm64/fpsimd: Update FA64 and ZT0 enables when loading SME state

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: <e50b4923-ee45-43de-9d4e-344546c635bb@sirena.org.uk>
Date: Thu, 8 Jan 2026 15:57:24 +0000
From: Mark Brown <broonie@...nel.org>
To: Fuad Tabba <tabba@...gle.com>
Cc: Marc Zyngier <maz@...nel.org>, Joey Gouly <joey.gouly@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Will Deacon <will@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>,
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>,
	Oliver Upton <oupton@...nel.org>, Dave Martin <Dave.Martin@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ben Horgan <ben.horgan@....com>,
	linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org,
	Peter Maydell <peter.maydell@...aro.org>,
	Eric Auger <eric.auger@...hat.com>
Subject: Re: [PATCH v9 02/30] arm64/fpsimd: Update FA64 and ZT0 enables when
 loading SME state

On Thu, Jan 08, 2026 at 02:09:34PM +0000, Fuad Tabba wrote:
> On Thu, 8 Jan 2026 at 11:54, Mark Brown <broonie@...nel.org> wrote:
> > On Wed, Jan 07, 2026 at 07:25:04PM +0000, Fuad Tabba wrote:
> > > On Tue, 23 Dec 2025 at 01:21, Mark Brown <broonie@...nel.org> wrote:

> > > Should we also preserve the remaining old bits from SMCR_EL1, i.e.,
> > > copy over the bits that aren't
> > > SMCR_ELx_LEN_MASK|SMCR_ELx_FA64|SMCR_ELx_EZT0? For now they are RES0,
> > > but that could change.

> > My thinking here is that any new bits are almost certainly going to need
> > explicit support (like with the addition of ZT0) and that copying them
> > forward without understanding is more likely to lead to a bug like
> > exposing state we didn't mean to than clearing them will.

> I understand the 'secure by default' intent for enable bits, but I'm
> concerned that this implementation changes the current behavior of the
> host kernel, which isn't mentioned in the commit message. Previously,
> both the feature enablement code (cpu_enable_fa64) and the vector
> length setting code (sme_set_vq/write_vl) performed a RMW, preserving
> existing bits in SMCR_EL1. This new macro zeroes out any bits not
> explicitly tracked here.

The behaviour is unchanged since we're always choosing the same value in
the end, it's just a question of rearranging when do it which is the
explicit goal of the change.  There won't be a change in behaviour until
later on in the series when we start potentially choosing other settings
for KVM guests.

> In terms of copying them over, if they were set from the beginning,
> doesn't that mean that that explicit support was already added?

That's a bit circular, with the new interface if someone updates the
kernel to set some new bits they're going to have to update this code as
part of that.  A part of the goal here is to make it harder to make a
mistake with remembering what needs to be updatd when.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)