linux-kernel - Re: [GIT PULL] Crypto Update for 6.15

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: <CAHk-=whoeJQqyn73_CQVVhMXjb7-C_atv2m6s_Ssw7Ln9KfpTg@mail.gmail.com>
Date: Sat, 29 Mar 2025 10:40:23 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller" <davem@...emloft.net>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [GIT PULL] Crypto Update for 6.15

On Tue, 25 Mar 2025 at 08:25, Eric Biggers <ebiggers@...nel.org> wrote:
>
> Each hash request can also contain an entire scatterlist.  It's overkill for
> what is actually needed for multibuffer hashing, which is a simple API that
> hashes two buffers specified by virtual address.  Herbert's API creates lots of
> unnecessary edge cases, most of which lack any testing.

Isn't that the whole *point* of the generic crypto layer?

Honestly, I think anybody who cares about modern CPU-based crypto
should do what wireguard did: stop using the generic crypto layer,
because it's fundamentally designed for odd async hardware in strange
*legacy* models, and the whole basic design is around the indirection
that allows different crypto engines.

Because that's the *point* of that code. I mean, a large part of the
*design* of it is centered around having external crypto engines. And
the thing you worry about is pretty much the opposite of that.

So if what you want is just fast modern crypto on the CPU, the generic
interfaces are just odd and complicated.

Yes, they get less complicated if you limit yourself to the
synchronous interfaces - which is, as you point out - why most people
do exactly that.

Put another way: I don't disagree with you, but at the same time my
reaction is that the generic crypto layer does what it has always
done.

I get the feeling that you are arguing for avoiding the overheads and
abstractions, and I'm not disagreeing. But overheads and abstractions
is what that crypto layer is *for*.

I mean, you can do

        tfm = crypto_alloc_shash("crc32c", 0, 0);

and jump through the crazy hoops with the indirection of going through
that tfm ("transformation object") that allocates a lot of extra info
and works with other things. And it's designed to work with various
non-CPU addresses etc.

Or you can just do

        crc = crc32c(crc, virt, cur_len);

and you're done - at the cost of only working with regular virtually
mapped addresses. Your choice.

So I think you want to do the wireguard thing, and use the fixed and
simple cases.

Yes, those interfaces only exist for a subset of things, but I think
that subset of things is (a) the relevant subset and (b) the ones
you'd do the whole parallel execution for anyway (afaik you did
sha256).

              Linus