netdev - Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

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: <CAJN39ohS0+GCLMsc3s_JyROTDty8eomRJ==QW34YxhDrDGr9KA@mail.gmail.com>
Date:   Mon, 11 Mar 2019 18:29:55 -0700
From:   Brendan Gregg <bgregg@...flix.com>
To:     Kris Van Hees <kris.van.hees@...cle.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH 0/2] bpf: context casting for tail call and gtrace prog type

On Mon, Mar 11, 2019 at 7:21 AM Kris Van Hees <kris.van.hees@...cle.com> wrote:
>
> On Thu, Mar 07, 2019 at 01:30:37PM -0800, Alexei Starovoitov wrote:
> > On Tue, Mar 05, 2019 at 09:03:57PM -0500, Kris Van Hees wrote:
[...]
> > > But being able to do things like this without
> > > needing to touch the context of any other BPF program type is a great benefit
> > > to offer tracing tools, as far as I see it.
> >
> > I still don't understand what you're referring to by 'things like this'
> > that somehow will be possible in the future, but not possible today.
> > Could you please give concrete example?
>
> My apologies for not being clear.  I am referring to the features of the
> gtrace context in terms of containing task information, and output buffers
> to be used in BPF programs triggered from various probe sources (kprobe,
> tracepoints, ...)  I would not want to suggest making changes to all the
> different program contexts in order to support tracing needs because that
> would be wrong.  Doing it in a central place makes it a lot easier to maintain
> without impacting other program types, etc.
>
> Of course, yes, bpf_probe_read() and bpf_perf_event_output() can be used
> to implement a lot of what existing tracing tools like DTrace can do, if you
> write them based on that.  One limitations I am obviously working with is
> that DTrace already exists and has existed for a long time.  And while it is
> 100% available as open source, it involves a pretty involved set of patches to
> be applied to the kernel to be able to use it which is just not ideal.  Hence
> the goal to make it available by re-using as much of the existing features in
> Linux as possible, while still maintaining the same level of functionality in
> DTrace.  That means we need to fill the gaps - and from where I am sitting,
> the ways to do that might as well be of use to others (if they want to).
>
> If phrasing things in the context of DTrace would make the conversation easier
> I certainly don;t mind doing that, but I really don't want to limit my patches
> to supporting just DTrace (even if right now it might be the only tracer using
> it).

As a concrete example, can you point to one of my own published DTrace
tools that BPF can't do? These were created to solve many real
production issues, and make good use cases. I've been porting them
over to BPF (bcc and bpftrace) without too much problem, and I can't
think of a single one that I couldn't port over today.

There's a few minor things that I'm currently doing workarounds for,
like ppid, but that should be satisfied with a few more helpers. And
if it's really niche, then BTF sounds like a good solution.

If your ultimate goal is to have a command called "dtrace" that runs D
programs, to support your existing users, then I'd add a lex/yacc pair
to bpftrace and have it emit a dtrace binary.

Brendan

--
Brendan Gregg, Senior Performance Architect, Netflix