From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Borislav Petkov <bp@alien8.de>,
Jain@formenos.rohan.me.apana.org.au, Ayush <Ayush.Jain3@amd.com>,
Stephen Rothwell <sfr@canb.auug.org.au>, x86-ml <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH] crypto: lib/sha256 - Disable SIMD
Date: Fri, 16 May 2025 10:03:16 -0700 [thread overview]
Message-ID: <20250516170316.GD1241@sol> (raw)
In-Reply-To: <aCcmJGuCnuyHmHbx@gondor.apana.org.au>
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@alien8.de>
> Fixes: 950e5c84118c ("crypto: sha256 - support arch-optimized lib and expose through shash")
> Signed-off-by: Herbert Xu <herbert@gondor.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
next prev parent reply other threads:[~2025-05-16 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 11:22 cryptodev linux-next splat Borislav Petkov
2025-05-16 11:34 ` Herbert Xu
2025-05-16 11:48 ` [PATCH] crypto: lib/sha256 - Disable SIMD Herbert Xu
2025-05-16 12:27 ` Borislav Petkov
2025-05-16 17:03 ` Eric Biggers [this message]
2025-05-16 18:13 ` Borislav Petkov
2025-05-16 19:06 ` Eric Biggers
2025-05-16 20:34 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250516170316.GD1241@sol \
--to=ebiggers@kernel.org \
--cc=Ayush.Jain3@amd.com \
--cc=Jain@formenos.rohan.me.apana.org.au \
--cc=bp@alien8.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.