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