On Jun 10, 2015, at 4:31 PM, Mindaugas Rasiukevicius <rm...@noxt.eu> wrote:
> Darren Reed <darr...@netbsd.org> wrote: >> Extending BPF >> ============= >> >> Introduction >> ------------ >> BPF was originally designed to provide very fast packet matching >> capabilities for IPv4 but as a result of its generic nature, is >> capable of being used for just about any protocol. With IPv6 the >> limitations of BPF became apparent. >> >> ... > > Conceptually, I like the idea of an extended BPF instruction set. There > are several important questions here. First, what is the exact problem we > want to solve with a new instruction set? Is it just the IPv6 handling? No, we'd like to, at minimum, be able to cope with VLANs better than we do now - ideally, it'd be nice to be able to, for example, say "ip" in a filter and have it match IP over Ethernet and IP in a VLAN over Ethernet and IP in a VLAN in another VLAN over Ethernet and so on. > Specifically, I would like to see: > > - Capability to jump backwards. Basically, the general purpose instruction > set ought be Turing-complete. Obviously, with a way to enable/disable this > depending whether the user needs bpf_validate(). ...with some way of preventing infinite loops in the kernel, even if it's as crude as "there's a pointer into the packet and if you do a backwards jump without moving that pointer forwards and checking to make sure you haven't gone beyond the end of the packet, the filter program immediately fails". (Yes, that means it's no longer Turing-complete, as there's no longer a halting problem. :-)) > - Opcode extended to 32-bits. It seems we agree on this, although this > can be debatable. The classic BPF byte-code has a simple, minimalistic > RISC-like instruction set (with the exception of BPF_MSH hack). I would > be inclined to keep it that way instead of polluting the, quite limited, > instruction space with various arbitrary mechanisms, but this is somewhat > philosophical RISC vs CISC debate. Nevertheless, if the general feeling > is to go with complex instructions, then we could at least dedicate a wide > range for them. If the machine language is interpreted, frequently-executed complicated instructions might help performance. If it's translated to machine code and executed, it probably wouldn't make much of a difference as long as the JIT compiler does a reasonably good job. > Last, but not least, how does this all fit in the libpcap/tcpdump project? It fits into tcpdump the same way it fits into Wireshark or Snort or... - you supply a filter expression to the application and it hands it to libpcap's compiler. For libpcap: > Are the project goals exclusively limited to capturing the network traffic > or there is a desire to abstract parts of libpcap into some more generic > libbpf? I wouldn't be opposed to putting the BPF interpreter into a libbpf; whether the compiler belongs there or not depends on how generic it is - if it's generic enough that it's used for purposes other than looking at network packets, the rather network-oriented libpcap filter language might not be appropriate. > Also, given that Linux eBPF is gaining the momentum, how realistic > is to push a competing instruction set? All other things being equal, I'd go for a strategy that increases the chances that the new language will be adopted by the OSes whose kernel code supports BPF (Linux, *BSD/OS X, Solaris, AIX). If we can extend eBPF for our purposes, that might make it more likely for Linux to pick it up, as long as we can have a BSD-licensed interpreter (plus perhaps JIT compilers) for the same machine code. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
