On Fri, Jun 27, 2014 at 11:12 PM, Alexei Starovoitov <a...@plumgrid.com> wrote: > On Fri, Jun 27, 2014 at 5:19 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Fri, Jun 27, 2014 at 5:05 PM, Alexei Starovoitov <a...@plumgrid.com> >> wrote: >>> eBPF programs are safe run-to-completion functions with load/unload >>> methods from userspace similar to kernel modules. >>> >>> User space API: >>> >>> - load eBPF program >>> prog_id = bpf_prog_load(int prog_id, bpf_prog_type, struct nlattr *prog, >>> int len) >>> >>> where 'prog' is a sequence of sections (currently TEXT and LICENSE) >>> TEXT - array of eBPF instructions >>> LICENSE - GPL compatible >>> + >>> + err = -EINVAL; >>> + /* look for mandatory license string */ >>> + if (!tb[BPF_PROG_LICENSE]) >>> + goto free_attr; >>> + >>> + /* eBPF programs must be GPL compatible */ >>> + if (!license_is_gpl_compatible(nla_data(tb[BPF_PROG_LICENSE]))) >>> + goto free_attr; >> >> Seriously? My mind boggles. > > Yes. Quite a bit of logic can fit into one eBPF program. I don't think it's > wise > to leave this door open for abuse. This check makes it clear that if you > write a program in C, the source code must be available. > If program is written in assembler than this check is nop anyway. >
I can see this seriously annoying lots of users. For example, Chromium might object. If you want to add GPL-only functions in the future, that would be one thing. But if someone writes a nice eBPF compiler, and someone else writes a little program that filters on network packets, I see no reason to claim that the little program is a derivative work of the kernel and therefore must be GPL. > btw this patch doesn't include debugfs access to all loaded eBPF programs. > Similarly to kernel modules I'm planning to have a way to list all loaded > programs with optional assembler dump of instructions. Users can also dump running programs with ptrace. That doesn't mean that all loaded programs need to be GPL. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
