All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org,
	linux-s390@vger.kernel.org, x86@kernel.org, ardb@kernel.org,
	Jason@zx2c4.com, torvalds@linux-foundation.org
Subject: Re: [PATCH 11/13] crypto: x86/sha256 - implement library instead of shash
Date: Sat, 26 Apr 2025 18:02:48 -0700	[thread overview]
Message-ID: <20250427010248.GA68006@quark> (raw)
In-Reply-To: <aA138IKjqyZeQLgB@gondor.apana.org.au>

On Sun, Apr 27, 2025 at 08:18:56AM +0800, Herbert Xu wrote:
> On Sat, Apr 26, 2025 at 11:03:26AM -0700, Eric Biggers wrote:
> >
> > The SHA-256 library functions currently work in any context, and this patch
> > series preserves that behavior.  Changing that would be a separate change.
> 
> I've already removed the SIMD fallback path and your patch is
> adding it back.

While you've been pushing out a lot of random broken changes to shash recently,
the SHA-256 library functions weren't SIMD-optimized until this patchset.

> > But also as I've explained before, for the library API the performance benefit
> > of removing the crypto_simd_usable() doesn't seem to be worth the footgun that
> > would be introduced.  Your position is, effectively, that if someone calls one
> > of the sha256*() functions from a hardirq, we should sometimes corrupt a random
> > task's FPU registers.  That's a really bad bug that is very difficult to
> > root-cause.  My position is that we should make it just work as expected.
> 
> kernel_fpu_begin already does a WARN_ON when called in hardirq
> context and it can't safely use the FPU, there is no silent
> corruption.

Only when CONFIG_X86_DEBUG_FPU is enabled, which people don't enable in
production.  And even if that is enabled, it's just a WARN, so the registers
still get used and corrupted anyway.

- Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org,
	linux-s390@vger.kernel.org, x86@kernel.org, ardb@kernel.org,
	Jason@zx2c4.com, torvalds@linux-foundation.org
Subject: Re: [PATCH 11/13] crypto: x86/sha256 - implement library instead of shash
Date: Sat, 26 Apr 2025 18:02:48 -0700	[thread overview]
Message-ID: <20250427010248.GA68006@quark> (raw)
In-Reply-To: <aA138IKjqyZeQLgB@gondor.apana.org.au>

On Sun, Apr 27, 2025 at 08:18:56AM +0800, Herbert Xu wrote:
> On Sat, Apr 26, 2025 at 11:03:26AM -0700, Eric Biggers wrote:
> >
> > The SHA-256 library functions currently work in any context, and this patch
> > series preserves that behavior.  Changing that would be a separate change.
> 
> I've already removed the SIMD fallback path and your patch is
> adding it back.

While you've been pushing out a lot of random broken changes to shash recently,
the SHA-256 library functions weren't SIMD-optimized until this patchset.

> > But also as I've explained before, for the library API the performance benefit
> > of removing the crypto_simd_usable() doesn't seem to be worth the footgun that
> > would be introduced.  Your position is, effectively, that if someone calls one
> > of the sha256*() functions from a hardirq, we should sometimes corrupt a random
> > task's FPU registers.  That's a really bad bug that is very difficult to
> > root-cause.  My position is that we should make it just work as expected.
> 
> kernel_fpu_begin already does a WARN_ON when called in hardirq
> context and it can't safely use the FPU, there is no silent
> corruption.

Only when CONFIG_X86_DEBUG_FPU is enabled, which people don't enable in
production.  And even if that is enabled, it's just a WARN, so the registers
still get used and corrupted anyway.

- Eric

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2025-04-27  1:02 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-26  6:50 [PATCH 00/13] Architecture-optimized SHA-256 library API Eric Biggers
2025-04-26  6:50 ` Eric Biggers
2025-04-26  6:50 ` [PATCH 01/13] crypto: sha256 - support arch-optimized lib and expose through shash Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-27  1:06   ` Herbert Xu
2025-04-27  1:06     ` Herbert Xu
2025-04-27  1:12     ` Eric Biggers
2025-04-27  1:12       ` Eric Biggers
2025-04-27  1:17       ` Herbert Xu
2025-04-27  1:17         ` Herbert Xu
2025-04-27  1:50         ` Eric Biggers
2025-04-27  1:50           ` Eric Biggers
2025-04-27  1:52           ` Herbert Xu
2025-04-27  1:52             ` Herbert Xu
2025-04-27  2:05             ` Eric Biggers
2025-04-27  2:05               ` Eric Biggers
2025-04-27  2:08               ` Herbert Xu
2025-04-27  2:08                 ` Herbert Xu
2025-04-26  6:50 ` [PATCH 02/13] crypto: arm/sha256 - implement library instead of shash Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  9:10   ` Ard Biesheuvel
2025-04-26  9:10     ` Ard Biesheuvel
2025-04-26  6:50 ` [PATCH 03/13] crypto: arm64/sha256 - remove obsolete chunking logic Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  9:07   ` Ard Biesheuvel
2025-04-26  9:07     ` Ard Biesheuvel
2025-04-26  6:50 ` [PATCH 04/13] crypto: arm64/sha256 - implement library instead of shash Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  9:07   ` Ard Biesheuvel
2025-04-26  9:07     ` Ard Biesheuvel
2025-04-26  6:50 ` [PATCH 05/13] crypto: mips/sha256 " Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 06/13] crypto: powerpc/sha256 " Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 07/13] crypto: riscv/sha256 " Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 08/13] crypto: s390/sha256 " Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 09/13] crypto: sparc - move opcodes.h into asm directory Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 10/13] crypto: sparc/sha256 - implement library instead of shash Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 11/13] crypto: x86/sha256 " Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26 10:50   ` Herbert Xu
2025-04-26 10:50     ` Herbert Xu
2025-04-26 18:03     ` Eric Biggers
2025-04-26 18:03       ` Eric Biggers
2025-04-27  0:18       ` Herbert Xu
2025-04-27  0:18         ` Herbert Xu
2025-04-27  1:02         ` Eric Biggers [this message]
2025-04-27  1:02           ` Eric Biggers
2025-04-27  5:21   ` Herbert Xu
2025-04-27  5:21     ` Herbert Xu
2025-04-26  6:50 ` [PATCH 12/13] crypto: sha256 - remove sha256_base.h Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26  6:50 ` [PATCH 13/13] crypto: lib/sha256 - improve function prototypes Eric Biggers
2025-04-26  6:50   ` Eric Biggers
2025-04-26 15:17 ` [PATCH 00/13] Architecture-optimized SHA-256 library API Linus Torvalds
2025-04-26 15:17   ` Linus Torvalds

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=20250427010248.GA68006@quark \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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.