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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 8 Feb 2017 12:33:56 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Jiri Pirko <jiri@...nulli.us>
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

On Wed, Feb 8, 2017 at 12:12 PM, Jiri Pirko <jiri@...nulli.us> wrote:
> 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
>
I am merely suggesting that BPF offers a user programmable interface
that could allow implementing protocol support in the kernel for
functions like flow_dissector for protocols that we don't really want
explicit kernel code for. SOREUSEPORT-BPF is the canonical example of
such a capability.

Tom