netdev - Re: [RFC] ethtool: raw packet filtering

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]

Message-ID: <bc2cad6a-a456-4aa2-aeaa-157b3cd48b57@intel.com>
Date: Mon, 11 Dec 2023 16:34:42 -0700
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<pabeni@...hat.com>, <mkubecek@...e.cz>, "Chittim, Madhu"
	<madhu.chittim@...el.com>, "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: Re: [RFC] ethtool: raw packet filtering



On 2023-12-06 19:25, Jakub Kicinski wrote:
> On Wed, 6 Dec 2023 15:47:18 -0700 Ahmed Zaki wrote:
>> Sure. The main use case is to be able to filter on any standard or
>> proprietary protocol headers, tunneled or not, using the ntuple API.
>> ethtool allows this only for the basic TCP/UDP/SCTP/ah/esp and IPv4/6.
>> Filtering on any other protocol or stack of protocols will require
>> ethtool and core changes. Raw filtering on the first 512 bytes of the
>> packet will allow anyone to do such filtering without these changes.
>>
>> To be clear, I am not advocating for bypassing Kernel parsing, but there
>> are so many combinations of protocols and tunneling methods that it is
>> very hard to add them all in ethtool.
>>
>> As an example, if we want to direct flows carrying GTPU traffic
>> originating from <Inner IP> and tunneled on a given VxLan at a given
>> <Outer IP>:
>>
>> <Outer IP> : <Outer UDP> : <VXLAN VID> : <ETH> : <Inner IP> : <GTPU>
>>
>> to a specific RSS queue.
> 
> Dunno. I think it's a longer conversation. In principle - I personally
> don't mind someone extending raw matching support, others who care about
> protocol ossification and sensible parsing API might. But if you want
> 512B you would have to redo the uAPI, and adding stuff to ethtool ioctl
> has very high bar as this is a legacy interface. Moving ntuple filters
> to netlink OTOH is a different can of warms - it duplicates parts of TC
> and nft while having a _lot_ less capabilities. And performance
> (everything under rtnl). Which begs the question whether we should
> leave n-tuple filters behind completely and focus on tc / nft APIs.
> 
> So I'll be completely honest - feels like this is going to be really
> high effort / benefit ratio for the maintainers. It will be challenging
> to get it merged.

I agree on the n-tuple hurdles, but is there a tc/nft API that you have 
in mind? Not sure where are the overlaps/duplication.

I couldn't find anything that can be extended to offload RX packet 
filtering/matching. Or did you mean __create__ new APIs?