netdev - Re: [PATCH net-next ct-offload 02/13] net/sched: act_ct: Instantiate flow table entry actions

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: <acdcef0b-8b44-6544-59e1-0868296ea20f@mellanox.com>
Date:   Sun, 8 Mar 2020 11:41:26 +0200
From:   Paul Blakey <paulb@...lanox.com>
To:     Edward Cree <ecree@...arflare.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Oz Shlomo <ozsh@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>
Subject: Re: [PATCH net-next ct-offload 02/13] net/sched: act_ct: Instantiate
 flow table entry actions


On 3/6/2020 4:55 PM, Edward Cree wrote:
> On 06/03/2020 13:22, Paul Blakey wrote:
>> On 06/03/2020 13:35, Edward Cree wrote:
>>> I'm not quite sure what the zone is doing in the action.  Surely it's
>>>  a property of the match.  Or does this set a ct_zone for a potential
>>>  *second* conntrack lookup?
>> this is part of the metadata that driver should mark the with, as it can be matched against in following hardware tables/rules. consider this set of offloaded rules:
> <snip>
> So, normally I'd expect to use different chains for the different zones.
> But I can see that in theory you might want to have some rules shared by
>  both, hence being able to put them in the same chain is useful.
>
> Assuming an idealised model of the hardware, with three stages:
> * "left-hand rule" - in chain 0, match -trk, action "ct and goto chain"
> * "conntrack lookup" - match 5-tuple, return NATted 5-tuple + some flags
> * "right-hand rule" - in chain !=0, match +trk(±others), many actions
> The zone is set by the left-hand rule, it's a (semi-)implicit input to
>  the conntrack lookup, and it can be an explicit match field of the
>  right-hand rule (as it is in your example).
> But from a logical perspective, the conntrack lookup isn't *producing*
>  the zone as an output, it's just forwarding on the zone that was fed to
>  it by the left-hand rule.
> So, the conntrack entry, which already has the zone in its
>  struct flow_match (. struct flow_match_ct .key->ct_zone), doesn't need
>  to specify the zone *again* in the action.  If the driver needs to
>  supply that piece of information a second time in the action metadata
>  for the conntrack action, that's a hardware-specific implementation
>  detail.
> Or so it seems to me, anyway.
>
> -ed
I will remove this from the metadata action, and the driver will learn
the zone by keeping it in the cb_priv while they register for the flowtable.

Paul.