linux-kernel - Re: [PATCH bpf-next v8 3/5] libbpf: Add libbpf_probe_bpf

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4Bzb1Epj9QdSeA02hAypqcbu3a_Nx9Gvj_o-RjukeNrWWeA@mail.gmail.com>
Date: Tue, 25 Feb 2025 09:01:48 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Tao Chen <chen.dylane@...ux.dev>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, eddyz87@...il.com, 
	haoluo@...gle.com, jolsa@...nel.org, qmo@...nel.org, bpf@...r.kernel.org, 
	linux-kernel@...r.kernel.org, chen.dylane@...il.com, 
	Tao Chen <dylane.chen@...iglobal.com>
Subject: Re: [PATCH bpf-next v8 3/5] libbpf: Add libbpf_probe_bpf_kfunc API

On Mon, Feb 24, 2025 at 9:47 PM Tao Chen <chen.dylane@...ux.dev> wrote:
>
> 在 2025/2/25 09:15, Andrii Nakryiko 写道:
> > On Mon, Feb 24, 2025 at 9:02 AM Tao Chen <chen.dylane@...ux.dev> wrote:
> >>
> >> Similarly to libbpf_probe_bpf_helper, the libbpf_probe_bpf_kfunc
> >> used to test the availability of the different eBPF kfuncs on the
> >> current system.
> >>
> >> Cc: Tao Chen <dylane.chen@...iglobal.com>
> >> Reviewed-by: Jiri Olsa <jolsa@...nel.org>
> >> Reviewed-by: Eduard Zingerman <eddyz87@...il.com>
> >> Signed-off-by: Tao Chen <chen.dylane@...ux.dev>
> >> ---
> >>   tools/lib/bpf/libbpf.h        | 19 ++++++++++++-
> >>   tools/lib/bpf/libbpf.map      |  1 +
> >>   tools/lib/bpf/libbpf_probes.c | 51 +++++++++++++++++++++++++++++++++++
> >>   3 files changed, 70 insertions(+), 1 deletion(-)
> >>
> >
> > [...]
> >
> >> +       buf[0] = '\0';
> >> +       ret = probe_prog_load(prog_type, insns, insn_cnt, btf_fd >= 0 ? fd_array : NULL,
> >> +                             buf, sizeof(buf));
> >> +       if (ret < 0)
> >> +               return libbpf_err(ret);
> >> +
> >> +       if (ret > 0)
> >> +               return 1; /* assume supported */
> >> +
> >> +       /* If BPF verifier recognizes BPF kfunc but it's not supported for
> >> +        * given BPF program type, it will emit "calling kernel function
> >> +        * <name> is not allowed". If the kfunc id is invalid,
> >> +        * it will emit "kernel btf_id <id> is not a function". If BTF fd
> >> +        * invalid in module BTF, it will emit "invalid module BTF fd specified" or
> >> +        * "negative offset disallowed for kernel module function call". If
> >> +        * kfunc prog not dev buound, it will emit "metadata kfuncs require
> >> +        * device-bound program".
> >> +        */
> >> +       if (strstr(buf, "not allowed") || strstr(buf, "not a function") ||
> >> +          strstr(buf, "invalid module BTF fd") ||
> >
> > why is invalid module BTF FD not an error (negative return)?
> >
> >> +          strstr(buf, "negative offset disallowed") ||
> >> +          strstr(buf, "device-bound program"))
> >> +               return 0;
> >> +
> >> +       return 1;
> >> +}
> >> +
> >>   int libbpf_probe_bpf_helper(enum bpf_prog_type prog_type, enum bpf_func_id helper_id,
> >>                              const void *opts)
> >>   {
> >> --
> >> 2.43.0
> >>
>
> In probe_prog_load, err will be checked and converted into either 0 or 1.

I guess what I was getting at is that providing invalid module BTF FD
is not a "not supported" case, it's an error case (and so should
result in negative return)

>
> --
> Best Regards
> Tao Chen