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 20:55:34 -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 7:33 PM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Thu, 9 Feb 2017 18:29:54 -0800
>
>> So we have thousands or LOC coming into drivers every day anyway with
>> all those properties anyway, so this "restricted" environment solves
>> at best 1% of the problem.
>
> What you must understand is that no matter what someone outside of
> upstream writes into an eBPF program, it's safe, and we can absolutely
> prove this with the verifier and the invariants of the execution
> environment.
>
This is the exact same argument the userspace stack proponents will
use-- put your stack in userspace and you can't crash the host. But
just like eBPF that does not at all mean the logic of the program is
correct. Getting into a mode where we drop every packet, or checksums
are miscomputed, or a protocol field is miswritten is entirely
possible. The value of coding in the Linux kernel, maybe the only
truly relevant point compared to userspace stacks, is the scrutiny,
the testing, the debugging, and the eyes of experts we get to look at
every line going into the kernel to avoid such problems. Even though
there's the possibility of crash or deadloacking the system, I would
absolutely put the quality of kernel code over _any_ piece of
userspace code _any_ day of the week. Maybe some day we'll see a
process for XDP/BPF for reviewing and accepting code and you along
with several of established experts on netdev will be earnestly
reviewing such code, but until then I am more inclined to stick with
writing kernel code for anything other than simple things that are
amenable to BPF. The problem with kernel bypass is not just that it
bypasses the well-written and well-tested kernel code, but that it
also bypasses the process.

Tom