netdev - Re: [RFC]: raw packet filtering via tc-flower

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: <CAM0EoMkdsFTuJ-mfqBUKZbvpAzex8ws9jcrPEzTO1iUnaWOPZQ@mail.gmail.com>
Date: Fri, 23 Feb 2024 08:32:47 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Jiri Pirko <jiri@...nulli.us>, Ahmed Zaki <ahmed.zaki@...el.com>, stephen@...workplumber.org, 
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com, corbet@....net, 
	xiyou.wangcong@...il.com, netdev@...r.kernel.org, 
	"Chittim, Madhu" <madhu.chittim@...el.com>, 
	"Samudrala, Sridhar" <sridhar.samudrala@...el.com>, amritha.nambiar@...el.com, 
	Jan Sokolowski <jan.sokolowski@...el.com>, Jakub Kicinski <kuba@...nel.org>
Subject: Re: [RFC]: raw packet filtering via tc-flower

On Fri, Feb 23, 2024 at 7:36 AM Edward Cree <ecree.xilinx@...il.com> wrote:
>
> On 23/02/2024 12:22, Jiri Pirko wrote:
> > Nope, the extension of dissector would be clean, one timer. Just add
> > support for offset+len based dissection.
>
> ... until someone else comes along with another kind of filtering and
>  wants _that_ in flower for the same reasons.
>
> >> How about a new classifier that just does this raw matching?
> >
> > That's u32 basically, isn't it?
>
> Well, u32 has all the extra complications around hashtables, links,
>  permoff... I guess you could have helpers in the kernel to stitch
>  'const' u32 filters into raw matches for drivers that only offload
>  that and reject anything else; and tc userspace could have syntactic
>  sugar to transform Ahmed's offset/pattern/mask into the appropriate
>  u32 matches under the hood.

u32 has a DSL that deals with parsing as well, which includes dealing
with variable packet offsets etc. That is a necessary ingredient if
you want to do pragmatic parsing (example how do you point to TCP
ports if the IP header has options etc).
This flower extension, if it wants to do something equivalent, would
have to adopt some of that language.
For the record, I am not against this being part of flower i just dont
think it's a simple offset/value/mask. u32 for example decided that it
will work with fixed 4 byte lengths to simplify, etc..
I wouldnt trust user space to do the right thing either otherwise
syzkaller will be feasting on this ... I empathise that using flower
will impose an operational challenge of having to use two classifiers
(but I want to point out that it already does offloads).

cheers,
jamal