netdev - Re: [PATCH v3 bpf-next 2/4] libbpf: add auto-attach for uprobes based on section 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: <CAEf4Bzb9xhpn5asJo7cwhL61DawqtuL_MakdU0YZwOeWuaRq6A@mail.gmail.com>
Date:   Fri, 4 Feb 2022 11:22:32 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alan Maguire <alan.maguire@...cle.com>
Cc:     Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        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: [PATCH v3 bpf-next 2/4] libbpf: add auto-attach for uprobes based
 on section name

On Mon, Jan 31, 2022 at 8:13 AM Alan Maguire <alan.maguire@...cle.com> wrote:
>
> Now that u[ret]probes can use name-based specification, it makes
> sense to add support for auto-attach based on SEC() definition.
> The format proposed is
>
>         SEC("u[ret]probe//path/to/prog:[raw_offset|[function_name[+offset]]")
>
> For example, to trace malloc() in libc:
>
>         SEC("uprobe//usr/lib64/libc.so.6:malloc")

I assume that path to library can be relative path as well, right?

Also, should be look at trying to locate library in the system if it's
specified as "libc"? Or if the binary is "bash", for example. Just
bringing this up, because I think it came up before in the context of
one of libbpf-tools.

>
> Auto-attach is done for all tasks (pid -1).
>
> Note that there is a backwards-compatibility issue here.  Consider a BPF
> object consisting of a set of BPF programs, including a uprobe program.
> Because uprobes did not previously support auto-attach, it's possible that
> because the uprobe section name is not in auto-attachable form, overall
> BPF skeleton attach would now fail due to the failure of the uprobe program
> to auto-attach.  So we need to handle the case of auto-attach failure where
> the form of the section name is not suitable for auto-attach without
> a complete attach failure.  On surveying the code, bpf_program__attach()
> already returns -ESRCH in cases where no auto-attach function is
> supplied, so for consistency with that - and because that return value
> is less likely to collide with actual attach failures than -EOPNOTSUPP -
> it is used as the attach function return value signalling auto-attach
> is not possible.

I'm actually working on generalizing and extending this part of
libbpf's SEC() handling, I should post code today or early next week.
So we can base your code on those changes and we won't need to worry
about error code collisions.

>
> Signed-off-by: Alan Maguire <alan.maguire@...cle.com>
> ---
>  tools/lib/bpf/libbpf.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 74 insertions(+), 3 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index eb95629..e2b4415 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -8581,6 +8581,7 @@ int bpf_program__set_log_buf(struct bpf_program *prog, char *log_buf, size_t log
>  }
>

[...]