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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Nov 2022 17:40:30 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Chris Mason <clm@...a.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Florent Revest <revest@...omium.org>,
        bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        KP Singh <kpsingh@...nel.org>,
        Brendan Jackman <jackmanb@...gle.com>, markowsky@...gle.com,
        Mark Rutland <mark.rutland@....com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Xu Kuohai <xukuohai@...wei.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC 0/1] BPF tracing for arm64 using fprobe

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

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

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?