netdev - Re: [PATCH net-next v8 00/15] Introducing P4TC

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: <ZWB9dF8/Uk2iP2uy@nanopsycho>
Date: Fri, 24 Nov 2023 11:39:48 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Edward Cree <ecree.xilinx@...il.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	John Fastabend <john.fastabend@...il.com>, netdev@...r.kernel.org,
	deb.chatterjee@...el.com, anjali.singhai@...el.com,
	Vipin.Jain@....com, namrata.limaye@...el.com, tom@...anda.io,
	mleitner@...hat.com, Mahesh.Shirshyad@....com,
	tomasz.osinski@...el.com, xiyou.wangcong@...il.com,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	vladbu@...dia.com, horms@...nel.org, bpf@...r.kernel.org,
	khalidm@...dia.com, toke@...hat.com, mattyk@...dia.com,
	dan.daly@...el.com, chris.sommers@...sight.com,
	john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next v8 00/15] Introducing P4TC

Thu, Nov 23, 2023 at 07:53:05PM CET, kuba@...nel.org wrote:
>On Thu, 23 Nov 2023 17:53:42 +0000 Edward Cree wrote:
>> The kernel doesn't like to trust offload blobs from a userspace compiler,
>>  because it has no way to be sure that what comes out of the compiler
>>  matches the rules/tables/whatever it has in the SW datapath.
>> It's also a support nightmare because it's basically like each user
>>  compiling their own device firmware.  
>
>Practically speaking every high speed NIC runs a huge binary blob of FW.
>First, let's acknowledge that as reality.

True, but I believe we need to diferenciate:
1) vendor created, versioned, signed binary fw blob
2) user compiled on demand, blob

I look at 2) as on "a configuration" of some sort.


>
>Second, there is no equivalent for arbitrary packet parsing in the
>kernel proper. Offload means take something form the host and put it
>on the device. If there's nothing in the kernel, we can't consider
>the new functionality an offload.
>
>I understand that "we offload SW functionality" is our general policy,
>but we should remember why this policy is in place, and not
>automatically jump to the conclusion.

It is in place to have well defined SW definition of what devices
offloads.


>
>>  At least normally with device firmware the driver side is talking to
>>  something with narrow/fixed semantics and went through upstream
>>  review, even if the firmware side is still a black box.
>
>We should be buildings things which are useful and open (as in
>extensible by people "from the street"). With that in mind, to me,
>a more practical approach would be to try to figure out a common
>and rigid FW interface for expressing the parsing graph.

Hmm, could you elaborate a bit more on this one please?

>
>But that's an interface going from the binary blob to the kernel.
>
>> Just to prove I'm not playing favourites: this is *also* a problem with
>>  eBPF offloads like Nanotubes, and I'm not convinced we have a viable
>>  solution yet.
>
>BPF offloads are actual offloads. Config/state is in the kernel,
>you need to pop it out to user space, then prove that it's what
>user intended.