On Fri, Oct 7, 2016 at 9:28 PM, Jesper Dangaard Brouer <bro...@redhat.com> wrote: > > On Sat, 8 Oct 2016 07:25:01 +0900 Tom Herbert <t...@herbertland.com> wrote: > >> One concern raised at netdev concerning XDP is how are we going to >> maintain code quality, security, and correctness of programs being >> loaded. With kernel bypass it is not just the kernel code path that is >> being bypassed, but also the processes that hold the quality of code >> being accepted to a high bar. Our users expect that quality to be >> maintained. >> >> I suggest that we need XDP programs to be subject to the same scrutiny >> that any other kernel netdev code is. One idea is to sign programs >> that have been accepted into the kernel. By default only signed >> programs would be allowed to be loaded, the override to allow unsigned >> programs might be a kernel config or a least a boot parameter >> (enabling the override needs to be very explicit). > > Sorry, I think this "lock-down" will kill the DDoS use-case. In the > DDoS mitigation use-case, is all about flexibility to adapt quickly to > changing attacks. Thus, you need the ability to quickly modify your > programs to catch attack signatures. > As I mentioned the ability to run arbitrary programs can be explicitly be disabled for such use-cases. But not all use cases of XDP require such dynamic program-ability and not every user is going to need or want this capability. For instance, an ILA router should be a straightforward program to implement and not really need dynamic modification (it is controlled through configuration). If someone chooses to do a proprietary ILA router themselves they can do that by disabling the lock-down, but they shouldn't expect any support from the community when things got wrong. This is no different then when people post to netdev about problems they are having with proprietary modules. If they use an in-tree implementation then we could support that.
Tom > >> The acceptable XDP programs should probably be under their own >> directory. Such a directory should only contain kernel code, not >> userspace code also as is currently in samples/bpf. >> >> A nice side effect of this model is when the same XDP programs are >> being used in non-Linux environments (HW offload, other OSes, etc.) >> the process could maintain quality expections in those environments >> also. > > I'm not against having some 'signed' eBPF/XDP programs. If a XDP > programs behavior is well-defined enough, this would also open up for > HW offloading of "programs" that does the same functionality (without > looking at the eBPF code). > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer
