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]

Message-ID: <alpine.LRH.2.23.451.2201191341380.10931@localhost>
Date:   Wed, 19 Jan 2022 14:03:43 +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 Fri, 14 Jan 2022, Andrii Nakryiko wrote:

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

I've been looking at this, and I've got the following cases working:

- local symbols in a binary. This involves symbol table lookup and 
  relative offset calcuation.
- shared object symbols in a shared object.  In this case, the symbol 
  table values suffice, no adjustment needed.

The former works using the program headers (instead of /proc/pid/maps for
offset computation), so can be run for all processes, lifting the 
limitation in the RFC which only supported name lookup for a specific 
process. Around a hundred lines for this makes it worthwhile I think.

There is one more case, which is a shared library function in a binary -
where I specify "malloc" as the function and /usr/bin/foo as the binary
path.  In this case, for dynamic symbols we can't just look up the symbol 
table in the binary, since the associated values are 0.  Ideally it would 
be nice if the user could just specify "malloc" and not need to use libc 
as the binary path argument, but getting this working is proving to be 
trickier. I've tried making use of PLT section information but no luck 
yet (the idea being we try to use the trampoline address of malloc@@PLT
instead, but I'm still trying to figure out how to extract that).

So I'm wondering if we just fail lookup for that case, assuming the user 
will specify the shared library path if they want to trace a shared library 
function. What do you think? Thanks!

Alan