On Thu, Feb 9, 2017 at 7:33 PM, David Miller <da...@davemloft.net> wrote: > From: Tom Herbert <t...@herbertland.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
