On Thu, Feb 9, 2017 at 2:34 PM, David Miller <da...@davemloft.net> wrote: > From: Tom Herbert <t...@herbertland.com> > Date: Thu, 9 Feb 2017 14:26:50 -0800 > >> On Thu, Feb 9, 2017 at 2:17 PM, David Miller <da...@davemloft.net> wrote: >>> From: Tom Herbert <t...@herbertland.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
