linux-kernel - Re: [v3 PATCH 00/13] Architecture-optimized SHA-256 library API

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250429165749.GC1743@sol.localdomain>
Date: Tue, 29 Apr 2025 09:57:49 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
	sparclinux@...r.kernel.org, linux-s390@...r.kernel.org,
	x86@...nel.org, Ard Biesheuvel <ardb@...nel.org>,
	"Jason A . Donenfeld " <Jason@...c4.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [v3 PATCH 00/13] Architecture-optimized SHA-256 library API

On Mon, Apr 28, 2025 at 01:17:02PM +0800, Herbert Xu wrote:
> Changes in v3:
> - Add shash sha256-lib/sha224-lib to provide test coverage for libsha256.
> 
> This is based on
> 
> 	https://patchwork.kernel.org/project/linux-crypto/list/?series=957558
> 
> Original description:
> 
> Following the example of several other algorithms (e.g. CRC32, ChaCha,
> Poly1305, BLAKE2s), this series refactors the kernel's existing
> architecture-optimized SHA-256 code to be available via the library API,
> instead of just via the crypto_shash API as it was before.  It also
> reimplements the SHA-256 crypto_shash API on top of the library API.
> 
> This makes it possible to use the SHA-256 library in
> performance-critical cases.  The new design is also much simpler, with a
> negative diffstat of over 1200 lines.  Finally, this also fixes the
> longstanding issue where the arch-optimized SHA-256 was disabled by
> default, so people often forgot to enable it.
> 
> For now the SHA-256 library is well-covered by the crypto_shash
> self-tests, but I plan to add a test for the library directly later.
> I've fully tested this series on arm, arm64, riscv, and x86.  On mips,
> powerpc, s390, and sparc I've only been able to partially test it, since
> QEMU does not support the SHA-256 instructions on those platforms.  If
> anyone with access to a mips, powerpc, s390, or sparc system that has
> SHA-256 instructions can verify that the crypto self-tests still pass,
> that would be appreciated.  But I don't expect any issues, especially
> since the new code is more straightforward than the old code.
> 
> Eric Biggers (13):
>   crypto: sha256 - support arch-optimized lib and expose through shash
>   crypto: arm/sha256 - implement library instead of shash
>   crypto: arm64/sha256 - remove obsolete chunking logic
>   crypto: arm64/sha256 - implement library instead of shash
>   crypto: mips/sha256 - implement library instead of shash
>   crypto: powerpc/sha256 - implement library instead of shash
>   crypto: riscv/sha256 - implement library instead of shash
>   crypto: s390/sha256 - implement library instead of shash
>   crypto: sparc - move opcodes.h into asm directory
>   crypto: sparc/sha256 - implement library instead of shash
>   crypto: x86/sha256 - implement library instead of shash
>   crypto: sha256 - remove sha256_base.h
>   crypto: lib/sha256 - improve function prototypes

To be clear, the objections I have on your v2 patchset still hold.  Your
unsolicited changes to my patches add unnecessary complexity and redundancy,
make the crypto_shash API even harder to use correctly, and also break the build
for several architectures.  If you're going to again use your maintainer
privileges to push these out anyway over my objections, I'd appreciate it if you
at least made your dubious changes as incremental patches using your own
authorship so that they can be properly reviewed/blamed.

Please also note that I've sent a v4 which fixes the one real issue that my v1
patchset had: https://lore.kernel.org/r/20250428170040.423825-1-ebiggers@kernel.org

- Eric