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 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:   Fri, 6 Mar 2020 14:55:37 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Paul Blakey <paulb@...lanox.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 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