Re: [RFC 0/1] BPF tracing for arm64 using fprobe

From: Chris Mason <clm@meta.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Florent Revest <revest@chromium.org>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	KP Singh <kpsingh@kernel.org>,
	Brendan Jackman <jackmanb@google.com>,
	markowsky@google.com, Mark Rutland <mark.rutland@arm.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Xu Kuohai <xukuohai@huawei.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe
Date: Thu, 17 Nov 2022 16:55:12 -0500	[thread overview]
Message-ID: <d24cded7-87b1-89f5-fc2a-5346669f6d57@meta.com> (raw)
In-Reply-To: <20221117121617.4e1529d3@gandalf.local.home>

On 11/17/22 12:16 PM, Steven Rostedt wrote:
> On Wed, 16 Nov 2022 18:41:26 -0800
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> 
>> Even with all optimization the performance overhead is not acceptable.
>> It feels to me that folks are still thinking about bpf trampoline
>> as a tracing facility.
>> It's a lot more than that. It needs to run 24/7 with zero overhead.
> 
> It obviously doesn't have zero overhead.
> 
> And correctness and maintainability trumps micro-optimizations.

During the bpf office hours today Mark Rutland and Florent had some
great ideas about how to wire things up.  I'm sure Mark will need some
time to write it all down but it was a fun call.

> 
>> It needs to replace the kernel functions and be invoked
> 
> What do you mean by "replace the kernel functions"? You mean an existing
> kernel function can be replaced by a bpf program? Like live patching?
> 
> This seems rather dangerous, and how does one know that their system has
> integrity? Is there a feature to sign bpf programs before they can be added?
> 
> Also, it may be time to bring in the lawyers. If a bpf program can replace
> an existing kernel function, then it has definitely passed the "user space"
> exception to the GPL, where user space must use the system call interface.
> By injecting executable code into the kernel, especially something that
> replaces kernel functionality, it becomes arguably derived from the kernel
> itself. And the BPF program must be GPL.
> 
> Allowing proprietary BPF programs to replace kernel functionality looks
> like a clear violation and circumvention of the GPL. But I could be
> mistaken. As I said, it's time to bring in the lawyers on this one.

https://docs.kernel.org/bpf/bpf_licensing.html answers most of your
questions.  It was reviewed by lawyers and also discussed pretty
extensively on the lists.

The short answer to your concerns is that you can't replace kernel
functions from proprietary BPF programs.  The LSM and TCP congestion
control features intentionally have GPL only support functions in the
way.  bpf_probe_read_kernel() is also GPL only and massively limits the
things that can be done from proprietary code.

This list of helpers is pretty current and details which ones are GPL only:

https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md#helpers

I know there's a long and glorious history of collaboration around these
parts of bpf and ftrace.  I really hope this time around we all come
away feeling like the technical discussion made both projects better.
Mark and Florent today certainly made me think that was the direction we
were headed.

Along these lines, I'm also hoping to avoid diving into old debates and
alarmist conclusions about GPL compliance and signed bpf programs. Or,
if some part of those old debates is no longer valid, can we split
it off into a well researched separate thread and focus on technical 
bits here?

-chris