From: David Miller <davem@davemloft.net>
To: daniel@iogearbox.net
Cc: alexei.starovoitov@gmail.com, luto@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net] bpf: rework prog_digest into prog_tag
Date: Mon, 16 Jan 2017 14:03:54 -0500 (EST) [thread overview]
Message-ID: <20170116.140354.1715988456440754815.davem@davemloft.net> (raw)
In-Reply-To: <384476e29f6a378766c4052187b9b5f840f4030e.1484346362.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 13 Jan 2017 23:38:15 +0100
> Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
> fdinfo/netlink") was recently discussed, partially due to
> admittedly suboptimal name of "prog_digest" in combination
> with sha1 hash usage, thus inevitably and rightfully concerns
> about its security in terms of collision resistance were
> raised with regards to use-cases.
>
> The intended use cases are for debugging resp. introspection
> only for providing a stable "tag" over the instruction sequence
> that both kernel and user space can calculate independently.
> It's not usable at all for making a security relevant decision.
> So collisions where two different instruction sequences generate
> the same tag can happen, but ideally at a rather low rate. The
> "tag" will be dumped in hex and is short enough to introspect
> in tracepoints or kallsyms output along with other data such
> as stack trace, etc. Thus, this patch performs a rename into
> prog_tag and truncates the tag to a short output (64 bits) to
> make it obvious it's not collision-free.
>
> Should in future a hash or facility be needed with a security
> relevant focus, then we can think about requirements, constraints,
> etc that would fit to that situation. For now, rework the exposed
> parts for the current use cases as long as nothing has been
> released yet. Tested on x86_64 and s390x.
>
> Fixes: 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Applied, thanks.
prev parent reply other threads:[~2017-01-16 19:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 22:38 [PATCH net] bpf: rework prog_digest into prog_tag Daniel Borkmann
2017-01-13 23:16 ` Andy Lutomirski
2017-01-13 23:34 ` Alexei Starovoitov
2017-01-13 23:41 ` Daniel Borkmann
2017-01-13 23:49 ` Andy Lutomirski
2017-01-13 23:59 ` Daniel Borkmann
2017-01-16 19:03 ` David Miller [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=20170116.140354.1715988456440754815.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=luto@kernel.org \
--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 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).