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. > 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
