[lkml]   [2017]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 7/8] net: Rename TCA*BPF_DIGEST to ..._SHA256
On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann <> wrote:
> Hi Andy,
> On 01/11/2017 04:11 AM, Andy Lutomirski wrote:
>> On Tue, Jan 10, 2017 at 4:50 PM, Daniel Borkmann <>
>> wrote:
>>> On 01/11/2017 12:24 AM, Andy Lutomirski wrote:
>>>> This makes it easier to add another digest algorithm down the road if
>>>> needed. It also serves to force any programs that might have been
>>>> written against a kernel that had the old field name to notice the
>>>> change and make any necessary changes.
>>>> This shouldn't violate any stable API policies, as no released kernel
>>>> has ever had TCA*BPF_DIGEST.
>>> Imho, this and patch 6/8 is not really needed. Should there ever
>>> another digest alg be used (doubt it), then you'd need a new nl
>>> attribute and fdinfo line anyway to keep existing stuff intact.
>>> Nobody made the claim that you can just change this underneath
>>> and not respecting abi for existing applications when I read from
>>> above that such apps now will get "forced" to notice a change.
>> Fair enough. I was more concerned about prerelease iproute2 versions,
>> but maybe that's a nonissue. I'll drop these two patches.
> Ok. Sleeping over this a bit, how about a general rename into
> "prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
> the netlink attributes, fwiw, it might reduce any assumptions on
> this being made? If this would be preferable, I could cook that
> patch against -net for renaming it?

That would be fine with me.

I think there are two reasonable approaches to computing the actual tag.

1. Use a standard, modern cryptographic hash. SHA-256, SHA-512,
Blake2b, whatever. SHA-1 is a bad choice in part because it's partly
broken and in part because the implementation in lib/ is a real mess
to use (as you noticed while writing the code).

2. Use whatever algorithm you like but make the tag so short that it's
obviously not collision-free. 48 or 64 bits is probably reasonable.

The intermediate versions are just asking for trouble. Alexei wants
to make the tag shorter, but I admit I still don't understand why he
prefers that over using a better crypto hash and letting user code
truncate the tag if it wants.

 \ /
  Last update: 2017-01-11 19:21    [W:0.090 / U:1.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site