[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94214ee4-3eec-4151-a5a7-9d5e030fbca3@sirena.org.uk>
Date: Thu, 2 Oct 2025 17:23:28 +0100
From: Mark Brown <broonie@...nel.org>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, herbert@...dor.apana.org.au,
linux@...linux.org.uk, Ard Biesheuvel <ardb@...nel.org>,
Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Kees Cook <keescook@...omium.org>,
Catalin Marinas <catalin.marinas@....com>,
Eric Biggers <ebiggers@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH v2 01/20] arm64: Revert support for generic kernel mode
FPU
On Wed, Oct 01, 2025 at 11:02:03PM +0200, Ard Biesheuvel wrote:
> However, dropping that flag allows the compiler to use FPU and SIMD
> registers in other ways too, and for this reason, arm64 only permits
> doing so in strictly controlled contexts, i.e., isolated compilation
> units that get called from inside a kernel_neon_begin() and
> kernel_neon_end() pair.
> The users of the generic kernel mode FPU API lack such strict checks,
> and this may result in userland FP/SIMD state to get corrupted, given
> that touching FP/SIMD registers outside of a kernel_neon_begin/end pair
> does not fault, but silently operates on the userland state without
> preserving it.
Oh dear, that's nasty - I didn't see the patch when it was going in:
Reviewed-by: Mark Brown <broonie@...nel.org>
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists