netdev - Re: [PATCH net-next RFC 00/20] 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: <63d6069f31bab_2c3eb20844@john.notmuch>
Date:   Sat, 28 Jan 2023 21:39:43 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Willem de Bruijn <willemb@...gle.com>,
        Jamal Hadi Salim <jhs@...atatu.com>
Cc:     Stanislav Fomichev <sdf@...gle.com>,
        Jamal Hadi Salim <hadi@...atatu.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        kernel@...atatu.com, deb.chatterjee@...el.com,
        anjali.singhai@...el.com, namrata.limaye@...el.com,
        khalidm@...dia.com, tom@...anda.io, pratyush@...anda.io,
        xiyou.wangcong@...il.com, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, vladbu@...dia.com, simon.horman@...igine.com,
        stefanc@...vell.com, seong.kim@....com, mattyk@...dia.com,
        dan.daly@...el.com, john.andy.fingerhut@...el.com
Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC

Willem de Bruijn wrote:
> On Sat, Jan 28, 2023 at 10:10 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >

[...]

> > >
> > > I would also think that if we need another programmable component in
> > > the kernel, that this would be based on BPF, and compiled outside the
> > > kernel.
> > >
> > > Is the argument for an explicit TC objects API purely that this API
> > > can be passed through to hardware, as well as implemented in the
> > > kernel directly? Something that would be lost if the datapath is
> > > implement as a single BPF program at the TC hook.
> > >
> >
> > We use the skip_sw and skip_hw knobs in tc to indicate whether a
> > policy is targeting hw or sw. Not sure if you are familiar with it but its
> > been around (and deployed) for a few years now. So a P4 program
> > policy can target either.
> 
> I know. So the only reason the kernel ABI needs to be extended with P4
> objects is to be able to pass the same commands to hardware. The whole
> kernel dataplane could be implemented as a BPF program, correct?
> 
> > In regards to the parser - we need a scriptable parser which is offered
> > by kparser in kernel. P4 doesnt describe how to offload the parser
> > just the matches and actions; however, as Tom alluded there's nothing
> > that obstructs us offer the same tc controls to offload the parser or pieces
> > of it.
> 
> And this is the only reason that the parser needs to be in the kernel.
> Because the API is at the kernel ABI level. If the P4 program is compiled
> to BPF in userspace, then the parser would be compiled in userspace
> too. A preferable option, as it would not require adding yet another
> parser in C in the kernel.

Also there already exists a P4 backend that targets BPF.

 https://github.com/p4lang/p4c

So as a SW object we can just do the P4 compilation step in user
space and run it in BPF as suggested. Then for hw offload we really
would need to see some hardware to have any concrete ideas on how
to make it work.

Also P4 defines a runtime API so would be good to see how all that
works with any proposed offload.

> 
> I understand the value of PANDA as a high level declarative language
> to describe network protocols. I'm just trying to get more explicit
> why compilation from PANDA to BPF is not sufficient for your use-case.
> 
> 
> > cheers,
> > jamal
> >
> > > Can you elaborate some more why this needs yet another in-kernel
> > > parser separate from BPF? The flow dissection case is solved fine by
> > > the BPF flow dissector. (I also hope one day the kernel can load a BPF
> > > dissector by default and we avoid the majority of the unsafe C code
> > > entirely.)
>