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: <ZdiOHpbYB3Ebwub5@nanopsycho>
Date: Fri, 23 Feb 2024 13:22:54 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Ahmed Zaki <ahmed.zaki@...el.com>, stephen@...workplumber.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	corbet@....net, jhs@...atatu.com, 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

Fri, Feb 23, 2024 at 01:07:06PM CET, ecree.xilinx@...il.com wrote:
>On 23/02/2024 09:51, Jiri Pirko wrote:
>> Hmm, but why flower can't be extended this direction. I mean, it is very
>> convenient to match on well-defined fields.
>
>Flower is intrinsically tied to the flow dissector, both conceptually
> and in implementation.  I'm not sure it's appropriate for it to become
> a dumping ground for random vendor filtering extensions/capabilities.

Nope, the extension of dissector would be clean, one timer. Just add
support for offset+len based dissection. Also, the fact that flower uses
flow_dissector is only because DaveM requested that back in the days I
pushed flower. The original implementation was not using flow_dissector.
The dissection backing should not block flower extension. We can always
replace it if needed and convenient (maybe the criteria is met already).


>
>> U32 is, well, not that convenient.
>
>How about a new classifier that just does this raw matching?

That's u32 basically, isn't it?


>
>> I can imagine that the
>> combination of match on well-defined fields and random chunks together
>> is completely valid use-case.
>
>But is it likely to be something that hardware supports?  (Since the

Yeah, I know couple of ASICs that support this, driver names are mlx5
and mlxsw :)


> motivation for this feature is clearly the hardware offload — otherwise
> there are other mechanisms like BPF for arbitrary packet filtering.)
>
>As the vendor behind this, one hopes Intel can comment on both the
> hardware and the use-case side of this question.