netdev - Re: [RFC bpf-next 0/4] libbpf: userspace attach by name

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:   Fri, 14 Jan 2022 12:48:46 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alan Maguire <alan.maguire@...cle.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        john fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
        Yucong Sun <sunyucong@...il.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [RFC bpf-next 0/4] libbpf: userspace attach by name

On Thu, Jan 13, 2022 at 2:30 AM Alan Maguire <alan.maguire@...cle.com> wrote:
>
> On Wed, 12 Jan 2022, Andrii Nakryiko wrote:
>
> > On Wed, Jan 12, 2022 at 8:19 AM Alan Maguire <alan.maguire@...cle.com> wrote:
> > >
> > > This patch series is a rough attempt to support attach by name for
> > > uprobes and USDT (Userland Static Defined Tracing) probes.
> > > Currently attach for such probes is done by determining the offset
> > > manually, so the aim is to try and mimic the simplicity of kprobe
> > > attach, making use of uprobe opts.
> > >
> > > One restriction applies: uprobe attach supports system-wide probing
> > > by specifying "-1" for the pid.  That functionality is not supported,
> > > since we need a running process to determine the base address to
> > > subtract to get the uprobe-friendly offset.  There may be a way
> > > to do this without a running process, so any suggestions would
> > > be greatly appreciated.
> > >
> > > There are probably a bunch of subtleties missing here; the aim
> > > is to see if this is useful and if so hopefully we can refine
> > > it to deal with more complex cases.  I tried to handle one case
> > > that came to mind - weak library symbols - but there are probably
> > > other issues when determining which address to use I haven't
> > > thought of.
> > >
> > > Alan Maguire (4):
> > >   libbpf: support function name-based attach for uprobes
> > >   libbpf: support usdt provider/probe name-based attach for uprobes
> > >   selftests/bpf: add tests for u[ret]probe attach by name
> > >   selftests/bpf: add test for USDT uprobe attach by name
> > >
> >
> > Hey Alan,
> >
> > I've been working on USDT support last year. It's considerably more
> > code than in this RFC, but it handles not just finding a location of
> > USDT probe(s), but also fetching its arguments based on argument
> > location specification and more usability focused BPF-side APIs to
> > work with USDTs.
> >
> > I don't remember how up to date it is, but the last "open source"
> > version of it can be found at [0]. I currently have the latest
> > debugged and tested version internally in the process of being
> > integrated into our profiling solution here at Meta. So far it seems
> > to be working fine and covers our production use cases well.
> >
>
> This looks great Andrii! I really like the argument access work, and the
> global tracing part is solved too by using the ELF segment info instead
> of the process maps to get the relative offset, with (I think?) use of
> BPF cookies to disambiguate between different user attachments.

BPF cookies are mandatory for when attaching to a shared library *and*
NOT specifying PID. This is actually the mode that BCC doesn't seem to
support. In all other cases BPF cookie shouldn't be mandatory.

>
> The one piece that seems to be missing from my perspective - and this may
> be in more recent versions - is uprobe function attachment by name. Most of
> the work is  already done in libusdt so it's reasonably doable I think - at a
> minimum  it would require an equivalent to the find_elf_func_offset()
> function in my  patch 1. Now the name of the library libusdt suggests its
> focus is on USDT of course, but I think having userspace function attach
> by name too would be great. Is that part of your plans for this work?

True, uprobes don't supprot attaching by function name, which is quite
annoying. It's certainly not a focus for libusdt (or whatever it will
end up being called when open-sources). But if it's not much code and
complexity we should probably just add that to libbpf directly for
uprobes.


>
> Thanks!
>
> Alan