lkml.org 
[lkml]   [2013]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH tip 0/5] tracing filters with BPF

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-12-05 12:01    [W:0.082 / U:21.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site