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]

Date:   Thu, 9 Feb 2017 14:45:04 -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:34 PM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Thu, 9 Feb 2017 14:26:50 -0800
>
>> 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.
>
> We can actually control what externally written XDP eBPF programs can
> do, for kernel modules we have no such control or influence.  This
> hook runs right in the driver and bypasses the entire stack, it has to
> execute in a hardened thing that cannot crash and it will not as long
> as BPF verifier is correct.
>
> And you're going to make it even more complicated what XDP offload in
> hardware actually means.  With eBPF it is very clearly defined what
> the necessary execution engine is.
>
> Tom I'm strongly against being allowed to run arbitrary module code
> from the XDP hook, sorry.
>
> It is as important as the distinction between full stack offload and
> partial offload in those nice charts in your talks. :-)
>
Yes it is. And the relevant principle that I would draw from that is
the "offload" means offloading functionality from the kernel **to**
the device. Restricting what we implement in the kernel on the basis
of whether or not it can be offloaded to a device is completely
backwards in this regard.

Tom