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: <3c8b4a5e-89f4-47e0-9a5d-24399407db0c@sirena.org.uk>
Date: Thu, 8 Jan 2026 11:54:31 +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 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:

> > +#define sme_cond_update_smcr(vl, fa64, zt0, reg)               \
> > +       do {                                                    \
> > +               u64 __old = read_sysreg_s((reg));               \
> > +               u64 __new = vl;                                 \
> > +               if (fa64)                       \
> > +                       __new |= SMCR_ELx_FA64;                 \
> > +               if (zt0)                                        \
> > +                       __new |= SMCR_ELx_EZT0;                 \
> > +               if (__old != __new)                             \
> > +                       write_sysreg_s(__new, (reg));           \
> > +       } while (0)
> > +

> Should we cap the VL based on SMCR_ELx_LEN_MASK (as we do in
> sve_cond_update_zcr_vq())?

Yes, although I fear if we've got to the point where we've ever got a
bigger value going in we're going to have bigger problems.

> 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.

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