[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tue8ftrm.fsf@toke.dk>
Date: Wed, 12 Jan 2022 23:56:13 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Ard Biesheuvel <ardb@...nel.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>,
linux-crypto@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH RFC v1 1/3] bpf: move from sha1 to blake2s in tag
calculation
[ adding the bpf list - please make sure to include that when sending
BPF-related patches, not everyone in BPF land follows netdev ]
"Jason A. Donenfeld" <Jason@...c4.com> writes:
> BLAKE2s is faster and more secure. SHA-1 has been broken for a long time
> now. This also removes quite a bit of code, and lets us potentially
> remove sha1 from lib, which would further reduce vmlinux size.
AFAIU, the BPF tag is just used as an opaque (i.e., arbitrary) unique
identifier for BPF programs, without any guarantees of stability. Which
means changing it should be fine; at most we'd confuse some operators
who have memorised the tags of their BPF programs :)
The only other concern I could see would be if it somehow locked us into
that particular algorithm for other future use cases for computing
hashes of BPF programs (say, signing if that ends up being the direction
we go in). But obviously SHA1 would not be a good fit for that anyway,
so the algorithm choice would have to be part of that discussion in any
case.
So all in all, I don't see any issues with making this change for BPF.
-Toke
> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
> Cc: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: Ard Biesheuvel <ardb@...nel.org>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
> Cc: linux-crypto@...r.kernel.org
> Signed-off-by: Jason A. Donenfeld <Jason@...c4.com>
> ---
> kernel/bpf/core.c | 39 ++++-----------------------------------
> 1 file changed, 4 insertions(+), 35 deletions(-)
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 2405e39d800f..d01976749467 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -33,6 +33,7 @@
> #include <linux/extable.h>
> #include <linux/log2.h>
> #include <linux/bpf_verifier.h>
> +#include <crypto/blake2s.h>
>
> #include <asm/barrier.h>
> #include <asm/unaligned.h>
> @@ -265,24 +266,16 @@ void __bpf_prog_free(struct bpf_prog *fp)
>
> int bpf_prog_calc_tag(struct bpf_prog *fp)
> {
> - const u32 bits_offset = SHA1_BLOCK_SIZE - sizeof(__be64);
> u32 raw_size = bpf_prog_tag_scratch_size(fp);
> - u32 digest[SHA1_DIGEST_WORDS];
> - u32 ws[SHA1_WORKSPACE_WORDS];
> - u32 i, bsize, psize, blocks;
> struct bpf_insn *dst;
> bool was_ld_map;
> - u8 *raw, *todo;
> - __be32 *result;
> - __be64 *bits;
> + u8 *raw;
> + int i;
>
> raw = vmalloc(raw_size);
> if (!raw)
> return -ENOMEM;
>
> - sha1_init(digest);
> - memset(ws, 0, sizeof(ws));
> -
> /* We need to take out the map fd for the digest calculation
> * since they are unstable from user space side.
> */
> @@ -307,31 +300,7 @@ int bpf_prog_calc_tag(struct bpf_prog *fp)
> }
> }
>
> - psize = bpf_prog_insn_size(fp);
> - memset(&raw[psize], 0, raw_size - psize);
> - raw[psize++] = 0x80;
> -
> - bsize = round_up(psize, SHA1_BLOCK_SIZE);
> - blocks = bsize / SHA1_BLOCK_SIZE;
> - todo = raw;
> - if (bsize - psize >= sizeof(__be64)) {
> - bits = (__be64 *)(todo + bsize - sizeof(__be64));
> - } else {
> - bits = (__be64 *)(todo + bsize + bits_offset);
> - blocks++;
> - }
> - *bits = cpu_to_be64((psize - 1) << 3);
> -
> - while (blocks--) {
> - sha1_transform(digest, todo, ws);
> - todo += SHA1_BLOCK_SIZE;
> - }
> -
> - result = (__force __be32 *)digest;
> - for (i = 0; i < SHA1_DIGEST_WORDS; i++)
> - result[i] = cpu_to_be32(digest[i]);
> - memcpy(fp->tag, result, sizeof(fp->tag));
> -
> + blake2s(fp->tag, raw, NULL, sizeof(fp->tag), bpf_prog_insn_size(fp), 0);
> vfree(raw);
> return 0;
> }
> --
> 2.34.1
Powered by blists - more mailing lists