netdev - Re: [PATCH bpf-next 0/7] Introduce BPF trampoline

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]

Message-ID: <20191105175905.fenzkyottcnsw6kx@ast-mbp.dhcp.thefacebook.com>
Date:   Tue, 5 Nov 2019 09:59:07 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Alexei Starovoitov <ast@...nel.org>, davem@...emloft.net,
        daniel@...earbox.net, peterz@...radead.org, x86@...nel.org,
        netdev@...r.kernel.org, bpf@...r.kernel.org, kernel-team@...com,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH bpf-next 0/7] Introduce BPF trampoline

On Tue, Nov 05, 2019 at 12:26:29PM -0500, Steven Rostedt wrote:
> 
> I'm guessing it will use kprobes (or optimized probes). I haven't had a
> chance to look at your patches.

People complained that kprobe and especially kretprobe is too slow and too
unpredictable (not guarantees that prog will be executed and k*probe won't be
missed). For bpf to attach to fentry/fexit none of k*probe stuff is needed.

> I still think using the register_ftrace_direct() will be cleaner (as it
> is built on top of code that's been in the kernel for a decade).
> Perhaps we can make it work even without the full ftrace code.

Yes and I still agree that long term using register_ftrace_direct() is cleaner.
What I strongly disagree is that bpf developers need to wait for it to land.
Especially when there is no direct dependency. It's nice to have both bpf
trampoline and ftrace to be functional at the same time tracing the same kernel
function. But for the time being running one or another is an acceptable
limitation. Especially since the path to making it clean is already defined and
agreed.