linux-kernel - Re: [RFC PATCH tip 0/5] tracing filters with BPF

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: <CAMEtUuwMGwQEtX4p1RyNTSZBA_9j-XQ4aEtM7L5hrqPkS2szfw@mail.gmail.com>
Date:	Wed, 4 Dec 2013 09:36:23 -0800
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Tom Zanussi <tom.zanussi@...ux.intel.com>,
	Jovi Zhangwei <jovi.zhangwei@...il.com>,
	Eric Dumazet <edumazet@...gle.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Pekka Enberg <penberg@....fi>,
	"David S. Miller" <davem@...emloft.net>,
	Arjan van de Ven <arjan@...radead.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC PATCH tip 0/5] tracing filters with BPF

On Wed, Dec 4, 2013 at 1:34 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Alexei Starovoitov <ast@...mgrid.com> wrote:
>
>> On Tue, Dec 3, 2013 at 1:16 AM, Ingo Molnar <mingo@...nel.org> wrote:
>> >
>> > Very cool! (Added various other folks who might be interested in
>> > this to the Cc: list.)
>> >
>> > I have one generic concern:
>> >
>> > It would be important to make it easy to extract loaded BPF code
>> > from the kernel in source code equivalent form, which compiles to
>> > the same BPF code.
>> >
>> > I.e. I think it would be fundamentally important to make sure that
>> > this is all within the kernel's license domain, to make it very
>> > clear there can be no 'binary only' BPF scripts.
>> >
>> > By up-loading BPF into a kernel the person loading it agrees to
>> > make that code available to all users of that system who can
>> > access it, under the same license as the kernel's code (or under a
>> > more permissive license).
>> >
>> > The last thing we want is people getting funny ideas and writing
>> > drivers in BPF and hiding the code or making license claims over
>> > it
>>
>> all makes sense. In case of kernel modules all export_symbols are
>> accessible and module has to have kernel compatible license. Same
>> licensing terms apply to anything else that interacts with kernel
>> functions. In case of BPF the list of accessible functions is tiny,
>> so it's much easier to enforce specific limited use case. For
>> tracing filters it's just bpf_load_xx/trace_printk/dump_stack. Even
>> if someone has funny ideas they cannot be brought to life, since
>> drivers need a lot more than this set of functions and BPF checker
>> will reject any attempts to call something outside of this tiny
>> list. imo the same applies to existing BPF as well. Meaning that
>> tcpdump filter string and seccomp filters, if distributed, has to
>> have their source code available.
>
> I mean more than that, I mean the licensing of BFP filters a user can
> find on his own system's kernel should be very clear: by the act of
> loading a BFP script into the kernel the user doing the 'upload' gives
> permission for it to be redistributed on kernel-compatible license
> terms.
>
> The easiest way to achieve that is to make sure that all loaded BFP
> scripts are 'registered' and are dumpable, viewable and reusable.
> That's good for debugging and it's good for transparency.
>
> This means a minimal BFP decoder will have to be in the kernel as
> well, but that's OK, we actually have several x86 instruction decoder
> in the kernel already, so there's no complexity threshold.

sure. there is pr_info_bpf_insn() in bpf_run.c that dumps bpf insn in
human readable format.
I'll hook it up to trace_seq, so that "cat
/sys/kernel/debug/.../filter" will dump it.

Also I'm thinking to add 'license_string' section to bpf binary format
and call license_is_gpl_compatible() on it during load.
If false, then just reject it…. not even messing with taint flags...
That would be way stronger indication of bpf licensing terms than what
we have for .ko

>> wow. I guess if the whole thing takes off, we would need an
>> in-kernel directory to store upstreamed bpf filters as well :)
>
> I see no reason why not, but more importantly all currently loaded BFP
> scripts should be dumpable, displayable and reusable in a kernel
> license compatible fashion.

ok. will add global bpf list as well (was hesitating to do something
like this because of central lock)
and something in debugfs that dumps bodies of all currently loaded filters.

Will that solve the concern?

Thanks
Alexei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/