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: <20231206182524.0dc8b680@kernel.org>
Date: Wed, 6 Dec 2023 18:25:24 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Ahmed Zaki <ahmed.zaki@...el.com>
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 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.