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] [day] [month] [year] [list]
Date:   Sun, 8 Mar 2020 11:41:26 +0200
From:   Paul Blakey <>
To:     Edward Cree <>,
        Saeed Mahameed <>,
        Oz Shlomo <>,
        Jakub Kicinski <>,
        Vlad Buslov <>,
        David Miller <>,
        "" <>,
        Jiri Pirko <>, Roi Dayan <>
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.


Powered by blists - more mailing lists