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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131204093417.GC32531@gmail.com>
Date:	Wed, 4 Dec 2013 10:34:17 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Alexei Starovoitov <ast@...mgrid.com>
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


* 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.

> > I.e. we want to allow flexible plugins technologically, but make 
> > sure people who run into such a plugin can modify and improve it 
> > under the same license as they can modify and improve the kernel 
> > itself!
> 
> 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.

Thanks,

	Ingo
--
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/