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

[Steven Rostedt]

On Thu, 17 Nov 2022 16:55:12 -0500
Chris Mason <clm@xxxxxxxx> wrote:

> On 11/17/22 12:16 PM, Steven Rostedt wrote:
> > On Wed, 16 Nov 2022 18:41:26 -0800
> > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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.

That's good to hear.

> 
> >   
> >> 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.

^^^^^^^^^^^^^^^^^

That's the part I wanted to hear. But just the fact of replacing a kernel
function with BPF code seems a bit concerning.

> 
> 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,

Not alarmist, but concern as being able to modify what a kernel function can
do is not something I take lightly.

-- Steve

> 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?