netdev - Re: [PATCH net-next v3] net: openvswitch: Set OvS recirc

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Sep 2019 07:13:46 +0000
From:   Paul Blakey <paulb@...lanox.com>
To:     Edward Cree <ecree@...arflare.com>,
        Pravin B Shelar <pshelar@....org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Justin Pettit <jpettit@...ira.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Vlad Buslov <vladbu@...lanox.com>
CC:     Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        Rony Efraim <ronye@...lanox.com>, Oz Shlomo <ozsh@...lanox.com>
Subject: Re: [PATCH net-next v3] net: openvswitch: Set OvS recirc_id from tc
 chain index

On 9/3/2019 5:56 PM, Edward Cree wrote:
> On 03/09/2019 14:23, Paul Blakey wrote:
>> Offloaded OvS datapath rules are translated one to one to tc rules,
>> for example the following simplified OvS rule:
>>
>> recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2)
>>
>> Will be translated to the following tc rule:
>>
>> $ tc filter add dev dev1 ingress \
>> 	    prio 1 chain 0 proto ip \
>> 		flower tcp ct_state -trk \
>> 		action ct pipe \
>> 		action goto chain 2
>>
>> Received packets will first travel though tc, and if they aren't stolen
>> by it, like in the above rule, they will continue to OvS datapath.
>> Since we already did some actions (action ct in this case) which might
>> modify the packets, and updated action stats, we would like to continue
>> the proccessing with the correct recirc_id in OvS (here recirc_id(2))
>> where we left off.
> IMHO each offload (OvS -> tc, and tc -> hw) ought only take place for a rule
>   if all sequelae of that rule are also offloaded, or if non-offloaded sequelae
>   can be guaranteed to provide an unmodified packet so that the exception path
>   can start from the beginning.  I don't like this idea of doing part of the
>   processing in one place and then resuming the rest later in an entirely
>   different piece of code.

We hope to replicate the entire software module to hardware, not just tc.

For tc offloading, we currently offload tc rules one by one, including 
tc chains rules (match on chain, and goto chain action),

and the offloaded rules might not catch all packets:

tc fiter add dev1 ..... chain 0 ... flower dst_mac aa:bb:cc:dd:ee:ff 
action pedit munge ex set dst src 12:34:56:78:aa:bb action goto chain 5

tc fiter add dev1 ..... chain 5 ... flower ip_proto UDP action mirred 
egress redirect dev dev2

If the packet isn't UDP we miss on chain5.

Besides this basic case, there can be actions that aren't available 
currently, and need software assistance, such as encapsulation.

if we had the following rule:

tc fiter add dev1 ..... chain 5 ... flower ip_proto UDP action 
tunnel_key set dst_port 4789 vni 98 dst_ip 1.1.1.1 mirred egress 
redirect dev vxlan_sys_4789

And neighbor for the dst_ip 1.1.1.1 is unreachable, we can't do the 
encapsulation in hardware currently, and wait for software to resolve

the neighbor via arp.

Another is the action ct we plan on offloading here, we send packets 
back to conntrack if needed (before the connection is established, for 
connection setup)

There can also be trap action, to explicitly continue in software, and 
the user might want the partial processing before it.

We currently support up to several millions of such rules, and any 
update (delete/add) of a continuation of a rule (e.g chain 5 rule),

might affect the processing of millions of other rules before it (goto 
chain 5 rules), with tc priorities, it's even worse and happens more often.