linux-kernel - Re: [RFC net-next] bpf: taint loading !is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7tk26w3ybv.fsf@redhat.com>
Date:   Fri, 07 Apr 2017 13:46:28 -0400
From:   Aaron Conole <aconole@...heb.org>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC net-next] bpf: taint loading !is_gpl programs

Hi Alexei, and Daniel,

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Wed, Apr 05, 2017 at 10:59:49PM -0400, Aaron Conole wrote:
>> Hi Daniel,
>> 
>> Daniel Borkmann <daniel@...earbox.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@...heb.org>
>> >> ---
>> >
>> > Nacked-by: Daniel Borkmann <daniel@...earbox.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?