netdev - Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

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: <CALx6S34qGUd7Zteo_sDdcXK69cOZUwiQ6wsbLfiyHW1K6gJn=A@mail.gmail.com>
Date:   Thu, 9 Feb 2017 14:26:50 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

On Thu, Feb 9, 2017 at 2:17 PM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Wed, 8 Feb 2017 15:41:20 -0800
>
>> These hooks are also generic to allow for XDP/BPF programs as well
>> as non-BPF code (e.g. kernel code can be written in a module).
>
> I don't think we should even remotely consider surrendering the XDP
> hook to module code.
>
> We restrict it to eBPF for a reason, because that framework is
> restricted in what it can do, what it can access, and how it can do
> so.
>
Kernel modules go through extensive netdev review before they are
taken into the kernel, for BPF programs we just allow what any user
gives us without any peer review even implied. For this reason, I
simply don't believe that BPF is magically more robust code than what
is in a kernel module. Or to put it another way, do you think DPDK is
going to put any restrictions on what a user can do over raw queues in
userspace? If we put on artificial limits on XDP like it can only ever
be BPF then we are just closing the door to its full potential and
given more fodder for the userpace stacks to claim superiority.

> Tom if you're going to do a cleanup that makes it so that drivers
> need less code to support XDP, that is awesome but please do only
> that.
>
> Don't combine it with more controversial changes.
>
We need this for TXDP; I have no interest in rewriting the TCP stack in BPF :-)

Tom

> Thank you.