netdev - Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in cls_flower and act_tunnel

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

Message-ID: <20171005145130.1f9bd7c4@griffin>
Date:   Thu, 5 Oct 2017 14:51:30 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     Simon Horman <simon.horman@...ronome.com>
Cc:     David Miller <davem@...emloft.net>, jiri@...lanox.com,
        jhs@...atatu.com, xiyou.wangcong@...il.com, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in
 cls_flower and act_tunnel_key

On Mon, 2 Oct 2017 09:50:15 +0200, Simon Horman wrote:
> I believe that in order to avoid per-packet overhead and at the same time
> code complexity the TLVs should be described in-order. So matching on
> TLV-A,TLV-B,TLV-C would be a different match to TLV-C,TLV-A,TLV-B.  An
> order-independent match could be added if desired in future.

Although better than the binary format, I doubt that it would be
useful. I can't imagine a real use case where you would want such match.

Instead, what you want is a match on a particular TLV, wherever it is
in the data. For start, we can support just a single TLV.

I.e. when matching on TLV-A, all of these would match:
TLV-A,TLV-B,TLV-C; TLV-B,TLV-A,TLV-C; TLV-B,TLV-C,TLV-A. And this one
won't match: TLV-B,TLV-C,TLV-D.

 Jiri