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

[Ingo Molnar <mingo@kernel.org>]

* Alexei Starovoitov <ast@plumgrid.com> wrote:

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

But will BFP tools generate such gpl-compatible license tags by 
default? If yes then this might work, combined with the facility 
below. If not then it's just a nuisance to users.

Also, 'tainting' is a non-issue here, as we don't want the kernel to 
load license-incompatible scripts at all. This should be made clear in 
the design of the facility and the tooling 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.
> 
> ok. will add global bpf list as well (was hesitating to do something 
> like this because of central lock)

A lock + list is no big issue here I think, we do such central lookup 
locks all the time. If it ever becomes measurable it can be made 
scalable via numerous techniques.

> and something in debugfs that dumps bodies of all currently loaded 
> filters.
> 
> Will that solve the concern?

My concern would be solved by adding a facility to always be able to 
dump source code as well, i.e. trivially transform it to C or so, so 
that people can review it - or just edit it on the fly, recompile and 
reinsert? Most BFP scripts ought to be pretty simple.

(For example the most common way to load OpenGL shaders is to load the 
GLSL source code and that source code can be queried after insertion 
as well, so this is not an unusual model for small plugin-alike 
scriptlets.)

Thanks,

	Ingo