Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752094AbaF1G2Y (ORCPT ); Sat, 28 Jun 2014 02:28:24 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:63673 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751503AbaF1G2X (ORCPT ); Sat, 28 Jun 2014 02:28:23 -0400 MIME-Version: 1.0 In-Reply-To: References: <1403913966-4927-1-git-send-email-ast@plumgrid.com> <1403913966-4927-8-git-send-email-ast@plumgrid.com> From: Andy Lutomirski Date: Fri, 27 Jun 2014 23:28:01 -0700 Message-ID: Subject: Re: [PATCH RFC net-next 07/14] bpf: expand BPF syscall with program load/unload To: Alexei Starovoitov Cc: "David S. Miller" , Ingo Molnar , Linus Torvalds , Steven Rostedt , Daniel Borkmann , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , Network Development , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 27, 2014 at 11:12 PM, Alexei Starovoitov wrote: > On Fri, Jun 27, 2014 at 5:19 PM, Andy Lutomirski wrote: >> On Fri, Jun 27, 2014 at 5:05 PM, Alexei Starovoitov 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 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/