[RFC bpf-next 0/3] libbpf: name-based u[ret]probe attach

[Alan Maguire <alan.maguire@oracle.com>]

This patch series is a refinement of the RFC patchset [1], focusing
on support for attach by name for uprobes and uretprobes.  Still
marked RFC as there are unresolved questions.

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 to specify a name string.

uprobe attach is done by specifying a binary path, a pid (where
0 means "this process" and -1 means "all processes") and an
offset.  Here a 'func_name' option is added to 'struct uprobe_opts'
and that name is searched for in symbol tables.  If the binary
is a program, relative offset calcuation must be done to the
symbol address as described in [2].

Having a name allows us to support auto-attach via SEC()
specification, for example

SEC("uprobe/usr/lib64/libc.so.6/malloc")

Unresolved questions:

 - the current scheme uses

u[ret]probe[/]/path/2/binary/function[+offset]

   ...as SEC() format for auto-attach, for example

SEC("uprobe/usr/lib64/libc.so.6/malloc")

   It would be cleaner to delimit binary and function with ':'
   as is done by bcc.  One simple way to achieve that would be
   to support section string pre-processing, where instances of
   ':' are replaced by a '/'; this would get us to supporting
   a similar probe specification as bcc without the backward
   compatibility headaches.  I can't think of any valid
   cases where SEC() definitions have a ':' that we would
   replace with '/' in error, but I might be missing something.

 - the current scheme doesn't support a raw offset address, since
   it felt un-portable to encourage that, but can add this support
   if needed.

 - The auto-attach behaviour is to attach to all processes.
   It would be good to have a way to specify the attach process
   target. A few possibilities that would be compatible with
   BPF skeleton support are to use the open opts (feels kind of
   wrong conceptually since it's an attach-time attribute) or
   to support opts with attach pid field in "struct bpf_prog_skeleton".
   Latter would even allow a skeleton to attach to multiple
   different processes with prog-level granularity (perhaps a union
   of the various attach opts or similar?). There may be other
   ways to achieve this.

Changes since RFC [1]:
 - focused on uprobe entry/return, omitting USDT attach (Andrii)
 - use ELF program headers in calculating relative offsets, as this
   works for the case where we do not specify a process.  The
   previous approach relied on /proc/pid/maps so would not work
   for the "all processes" case (where pid is -1).
 - add support for auto-attach (patch 2)
 - fix selftests to use a real library function.  I didn't notice
   selftests override the usleep(3) definition, so as a result of
   this, the libc function wasn't being called, so usleep() should
   not be used to test shared library attach.  Also switch to
   using libc path as the binary argument for these cases, as
   specifying a shared library function name for a program is
   not supported.  Tests now instrument malloc/free.
 - added selftest that verifies auto-attach.

[1] https://lore.kernel.org/bpf/1642004329-23514-1-git-send-email-alan.maguire@oracle.com/
[2] https://www.kernel.org/doc/html/latest/trace/uprobetracer.html

Alan Maguire (3):
  libbpf: support function name-based attach for uprobes
  libbpf: add auto-attach for uprobes based on section name
  selftests/bpf: add tests for u[ret]probe attach by name

 tools/lib/bpf/libbpf.c                             | 259 ++++++++++++++++++++-
 tools/lib/bpf/libbpf.h                             |  10 +-
 .../selftests/bpf/prog_tests/attach_probe.c        | 114 +++++++--
 .../selftests/bpf/progs/test_attach_probe.c        |  33 +++
 4 files changed, 396 insertions(+), 20 deletions(-)

-- 
1.8.3.1