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: Wed, 25 Sep 2019 18:01:54 +0100 From: Edward Cree <ecree@...arflare.com> To: Paul Blakey <paulb@...lanox.com>, Jakub Kicinski <jakub.kicinski@...ronome.com> CC: Pravin Shelar <pshelar@....org>, Daniel Borkmann <daniel@...earbox.net>, Vlad Buslov <vladbu@...lanox.com>, David Miller <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Jiri Pirko <jiri@...nulli.us>, Cong Wang <xiyou.wangcong@...il.com>, Jamal Hadi Salim <jhs@...atatu.com>, Simon Horman <simon.horman@...ronome.com>, Or Gerlitz <gerlitz.or@...il.com> Subject: Re: CONFIG_NET_TC_SKB_EXT On 24/09/2019 12:48, Paul Blakey wrote: > The 'miss' for all or nothing is easy, but the hard part is combining > all the paths a packet can take in software to a single 'all or nothing' > rule in hardware. But you don't combine them to a single rule in hardware, because you have multiple sequential tables. (I just spent the last few weeks telling our hardware guys that no, they can't just give us one big table and expect the driver to do all that combining, because as you say, it's 'the hard part'.) > What if you 'miss' on the match for the tuple? You already did some > processing in hardware, so either you revert those, or you continue in > software where you left off (the action ct). But the only processing you did was to match stuff and generate metadata in the form of lookup keys (e.g. a ct_zone) for the next round of matching. There's nothing to "revert" unless you've actually modified the packet before sending it to CT, and as I said I don't believe that's worth supporting. > The all or nothing approach will require changing the software model to > allow > > merging the ct zone table matches into the hardware rules I don't know how much more clearly I can say this: all-or-nothing does not require merging. It just requires any actions that come before a matching stage (and that the hw doesn't have the capability to revert) to put a rule straight in the 'nothing' bucket. So if you write chain 0 dst_mac aa:bb:cc:dd:ee:ff ct_state -trk action vlan push blah action ct action goto chain X the driver can say -EOPNOTSUPP because you pushed a VLAN and might still miss in chain X. But if you write chain 0 dst_mac aa:bb:cc:dd:ee:ff ct_state -trk action ct action goto chain X then the driver will happily offload that because if you miss in the later lookups you've not altered the packet — the chain0-rule is *idempotent* so it doesn't matter if HW and SW both perform it. (Or even all three of HW, tc and OvS.)
Powered by blists - more mailing lists