From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Eric Dumazet <edumazet@google.com>,
Eric Biggers <ebiggers3@gmail.com>,
Tom Herbert <tom@herbertland.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v2 0/8] Switch BPF's digest to SHA256
Date: Tue, 10 Jan 2017 17:09:42 -0800 [thread overview]
Message-ID: <20170111010940.GA74000@ast-mbp.thefacebook.com> (raw)
In-Reply-To: <cover.1484090585.git.luto@kernel.org>
On Tue, Jan 10, 2017 at 03:24:38PM -0800, Andy Lutomirski wrote:
> I can imagine future uses for the new-in-4.10 BPF digest feature that
> would be problematic if malicious users could produce collisions, and
> SHA-1 is no longer consdiered to be collision-free. Even without
> needing collision resistance, SHA-1 is no longer recommended for new
> applications. Switch the BPF digest to SHA-256 instead.
Using this reasoning we must immediately change 'git' to use sha256
as well. malicious users are coming!
Seriously, NACK for bpf bits again, since you somehow missed
the reasons I gave earlier, here they are again:
.......
This statement is also bogus. The only reason we added prog_digest is
to improve debuggability and introspection of bpf programs.
As I said in the previous thread "collisions are ok" and we could have
used jhash here to avoid patches like this ever appearing
and wasting everyones time.
sha1 is 20 bytes which is already a bit long to print and copy paste by humans.
whereas 4 byte jhash is a bit too short, since collisions are not that rare
and may lead to incorrect assumptions from the users that develop the programs.
I would prefer something in 6-10 byte range that prevents collisions most of
the time and short to print as hex, but I don't know of anything like this
in the existing kernel and inventing bpf specific hash is not great.
Another requirement for debugging (and prog_digest) that user space
should be able to produce the same hash without asking kernel, so
sha1 fits that as well, since it's well known and easy to put into library.
sha256 doesn't fit either of these requirements. 32-bytes are too long to print
and when we use it as a substitue for the prog name for jited ksym, looking
at long function names will screw up all tools like perf, which we don't
want. sha256 is equally not easy for user space app like iproute2,
so not an acceptable choice from that pov either.
...........
tldr: I see only Cons for sha1->sha256 switch. Not a single Pro, hence
nack for bpf patches 4+
The patches 1-3 are nice and useful on their own.
prev parent reply other threads:[~2017-01-11 1:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 23:24 [PATCH v2 0/8] Switch BPF's digest to SHA256 Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 1/8] crypto/sha256: Factor out the parts of base API that don't use shash_desc Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 2/8] crypto/sha256: Export a sha256_{init,update,final}_direct() API Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 3/8] crypto/sha256: Build the SHA256 core separately from the crypto module Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 4/8] bpf: Use SHA256 instead of SHA1 for bpf digests Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 5/8] bpf: Avoid copying the entire BPF program when hashing it Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 6/8] bpf: Rename fdinfo's prog_digest to prog_sha256 Andy Lutomirski
2017-01-10 23:24 ` [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256 Andy Lutomirski
2017-01-11 0:50 ` Daniel Borkmann
2017-01-11 3:11 ` Andy Lutomirski
2017-01-11 9:09 ` Daniel Borkmann
2017-01-11 18:19 ` Andy Lutomirski
2017-01-13 23:08 ` Daniel Borkmann
2017-01-10 23:24 ` [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests Andy Lutomirski
2017-01-11 15:13 ` David Laight
2017-01-11 18:10 ` Andy Lutomirski
2017-01-12 7:47 ` Herbert Xu
2017-01-12 7:52 ` Andy Lutomirski
2017-01-12 16:44 ` Herbert Xu
2017-01-11 1:09 ` Alexei Starovoitov [this message]
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=20170111010940.GA74000@ast-mbp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=Jason@zx2c4.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ebiggers3@gmail.com \
--cc=edumazet@google.com \
--cc=hannes@stressinduktion.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).