linux-kernel - Re: [PATCH bpf-next v8 4/5] libbpf: Init kprobe prog expected_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] [day] [month] [year] [list]

Message-ID: <CAEf4BzY85DmfwRruD4tnTj+UiRTk64k1N5vO69cdL1T7H+QTXw@mail.gmail.com>
Date: Tue, 25 Feb 2025 09:04:58 -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
Subject: Re: [PATCH bpf-next v8 4/5] libbpf: Init kprobe prog
 expected_attach_type for kfunc probe

On Mon, Feb 24, 2025 at 9:44 PM Tao Chen <chen.dylane@...ux.dev> wrote:
>
> 在 2025/2/25 09:15, Andrii Nakryiko 写道:
> > On Mon, Feb 24, 2025 at 9:03 AM Tao Chen <chen.dylane@...ux.dev> wrote:
> >>
> >> Kprobe prog type kfuncs like bpf_session_is_return and
> >> bpf_session_cookie will check the expected_attach_type,
> >> so init the expected_attach_type here.
> >>
> >> Signed-off-by: Tao Chen <chen.dylane@...ux.dev>
> >> ---
> >>   tools/lib/bpf/libbpf_probes.c | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/tools/lib/bpf/libbpf_probes.c b/tools/lib/bpf/libbpf_probes.c
> >> index 8efebc18a215..bb5b457ddc80 100644
> >> --- a/tools/lib/bpf/libbpf_probes.c
> >> +++ b/tools/lib/bpf/libbpf_probes.c
> >> @@ -126,6 +126,7 @@ static int probe_prog_load(enum bpf_prog_type prog_type,
> >>                  break;
> >>          case BPF_PROG_TYPE_KPROBE:
> >>                  opts.kern_version = get_kernel_version();
> >> +               opts.expected_attach_type = BPF_TRACE_KPROBE_SESSION;
> >
> > so KPROBE_SESSION is relative recent feature, if we unconditionally
> > specify this, we'll regress some feature probes for old kernels where
> > KPROBE_SESSION isn't supported, no?
> >
>
> Yeah, maybe we can detect the kernel version first, will fix it.

Hold on. I think the entire probing API is kind of unfortunately
inadequate. Just the fact that we randomly pick some specific
expected_attach_type to do helpers/kfunc compatibility detection is
telling. expected_attach_type can change a set of available helpers,
and yet it's not even an input parameter for either
libbpf_probe_bpf_helper() or kfunc variant you are trying to add.

Basically, I'm questioning the validity of even adding this API to
libbpf. It feels like this kind of detection is simple enough for
application to do on its own.

>
> +               if (opts.kern_version >= KERNEL_VERSION(6, 12, 0))
> +                       opts.expected_attach_type =BPF_TRACE_KPROBE_SESSION;

no, we shouldn't hard-code kernel version for feature detection (but
also see above, I'm not sure this API should be added in the first
place)

>
> > pw-bot: cr
> >
> >>                  break;
> >>          case BPF_PROG_TYPE_LIRC_MODE2:
> >>                  opts.expected_attach_type = BPF_LIRC_MODE2;
> >> --
> >> 2.43.0
> >>
>
>
> --
> Best Regards
> Tao Chen