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]

Message-ID: <CAM0EoMkbCpPYM4LgdUdrGfN4ECBrhNr8YiaVtuu=z+-hGnWFMQ@mail.gmail.com>
Date: Thu, 23 Nov 2023 13:58:32 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Edward Cree <ecree.xilinx@...il.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, kuba@...nel.org, 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, Nov 23, 2023 at 1:09 PM Jiri Pirko <jiri@...nulli.us> wrote:
>
> Thu, Nov 23, 2023 at 06:53:42PM CET, ecree.xilinx@...il.com wrote:
> >On 23/11/2023 16:30, Jamal Hadi Salim wrote:
> >> I was hoping not to say anything but my fingers couldnt help themselves:
> >> So "unoffloadable" means there is a binary blob and this doesnt work
> >> per your design idea of how it should work?
> >> Not that it cant be implemented (clearly it has been implemented), it
> >> is just not how _you_ would implement it? All along I thought this was
> >> an issue with your hardware.
> >
> >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.  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.
> >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.
>
> Just for the record, I'm not aware of anyone suggesting p4 eBPF offload
> in this thread.
>
>
> >
> >The only way I can see to handle it is something analogous to proof-
> > carrying code, where the kernel (driver, since the blob is likely to be
> > wholly vendor-specific) can inspect the binary blob and verify somehow
> > that (assuming the HW behaves according to its datasheet) it implements
> > the same thing that exists in SW.
> >Or simplify the hardware design enough that the compiler can be small
> > and tight enough to live in-kernel, but that's often impossible.
>
> Yeah, that would solve the offloading problem. From what I'm hearing
> from multiple sides, not going to happen.

This is a topic that has been discussed many times. The idea Tom is
describing has been the basis of the discussion i.e some form of
signature that is tied to the binary as well as the s/w side of things
when you do offload. I am not an attestation expert - but isnt that
sufficient?

cheers,
jamal

> >
> >-ed