Hi Alexei, and Daniel, Alexei Starovoitov <alexei.starovoi...@gmail.com> writes:
> On Wed, Apr 05, 2017 at 10:59:49PM -0400, Aaron Conole wrote: >> Hi Daniel, >> >> Daniel Borkmann <dan...@iogearbox.net> writes: >> >> > On 04/04/2017 08:33 PM, Aaron Conole wrote: >> >> The eBPF framework is used for more than just socket level filtering. It >> >> can also provide tracing, and even change the way packets coming into the >> >> system look. Most of the eBPF callable symbols are available to non-gpl >> >> programs, and this includes helper functions which modify packets. This >> >> allows proprietary eBPF code to link to the kernel and make decisions >> >> which can negatively impact network performance. >> >> >> >> Since the sources for these programs are only available under a >> >> proprietary >> >> license, it seems better to treat them the same as other proprietary >> >> modules: set the system taint flag. An exemption is made for socket-level >> >> filters, since they do not really impact networking for the whole kernel. >> >> >> >> Signed-off-by: Aaron Conole <acon...@bytheb.org> >> >> --- >> > >> > Nacked-by: Daniel Borkmann <dan...@iogearbox.net> Given we have different views about this, I think I am okay with some middle ground. Here's the next-steps plan. Please tell if you dislike it or want to change it: 1. Add a ref counter for tracking load and unload, which can be queried from a procfs or bpf fs interface 2. Add a new print during panic when the refcount is non-zero. This lets us know that there could be some kind of ebpf program loaded, and we would ask for sources before trying to disassemble. Does this sound reasonable?
