netdev - Re: [PATCH net-next 1/4] net/flow_dissector: add support for dissection of misc ip header fields

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]

Message-ID: <CAJ3xEMgfOO4fvR3OGdQC0hSZDKyDWy=yEuYA-jW0qd-girV3yw@mail.gmail.com>
Date:   Sat, 27 May 2017 19:29:49 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Tom Herbert <tom@...bertland.com>
Cc:     Or Gerlitz <ogerlitz@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Roi Dayan <roid@...lanox.com>, Paul Blakey <paulb@...lanox.com>
Subject: Re: [PATCH net-next 1/4] net/flow_dissector: add support for
 dissection of misc ip header fields

On Thu, May 25, 2017 at 6:42 PM, Tom Herbert <tom@...bertland.com> wrote:
> On Thu, May 25, 2017 at 6:24 AM, Or Gerlitz <ogerlitz@...lanox.com> wrote:
>> Add support for dissection of ip tos and ttl and ipv6 traffic-class
>> and hoplimit. Both are dissected into the same struct.

>> --- a/include/net/flow_dissector.h
>> +++ b/include/net/flow_dissector.h

>> +/**
>> + * struct flow_dissector_key_ip:
>> + * @tos: tos
>> + * @ttl: ttl
>> + */
>> +struct flow_dissector_key_ip {
>> +       __u8    tos;
>> +       __u8    ttl;
>> +};
>> +

> Looks like yet more complexity be piled onto flow dissector. Instead
> of splitting out individual fields can we just return a pointer to the
> IP header and let the caller extract the fields they're interested in?

Do you mean that struct flow_dissector_key_ip  will only contain
(union?) const struct iphdr * and const struct ipv6hdr * ? I wasn't
sure how would that further look on the kernel SW classification path
(the non offloaded case)