[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250516170316.GD1241@sol>
Date: Fri, 16 May 2025 10:03:16 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Borislav Petkov <bp@...en8.de>, Jain@...menos.rohan.me.apana.org.au,
Ayush <Ayush.Jain3@....com>,
Stephen Rothwell <sfr@...b.auug.org.au>, x86-ml <x86@...nel.org>,
lkml <linux-kernel@...r.kernel.org>, linux-crypto@...r.kernel.org
Subject: Re: [PATCH] crypto: lib/sha256 - Disable SIMD
On Fri, May 16, 2025 at 07:48:52PM +0800, Herbert Xu wrote:
> On Fri, May 16, 2025 at 07:34:06PM +0800, Herbert Xu wrote:
> >
> > So what's happened is that previously if you call sha256_update
> > from lib/crypto it would only use the generic C code to perform
> > the operation.
> >
> > This has now been changed to automatically use SIMD instructions
> > which obviously blew up in your case.
>
> In the interim you can go back to the old ways and disable SIMD
> for lib/crypto sha256 with this patch:
>
> ---8<---
> Disable SIMD usage in lib/crypto sha256 as it is causing crashes.
>
> Reported-by: Borislav Petkov <bp@...en8.de>
> Fixes: 950e5c84118c ("crypto: sha256 - support arch-optimized lib and expose through shash")
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
That's silly. We should just fix x86's irq_fpu_usable() to return false before
the CPU is properly initialized. It already checks a per-cpu bool, so it
shouldn't be too hard to fit that in.
Using the generic SHA-256 code explicitly is also an option, but ideally the
regular functions would just work.
- Eric
Powered by blists - more mailing lists