netdev - Re: [PATCH v3 bpf-next 0/4] libbpf: name-based u[ret]probe attach

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: <a74d3ab8-152a-b81b-54f3-9a46d6ba682d@iogearbox.net>
Date:   Tue, 1 Feb 2022 09:52:17 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Alan Maguire <alan.maguire@...cle.com>, andrii@...nel.org,
        ast@...nel.org
Cc:     kafai@...com, songliubraving@...com, yhs@...com,
        john.fastabend@...il.com, kpsingh@...nel.org, jolsa@...nel.org,
        sunyucong@...il.com, netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v3 bpf-next 0/4] libbpf: name-based u[ret]probe attach

Hi Alan,

On 1/31/22 5:12 PM, Alan Maguire wrote:
> This patch series is a refinement of the RFC patchset [1], focusing
> on support for attach by name for uprobes and uretprobes. v3
> because there was an earlier RFC [2].
> 
> 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.
> Patch 1 adds the "func_name" option to allow uprobe attach by
> name; the mechanics are described there.
> 
> Having name-based support allows us to support auto-attach for
> uprobes; patch 2 adds auto-attach support while attempting
> to handle backwards-compatibility issues that arise.  The format
> supported is
> 
> u[ret]probe//path/2/binary:[raw_offset|function[+offset]]
> 
> For example, to attach to libc malloc:
> 
> SEC("uprobe//usr/lib64/libc.so.6:malloc")
> 
> Patch 3 introduces a helper function to trace_helpers, allowing
> us to retrieve the path to a library by reading /proc/self/maps.
> 
> Finally patch 4 add tests to the attach_probe selftests covering
> attach by name, auto-attach and auto-attach failure.

Looks like the selftest in the series fails the BPF CI (test_progs & test_progs-no_alu32):

https://github.com/kernel-patches/bpf/runs/5012260907?check_suite_focus=true

   [...]
   test_attach_probe:PASS:uprobe_offset 0 nsec
   test_attach_probe:PASS:ref_ctr_offset 0 nsec
   test_attach_probe:PASS:skel_open 0 nsec
   test_attach_probe:PASS:check_bss 0 nsec
   test_attach_probe:PASS:attach_kprobe 0 nsec
   test_attach_probe:PASS:attach_kretprobe 0 nsec
   test_attach_probe:PASS:uprobe_ref_ctr_before 0 nsec
   test_attach_probe:PASS:attach_uprobe 0 nsec
   test_attach_probe:PASS:uprobe_ref_ctr_after 0 nsec
   test_attach_probe:PASS:attach_uretprobe 0 nsec
   test_attach_probe:PASS:auto-attach should fail for old-style name 0 nsec
   test_attach_probe:PASS:attach_uprobe_byname 0 nsec
   test_attach_probe:PASS:attach_uretprobe_byname 0 nsec
   test_attach_probe:PASS:get path to libc 0 nsec
   test_attach_probe:PASS:find libc path in /proc/self/maps 0 nsec
   libbpf: failed to open 7f55b225c000-7f55b2282000 r--p 00000000 fe:00 3381                       /usr/lib/libc-2.32.so: No such file or directory
   test_attach_probe:FAIL:attach_uprobe_byname2 unexpected error: -2
   test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec
   #4 attach_probe:FAIL
   [...]

Thanks,
Daniel