linux-kernel - Re: [PATCH v2 00/17] SHA-512 library functions

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250617192212.GA1365424@google.com>
Date: Tue, 17 Jun 2025 19:22:12 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
	sparclinux@...r.kernel.org, x86@...nel.org,
	Ard Biesheuvel <ardb@...nel.org>,
	"Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH v2 00/17] SHA-512 library functions

On Tue, Jun 17, 2025 at 11:29:15AM -0700, Linus Torvalds wrote:
> On Mon, 16 Jun 2025 at 23:05, Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > An additional note on testing: [..]
> 
> Talking about testing - when adding test scripts, can you do it as a
> separate thing entirely - either before or after?
> 
> As it is, this code movement is hard to judge just because the stats
> are all messed up with new tests:
> 
>  77 files changed, 4012 insertions(+), 1756 deletions(-)
> 
> that's 2k+ new lines of code that pretty much entirely hides the
> question of "did this code movement result in a simpler / same / more
> complex end result".
> 
> So in general, I'd really prefer big re-organizations to be *separate*
> from new code changes.
> 
> It's just a pain to review renaming when it's mixed up with other
> changes - whether renaming variables or whole files.
> 
> And that's as true on an individual commit level (we try to avoid
> renaming things *and* making other changes in one go) as it is on a
> pull request level.
> 
> If I see a pull request that only adds new tests, it's a no-brainer.
> 
> If I see a pull request that only re-organizes the code and the
> diffstat just just renames with some small updates for new locations,
> it's a no-brainer.
> 
> If I see a pull request that does both, it's a pain in the arse,
> because then I need to start to look into individual commits and go
> "which does what".

The tests are already in their own patches: patches 4 and 5.  Yes, this patchset
has a negative diffstat once you subtract them.

(And most of the positive diffstat in the tests is generated test vectors.  The
rest is mostly code that I'll reuse later in tests for other hash functions; it
just gets blamed to this one because it's the first one.)

I'd really prefer to keep testing as a first-class citizen.  Tests should be
contributed along with the code itself.

And the point of this patchset is not just "code movement", but rather adding a
library API, including documentation *and tests*.

Later, I'll be converting various in-kernel users to use that API, just as I've
been doing for crc32 and sha256.  It's already been shown that the
"librarification" works well and is much simpler than the old-school Crypto API.

If you really want patches 4-5 in a separate patchset that's based on this one,
I can do that.  Ultimately, the result would be the same.

I think your request for there to be a separate "tests" pull request is a
non-starter, though.  That would imply separate git trees, and we then wouldn't
be able to land tests at the same time as the code itself.

- Eric