netdev - Re: [PATCH net-next 4/6] net/sched: allow flower to match tunnel options

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:   Tue, 7 Aug 2018 20:44:17 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Simon Horman <simon.horman@...ronome.com>
Cc:     David Miller <davem@...emloft.net>, Jiri Pirko <jiri@...lanox.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 4/6] net/sched: allow flower to match tunnel options

On Tue, Aug 7, 2018 at 6:36 PM, Simon Horman <simon.horman@...ronome.com> wrote:
> From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@...ronome.com>
>
> Allow matching on options in Geneve tunnel headers.
> This makes use of existing tunnel metadata support.
>
> The options can be described in the form
> CLASS:TYPE:DATA/CLASS_MASK:TYPE_MASK:DATA_MASK, where CLASS is
> represented as a 16bit hexadecimal value, TYPE as an 8bit
> hexadecimal value and DATA as a variable length hexadecimal value.
>
> e.g.
>  # ip link add name geneve0 type geneve dstport 0 external
>  # tc qdisc add dev geneve0 ingress
>  # tc filter add dev geneve0 protocol ip parent ffff: \
>      flower \
>        enc_src_ip 10.0.99.192 \
>        enc_dst_ip 10.0.99.193 \
>        enc_key_id 11 \
>        geneve_opts 0102:80:1122334421314151/ffff:ff:ffffffffffffffff \
>        ip_proto udp \
>        action mirred egress redirect dev eth1
>
> This patch adds support for matching Geneve options in the order
> supplied by the user. This leads to an efficient implementation in
> the software datapath (and in our opinion hardware datapaths that
> offload this feature). It is also compatible with Geneve options
> matching provided by the Open vSwitch kernel datapath which is
> relevant here as the Flower classifier may be used as a mechanism
> to program flows into hardware as a form of Open vSwitch datapath
> offload (sometimes referred to as OVS-TC). The netlink
> Kernel/Userspace API may be extended, for example by adding a flag,
> if other matching options are desired, for example matching given
> options in any order. This would require an implementation in the
> TC software datapath. And be done in a way that drivers that
> facilitate offload of the Flower classifier can reject or accept
> such flows based on hardware datapath capabilities.
>
> This approach was discussed and agreed on at Netconf 2018 in Seoul.

2017, please fix

2018 was in Montreal