From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH net] bpf: rework prog_digest into prog_tag Date: Sat, 14 Jan 2017 00:59:19 +0100 Message-ID: <587969D7.5010806@iogearbox.net> References: <384476e29f6a378766c4052187b9b5f840f4030e.1484346362.git.daniel@iogearbox.net> <58796595.3030904@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Alexei Starovoitov , Andrew Lutomirski , Network Development To: Andy Lutomirski Return-path: Received: from www62.your-server.de ([213.133.104.62]:52440 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718AbdAMX7Y (ORCPT ); Fri, 13 Jan 2017 18:59:24 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 01/14/2017 12:49 AM, Andy Lutomirski wrote: > On Fri, Jan 13, 2017 at 3:41 PM, Daniel Borkmann wrote: >> On 01/14/2017 12:16 AM, Andy Lutomirski wrote: >>> On Fri, Jan 13, 2017 at 2:38 PM, Daniel Borkmann >>> wrote: >>>> >>>> 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. >>> >>> Seems reasonable. My only question is whether you'd still want to >>> switch to SHA-256 just from a code cleanliness perspective. With >>> SHA-256 you can use the easy streaming API I wrote, but with SHA-1 >>> you're still stuck with the crappy API in lib/, and I'm not >>> volunteering to fix up the SHA-1 API. >> >> We'd need to truncate that in kernel anyway to not get a too long >> tag, so given that I'm actually fine with it as-is. I was planning >> to submit the code for testing to bpf selftests for net-next once >> it's merged back, too. > > Unless you want to kill off that vmalloc()+vfree() pair... That is really just in slow-path, and should that become a bottleneck compared to the rest of the verification steps or allocs we do there, then we can always clean it up in net-next. Thanks, Daniel