linux-kernel - Re: [PATCH v2 20/20] arm64/fpsimd: Allocate kernel mode FP/SIMD buffers on the stack

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: <CAMj1kXFN0Q8Rba7gdh9AF2SAyyZcNjX89L-GtQs5kbfZtneQzA@mail.gmail.com>
Date: Thu, 2 Oct 2025 18:51:54 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, 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, 
	Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Catalin Marinas <catalin.marinas@....com>, Mark Brown <broonie@...nel.org>, 
	Eric Biggers <ebiggers@...nel.org>
Subject: Re: [PATCH v2 20/20] arm64/fpsimd: Allocate kernel mode FP/SIMD
 buffers on the stack

On Thu, 2 Oct 2025 at 18:22, Kees Cook <kees@...nel.org> wrote:
>
> On Wed, Oct 01, 2025 at 11:02:22PM +0200, Ard Biesheuvel wrote:
> > [...]
> > diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
> > index d9f83c478736..7ddb25df5c98 100644
> > --- a/arch/arm64/include/asm/simd.h
> > +++ b/arch/arm64/include/asm/simd.h
> > @@ -43,8 +43,11 @@ static __must_check inline bool may_use_simd(void) {
> >
> >  #endif /* ! CONFIG_KERNEL_MODE_NEON */
> >
> > -DEFINE_LOCK_GUARD_0(ksimd, kernel_neon_begin(), kernel_neon_end())
> > +DEFINE_LOCK_GUARD_1(ksimd,
> > +                 struct user_fpsimd_state,
> > +                 kernel_neon_begin(_T->lock),
> > +                 kernel_neon_end(_T->lock))
> >
> > -#define scoped_ksimd()       scoped_guard(ksimd)
> > +#define scoped_ksimd()       scoped_guard(ksimd, &(struct user_fpsimd_state){})
>
> I love it!
>
> > [...]
> > -void kernel_neon_end(void)
> > +void kernel_neon_end(struct user_fpsimd_state *s)
> >  {
> >       if (!system_supports_fpsimd())
> >               return;
> > @@ -1899,8 +1910,9 @@ void kernel_neon_end(void)
> >       if (!IS_ENABLED(CONFIG_PREEMPT_RT) && in_serving_softirq() &&
> >           test_thread_flag(TIF_KERNEL_FPSTATE))
> >               fpsimd_load_kernel_state(current);
> > -     else
> > -             clear_thread_flag(TIF_KERNEL_FPSTATE);
> > +     else if (test_and_clear_thread_flag(TIF_KERNEL_FPSTATE))
> > +             if (cmpxchg(&current->thread.kernel_fpsimd_state, s, NULL) != s)
> > +                     BUG();
>
> I always question BUG() uses -- is there a recoverable way to deal with
> a mismatch here? I assume not and that this is the best we can do, but I
> thought I'd just explicitly ask. :)
>

So this fires when kernel_neon_end() passes a different buffer than
the preceding kernel_neon_begin(), but the only purpose of passing it
twice is this particular check.

So perhaps this one can be demoted to a WARN() instead. The preceding
one will fire if kernel_neon_begin() is called and the recorded buffer
pointer is still set from a previous NEON block. Perhaps the same
applies there too: the warning is about something that already
happened, and we can actually proceed as usual.

TL;DR yes let's WARN() instead in both cases.