[<prev] [next>] [<thread-prev] [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(¤t->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.
Powered by blists - more mailing lists