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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 Nov 2023 10:53:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree.xilinx@...il.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, Jiri Pirko <jiri@...nulli.us>,
 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

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.

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.

>  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.

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.