[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220111181037.632969-1-Jason@zx2c4.com>
Date: Tue, 11 Jan 2022 19:10:35 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: linux-crypto@...r.kernel.org, netdev@...r.kernel.org,
wireguard@...ts.zx2c4.com, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, geert@...ux-m68k.org, tytso@....edu,
gregkh@...uxfoundation.org, jeanphilippe.aumasson@...il.com,
ardb@...nel.org
Cc: "Jason A. Donenfeld" <Jason@...c4.com>
Subject: [PATCH crypto v2 0/2] reduce code size from blake2s on m68k and other small platforms
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 v2 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.
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 | 117 ++++++++--------------------------
5 files changed, 64 insertions(+), 169 deletions(-)
--
2.34.1
Powered by blists - more mailing lists