From: Aaron Conole <aconole@bytheb.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC net-next] bpf: taint loading !is_gpl programs
Date: Fri, 07 Apr 2017 13:46:28 -0400 [thread overview]
Message-ID: <f7tk26w3ybv.fsf@redhat.com> (raw)
In-Reply-To: <20170406124059.GB53880@ast-mbp.thefacebook.com> (Alexei Starovoitov's message of "Thu, 6 Apr 2017 08:41:01 -0400")
Hi Alexei, and Daniel,
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
> On Wed, Apr 05, 2017 at 10:59:49PM -0400, Aaron Conole wrote:
>> Hi Daniel,
>>
>> Daniel Borkmann <daniel@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 <aconole@bytheb.org>
>> >> ---
>> >
>> > Nacked-by: Daniel Borkmann <daniel@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?
next prev parent reply other threads:[~2017-04-07 17:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 18:33 [RFC net-next] bpf: taint loading !is_gpl programs Aaron Conole
2017-04-04 21:12 ` Daniel Borkmann
2017-04-06 2:59 ` Aaron Conole
2017-04-06 12:41 ` Alexei Starovoitov
2017-04-07 17:46 ` Aaron Conole [this message]
2017-04-08 23:11 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7tk26w3ybv.fsf@redhat.com \
--to=aconole@bytheb.org \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).