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, 13 Jan 2022 10:29:35 +0000 (GMT)
From:   Alan Maguire <alan.maguire@...cle.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
cc:     Alan Maguire <alan.maguire@...cle.com>,
        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 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.

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?

Thanks!

Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ