Subject: Re: [RFC net-next] bpf: taint loading !is_gpl programs

From: Aaron Conole <[email-masked]>
Date: Fri, 07 Apr 2017 13:46:28 -0400

Hi Alexei, and Daniel,

Alexei Starovoitov <[email-masked]> writes:

> On Wed, Apr 05, 2017 at 10:59:49PM -0400, Aaron Conole wrote:
>> Hi Daniel,
>> 
>> Daniel Borkmann <[email-masked]> 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 <[email-masked]>
>> >> ---
>> >
>> > Nacked-by: Daniel Borkmann <[email-masked]>

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?