On Mon, Dec 05, 2016 at 09:08:36PM -0800, Tom Herbert wrote: > On Mon, Dec 5, 2016 at 7:05 PM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Sun, Dec 04, 2016 at 05:05:28PM +0100, Hannes Frederic Sowa wrote: > >> > >> If one of those eBPF verifiers only accepts a certain number of INSN, as > >> fundamental as backwards jumps, we might end up with two compiler? > > > > two compilers? We already have five. There is gcc bpf backend (unmaintained) > > and now lua, python and ply project can generate bpf code without llvm. > > The kernel verifier has to become smarter. Right now it understands > > only certain instruction patterns which caused all five bpf generators to > > do extra work to satisfy the verifier. The solution is to do > > data flow analysis using proper compiler techniques. > > > >> program thinks). Ergo, more complexity. What do you do when one of those > >> two systems fail? What is the reference data? What do you do if on a > >> highly busy box during DoS constant reloading of your vmalloc happens (I > >> don't know if it is a problem under DoS)? > > > > ddos is one of the key use cases for xdp. If the system is about to oom > > during ddos, it has to be fixed. The faster we move with xdp development > > the sooner we will find and fix those issues. > > And xdp being a core component of the linux kernel we will fix ddos > > for the whole internet. Anyone going dpdk route are simply in > > business of selling ddos protection with proprietary solutions. > > > Hi Alexei, > > I am wondering exactly how XDP fixes DDOS in a non-proprietary > fashion. While the XDP infrastructure is part of the core kernel, the > programs are not part of the kernel as you mention below. So what will > a DDOS solution based on XDP for the whole Internet look like? Do you > envision a set of "blessed" DDOS programs that various sites can use > and configure (maybe some maintained open source repository), or will > each site need to come up with their own XDP programs for DDOS?
At some point we would need a repository of these 'blessed' programs. Some of them will not be programs, but program generators similar to existing Cloudflare bpf setup: https://github.com/cloudflare/bpftools and instead of doing things like: https://github.com/cloudflare/lua-aho-corasick and reimplementing them in proprietary c++, the dfa/aho-corasick will be implemented as a kernel helper. That's what I was alluding to in https://github.com/iovisor/bcc/issues/471 Then all of the research in that area like: https://ir.nctu.edu.tw/bitstream/11536/26033/1/000288319400006.pdf will be applicable and researchers will be sharing these detector programs. Of course, not everyone will open up their secret sauce, but a lot of folks will do and it will drive the innovation.
