netdev - Re: [PATCH net-next v2] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e3b95525-b72e-00f2-8cda-eb5a419901ad@mellanox.com>
Date:   Sun, 25 Aug 2019 14:11:24 +0000
From:   Paul Blakey <paulb@...lanox.com>
To:     David Miller <davem@...emloft.net>
CC:     "pshelar@....org" <pshelar@....org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jpettit@...ira.com" <jpettit@...ira.com>,
        "simon.horman@...ronome.com" <simon.horman@...ronome.com>,
        "marcelo.leitner@...il.com" <marcelo.leitner@...il.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        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 v2] net: openvswitch: Set OvS recirc_id from tc
 chain index

On 8/22/2019 6:57 AM, David Miller wrote:

> From: Paul Blakey <paulb@...lanox.com>
> Date: Tue, 20 Aug 2019 15:30:51 +0300
>
>> @@ -4050,6 +4060,9 @@ enum skb_ext_id {
>>   #ifdef CONFIG_XFRM
>>   	SKB_EXT_SEC_PATH,
>>   #endif
>> +#if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
>> +	TC_SKB_EXT,
>> +#endif
>>   	SKB_EXT_NUM, /* must be last */
>>   };
> Sorry, no.
>
> The SKB extensions are not a dumping ground for people to use when they can't
> figure out another more reasonable place to put their values.  Try to use
> the normal cb[], and if you can't you must explain in exhaustive detail
> why you cannot in any way whatsoever make that work.
>
> Again, SKB extensions are not a dumping ground.
Hi,
The general context of this skb extension patch is hardware offload of 
multi chain rules.
This patch shows only one usage of this extension which is by tc -> OvS 
miss path.
But we also plan to reuse this extension to pass information from 
HW/Driver -> tc miss path.

In tc multi chain rules scenarios, some of the rules might be offloaded
and some not (e.g skip_hw, unsupported rules by HW, vxlan encapsulation, 
offload order, etc).
Therefore, HW can miss at any point of the processing chain.
SW will need to continue processing in correct tc chain where the HW 
left off, as HW might have modified the packet and updated stats for it.
This scenario can reuse this tc SKB extension to restore the tc chain.

Skb control block acts a scratchpad area for storing temporary 
information and isn't suppose
to be used to pass around information between different layers of 
processing.
HW/Driver -> tc - >OvS  are different layers, and not necessarily 
processing the packet one after another.
There can be bridges, tunnel devices, VLAN devices, Netfilter 
(Conntrack) and a host of other entities processing the packet in between
so we can't guarantee the control block integrity between this main 
processing entities (HW/Driver, Tc, Ovs).
So if we'll use the control block, it will restrict such use cases.
For example, the napi API which we use, uses the control block and comes 
right after our driver layer.
This will overwrite any usage of CB by us.

Thanks,
Paul B.