[ Resending this v3, because the previous one was so deeply nested
inside other patchset threads that b4 was unable to extract it without
getting terribly confused. And if b4 was confused, probably human
readers were too. This new cover letter is a new root thread. ]
Hi,
Geert emailed me this afternoon concerned about blake2s codesize on m68k
and other small systems. We identified two effective ways of chopping
down the size. One of them moves some wireguard-specific things into
wireguard proper. The other one adds a slower codepath for small
machines to blake2s. This worked, and was v1 of this patchset, but I
wasn't so much of a fan. Then someone pointed out that the generic C
SHA-1 implementation is still unrolled, which is a *lot* of extra code.
Simply rerolling that saves about as much as v1 did. So, we instead do
that in this patchset. SHA-1 is being phased out, and soon it won't
be included at all (hopefully). And nothing performance-oriented has
anything to do with it anyway.
The result of these two patches mitigates Geert's feared code size
increase for 5.17.
v3 improves on v2 by making the re-rolling of SHA-1 much simpler,
resulting in even larger code size reduction and much better
performance. The reason I'm sending yet a third version in such a short
amount of time is because the trick here feels obvious and substantial
enough that I'd hate for Geert to waste time measuring the impact of the
previous commit.
Thanks,
Jason
Jason A. Donenfeld (2):
lib/crypto: blake2s: move hmac construction into wireguard
lib/crypto: sha1: re-roll loops to reduce code size
drivers/net/wireguard/noise.c | 45 ++++++++++++++---
include/crypto/blake2s.h | 3 --
lib/crypto/blake2s-selftest.c | 31 ------------
lib/crypto/blake2s.c | 37 --------------
lib/sha1.c | 95 ++++++-----------------------------
5 files changed, 53 insertions(+), 158 deletions(-)
--
2.34.1
On Tue, Jan 18, 2022 at 1:45 PM David Laight <[email protected]> wrote:
> I've rammed the code through godbolt... https://godbolt.org/z/Wv64z9zG8
>
> Some things I've noticed;
It seems like you've done a lot of work here but...
> But I've not got time to test the code.
But you're not going to take it all the way. So it unfortunately
amounts to mailing list armchair optimization. That's too bad because
it really seems like you might be onto something worth seeing through.
As I've mentioned a few times now, I've dropped the blake2s
optimization patch, and I won't be developing that further. But it
appears as though you've really been captured by it, so I urge you:
please send a real patch with benchmarks on various platforms! (And CC
me on the patch.) Faster reference code would really be terrific.
Jason