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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ