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
| ||
|
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
Powered by blists - more mailing lists