From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Conole Subject: Re: [RFC net-next] bpf: taint loading !is_gpl programs Date: Fri, 07 Apr 2017 13:46:28 -0400 Message-ID: References: <20170404183354.8579-1-aconole@bytheb.org> <58E40C2B.7040802@iogearbox.net> <20170406124059.GB53880@ast-mbp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Daniel Borkmann , Alexei Starovoitov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: Alexei Starovoitov Return-path: In-Reply-To: <20170406124059.GB53880@ast-mbp.thefacebook.com> (Alexei Starovoitov's message of "Thu, 6 Apr 2017 08:41:01 -0400") Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Hi Alexei, and Daniel, Alexei Starovoitov writes: > On Wed, Apr 05, 2017 at 10:59:49PM -0400, Aaron Conole wrote: >> Hi Daniel, >> >> Daniel Borkmann 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 >> >> --- >> > >> > Nacked-by: Daniel Borkmann 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?