Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933995AbdDGRql (ORCPT ); Fri, 7 Apr 2017 13:46:41 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:34279 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754489AbdDGRqc (ORCPT ); Fri, 7 Apr 2017 13:46:32 -0400 From: Aaron Conole To: Alexei Starovoitov Cc: Daniel Borkmann , Alexei Starovoitov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC net-next] bpf: taint loading !is_gpl programs References: <20170404183354.8579-1-aconole@bytheb.org> <58E40C2B.7040802@iogearbox.net> <20170406124059.GB53880@ast-mbp.thefacebook.com> Date: Fri, 07 Apr 2017 13:46:28 -0400 In-Reply-To: <20170406124059.GB53880@ast-mbp.thefacebook.com> (Alexei Starovoitov's message of "Thu, 6 Apr 2017 08:41:01 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1672 Lines: 42 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?