From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752150AbbJYSSD (ORCPT <rfc822;w@1wt.eu>);
	Sun, 25 Oct 2015 14:18:03 -0400
Received: from mail-pa0-f43.google.com ([209.85.220.43]:35846 "EHLO
	mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751490AbbJYSSC (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 25 Oct 2015 14:18:02 -0400
Subject: Re: [PATCH net-next] bpf: make tracing helpers gpl only
To: Ingo Molnar <mingo@kernel.org>
References: <1445637499-11146-1-git-send-email-ast@kernel.org>
 <20151025091411.GE24337@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Wang Nan <wangnan0@huawei.com>, He Kuang <hekuang@huawei.com>,
        Kaixu Xia <xiakaixu@huawei.com>,
        Daniel Borkmann <daniel@iogearbox.net>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
From: Alexei Starovoitov <ast@plumgrid.com>
Message-ID: <562D1CD6.6020307@plumgrid.com>
Date: Sun, 25 Oct 2015 11:17:58 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151025091411.GE24337@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/25/15 2:14 AM, Ingo Molnar wrote:
> so I don't know the netfilter ones, but in particular the tracing ones I'm sure
> should be gpl-only. Do we really, really want proprietary modules mucking with
> such internals??

of course, not. Therefore bpf_probe_read() was gpl_only from very
beginning. Same goes to bpf_trace_printk() and bpf_ktime_get_ns().
and after this patch the only remaining non-gpl tracing helpers will be
bpf_get_current_pid_tgid()/uid_gid()/comm()
and imo it's fine.

On the networking side the helpers are non-gpl, since all of them are
generic. They don't mess with kernel, but examine/modify the packet.
Just like cBPF can read the packet data, get_processor_id, get_random,
eBPF can do the same plus write into the packet, compute checksum,
redirect, push/pop vlan.

When we introduce eBPF for seccomp, I would argue that helpers on that
side should be non-gpl as well, otherwise people will try to add
features to cBPF instead of moving to eBPF.