netdev - Re: [PATCH net] bpf: rework prog_digest into prog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20170116.140354.1715988456440754815.davem@davemloft.net>
Date:   Mon, 16 Jan 2017 14:03:54 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     daniel@...earbox.net
Cc:     alexei.starovoitov@...il.com, luto@...nel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] bpf: rework prog_digest into prog_tag

From: Daniel Borkmann <daniel@...earbox.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@...earbox.net>
> Acked-by: Alexei Starovoitov <ast@...nel.org>

Applied, thanks.