netdev - Re: [oss-drivers] Re: [PATCH/RFC net-next 1/2] flow dissector: ND support

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Feb 2017 21:12:25 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Tom Herbert <tom@...bertland.com>
Cc:     David Miller <davem@...emloft.net>,
        Simon Horman <simon.horman@...ronome.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Dinan Gunawardena <dinan.gunawardena@...ronome.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [oss-drivers] Re: [PATCH/RFC net-next 1/2] flow dissector: ND
 support

Wed, Feb 08, 2017 at 08:10:06PM CET, tom@...bertland.com wrote:
>On Wed, Feb 8, 2017 at 10:54 AM, David Miller <davem@...emloft.net> wrote:
>> From: Tom Herbert <tom@...bertland.com>
>> Date: Wed, 8 Feb 2017 10:33:46 -0800
>>
>>> On Wed, Feb 8, 2017 at 1:28 AM, Simon Horman <simon.horman@...ronome.com> wrote:
>>>> I think the above paragraph gets back to Tom's original question regarding
>>>> making things more complex just for OvS (use-cases). Possibly ND is an edge
>>>> case even for OvS and on reflection my timing for posting it seems to have
>>>> been less than ideal.
>>>
>>> If it wasn't ND it would be something else... with all the activity
>>> happening in networking features and HW this is a timely discussion.
>>> Flow dissector presents a good example of a function that might become
>>> a dumping ground for an endless stream of features if we don't figure
>>> out how exercise some restraint.
>>
>> I agree on most points.
>>
>> But, I would say that in this specific case, since we have ARP support in
>> there already it behooves us to support the ipv6 side in the form of ND
>> too.
>>
>> Then we can put a line in the sand and say that future feature additions
>> in this area require serious discussion.
>>
>> Ok Tom?
>
>Right, ND is okay on the basis that we already have ARP (although I
>still may grumble from time to time that ARP, ND, and ICMP are being
>identified as flows ;-) ).
>
>I think there are two projects in the are that someone, maybe an
>aspiring kernel network developer, might want to look into if they
>have the time:
>
>- Inevitably someone will want to support VXLAN or other UDP
>encapsulations in flow dissector. The only correct way to do this is
>going to be to do a lookup on UDP socket and have a flow_dissector
>function related to the socket. This is the model for dealing with UDP
>encapsulations in GRO that could be extended for flow dissection. We
>cannot hard code port numbers in flow_dissector. The interesting part
>here will be making a robust interface to avoid the pitfalls we've
>seen in some of the protocols in flow_dissector.
>
>- Allow calling a BPF function to do custom flow dissection. IIRC
>there someone (Daniel?) had already implement flow_dissector in BPF
>with pretty good results.

How will this help us for cls_flower case? Are you suggesting to put this
whole BPF occult to the next level and use it kernel-to-kernel? :D