All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Ard Biesheuvel <ardb@kernel.org>,
	Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>,
	linux-crypto@vger.kernel.org, Erik Kline <ek@google.com>,
	Fernando Gont <fgont@si6networks.com>,
	Lorenzo Colitti <lorenzo@google.com>,
	hideaki.yoshifuji@miraclelinux.com,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation
Date: Thu, 13 Jan 2022 00:05:44 +0100	[thread overview]
Message-ID: <87r19cftbr.fsf@toke.dk> (raw)
In-Reply-To: <20220112131204.800307-3-Jason@zx2c4.com>

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> BLAKE2s is faster and more secure. SHA-1 has been broken for a long time
> now. This also removes some code complexity, and lets us potentially
> remove sha1 from lib, which would further reduce vmlinux size.

So this one is a bit less obvious than the BPF case: the "stable address
generation" is supposed to result in generating addresses that are,
well, stable. The documentation for the stable_secret sysctl implies
that this should be for the lifetime of the system:

       It is recommended to generate this secret during installation
       of a system and keep it stable after that.

However, if we make this change, systems setting a stable_secret and
using addr_gen_mode 2 or 3 will come up with a completely different
address after a kernel upgrade. Which would be bad for any operator
expecting to be able to find their machine again after a reboot,
especially if it is accessed remotely.

I haven't ever used this feature myself, though, or seen it in use. So I
don't know if this is purely a theoretical concern, or if the
stable_address feature is actually used in this way in practice. If it
is, I guess the switch would have to be opt-in, which kinda defeats the
purpose, no (i.e., we'd have to keep the SHA1 code around)?

Adding some of the people involved in the original work on stable
address generation in the hope that they can shed some light on the
real-world uses for this feature.

-Toke

> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
>  net/ipv6/addrconf.c | 31 +++++++++----------------------
>  1 file changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 3445f8017430..f5cb534aa261 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -61,7 +61,7 @@
>  #include <linux/delay.h>
>  #include <linux/notifier.h>
>  #include <linux/string.h>
> -#include <linux/hash.h>
> +#include <crypto/blake2s.h>
>  
>  #include <net/net_namespace.h>
>  #include <net/sock.h>
> @@ -3225,25 +3225,16 @@ static int ipv6_generate_stable_address(struct in6_addr *address,
>  					const struct inet6_dev *idev)
>  {
>  	static DEFINE_SPINLOCK(lock);
> -	static __u32 digest[SHA1_DIGEST_WORDS];
> -	static __u32 workspace[SHA1_WORKSPACE_WORDS];
> -
> -	static union {
> -		char __data[SHA1_BLOCK_SIZE];
> -		struct {
> -			struct in6_addr secret;
> -			__be32 prefix[2];
> -			unsigned char hwaddr[MAX_ADDR_LEN];
> -			u8 dad_count;
> -		} __packed;
> -	} data;
> -
> +	struct {
> +		struct in6_addr secret;
> +		__be32 prefix[2];
> +		unsigned char hwaddr[MAX_ADDR_LEN];
> +		u8 dad_count;
> +	} __packed data;
>  	struct in6_addr secret;
>  	struct in6_addr temp;
>  	struct net *net = dev_net(idev->dev);
>  
> -	BUILD_BUG_ON(sizeof(data.__data) != sizeof(data));
> -
>  	if (idev->cnf.stable_secret.initialized)
>  		secret = idev->cnf.stable_secret.secret;
>  	else if (net->ipv6.devconf_dflt->stable_secret.initialized)
> @@ -3254,20 +3245,16 @@ static int ipv6_generate_stable_address(struct in6_addr *address,
>  retry:
>  	spin_lock_bh(&lock);
>  
> -	sha1_init(digest);
>  	memset(&data, 0, sizeof(data));
> -	memset(workspace, 0, sizeof(workspace));
>  	memcpy(data.hwaddr, idev->dev->perm_addr, idev->dev->addr_len);
>  	data.prefix[0] = address->s6_addr32[0];
>  	data.prefix[1] = address->s6_addr32[1];
>  	data.secret = secret;
>  	data.dad_count = dad_count;
>  
> -	sha1_transform(digest, data.__data, workspace);
> -
>  	temp = *address;
> -	temp.s6_addr32[2] = (__force __be32)digest[0];
> -	temp.s6_addr32[3] = (__force __be32)digest[1];
> +	blake2s((u8 *)&temp.s6_addr32[2], (u8 *)&data, NULL,
> +		sizeof(temp.s6_addr32[2]) * 2, sizeof(data), 0);
>  
>  	spin_unlock_bh(&lock);
>  
> -- 
> 2.34.1


  parent reply	other threads:[~2022-01-12 23:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-12 13:12 [PATCH RFC v1 0/3] remove remaining users of SHA-1 Jason A. Donenfeld
2022-01-12 13:12 ` [PATCH RFC v1 1/3] bpf: move from sha1 to blake2s in tag calculation Jason A. Donenfeld
2022-01-12 22:56   ` Toke Høiland-Jørgensen
2022-01-13  1:33     ` Alexei Starovoitov
2022-01-13 12:27       ` Jason A. Donenfeld
2022-01-13 22:45         ` Alexei Starovoitov
2022-01-14  8:33           ` Geert Uytterhoeven
2022-01-14 14:12           ` Jason A. Donenfeld
2022-01-14 15:08             ` Ard Biesheuvel
2022-01-14 15:20               ` Jason A. Donenfeld
2022-01-14 15:36                 ` Geert Uytterhoeven
2022-01-14 15:59                 ` David Laight
2022-01-14 16:19               ` Alexei Starovoitov
2022-01-14 16:34                 ` Jason A. Donenfeld
2022-01-14 23:04     ` Jeffrey Walton
2022-01-12 13:12 ` [PATCH RFC v1 2/3] ipv6: move from sha1 to blake2s in address calculation Jason A. Donenfeld
2022-01-12 15:49   ` Jason A. Donenfeld
2022-01-12 23:05   ` Toke Høiland-Jørgensen [this message]
2022-01-12 23:31     ` Jason A. Donenfeld
2022-01-13 11:15       ` Hannes Frederic Sowa
2022-01-13 12:06         ` Ard Biesheuvel
2022-01-13 12:22           ` Jason A. Donenfeld
2022-01-13 12:29             ` Ard Biesheuvel
2022-01-13 13:30           ` Toke Høiland-Jørgensen
2022-01-13 13:40             ` Ard Biesheuvel
2022-01-13 13:45             ` Jason A. Donenfeld
2022-01-13 13:50               ` Ard Biesheuvel
2022-01-13 13:54                 ` Jason A. Donenfeld
2022-01-13 16:18                   ` Toke Høiland-Jørgensen
2022-01-14 16:07         ` Jason A. Donenfeld
2022-01-14 16:57           ` Toke Høiland-Jørgensen
2022-01-14 17:41           ` Hannes Frederic Sowa
2022-01-14 17:58             ` Jason A. Donenfeld
2022-01-12 13:12 ` [PATCH RFC v1 3/3] crypto: sha1_generic - import lib/sha1.c locally Jason A. Donenfeld
2022-01-12 18:50 ` [PATCH RFC v1 0/3] remove remaining users of SHA-1 David Sterba
2022-01-12 18:57   ` Jason A. Donenfeld
2022-01-13  3:24 ` Sandy Harris
2022-01-13  8:08   ` Ard Biesheuvel
2022-01-13 17:28   ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r19cftbr.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=ek@google.com \
    --cc=fgont@si6networks.com \
    --cc=geert@linux-m68k.org \
    --cc=hannes@stressinduktion.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=hideaki.yoshifuji@miraclelinux.com \
    --cc=jeanphilippe.aumasson@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.