Message-ID: <20131209100248.74db0fb3@gandalf.local.home>
Date:	Mon, 9 Dec 2013 10:02:48 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	Ingo Molnar <mingo@...nel.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: binary blob no more! Was: [RFC PATCH tip 0/5] tracing filters
 with BPF

On Sun, 8 Dec 2013 19:36:18 -0800
Alexei Starovoitov <ast@...mgrid.com> wrote:

 
> Actually I think there are few ways to include the source equivalent
> in bpf image.
> 
> Approach #1
> include original C source code into bpf image:
>   bpf_image = bpf_insns + original_C
> this will imply that C code can have #include's of linux kernel headers only
> and it can only be C source.
> this way the user can do 'cat /sys/kernel/debug/bpf/filter', kernel
> will print original_C and these restrictions will guarantee that it
> will compile into similar bpf code whether gcc or llvm compiler is
> used.
> 
> Approach #2
> include original llvm bitcode:
>   bpf_image = bpf_insns + llvm_bc
> The user can do 'cat .../filter' and use llvm-dis to see human readable bitcode.
> It takes practice to read it, but it's high level enough to understand
> what filter is doing. llvm-llc can be used to generate bpf_insns
> again, or generate C from bitcode.
> Pro vs 1: bitcode is very compact
> Con: only llvm compiler can used to generate bpf instructions
> 
> Enforcement can be done by having a user space daemon that
> walks over all loaded filters and recompiles them from C or from bitcode.
> 
> Please let me know which approach you prefer.

I don't like either. And different compilers may produce different
results, so that daemon may not be able to verify what is in the C code
is really what's in the bitcode.

> 
> I still think that bpf_image = bpf_insns + license_string is just as good,
> since bpf code can only call tiny set of functions, so no matter what
> the code does its scope is very limited and license enforcement
> guarantees that original source has to be available,
> but I'm ok whichever way.

I like that approach much better. That is, all binary code must state
that it is under the GPL. That way, if you give a binary to someone,
you must also supply the source under the GPL license.

Having a disassembler in the kernel to see what code is loaded, adds
the added benefit that you can see what is there. We can have a
userspace tool to make even more sense out of the disassembled code.

I don't think the kernel should have anything more than a disassembler
though. Maybe that's even too much, but at least a human can inspect it
a little without needing extra tools.

> 
> Also please indicate whether gcc or llvm backend is preferred to
> be hosted in tools.

If we end up placing a compiler in tools, than that compiler should
also be able to be used to compile the entire kernel.

Maybe we will finally get our kcc ;-)

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

Powered by blists - more mailing lists