linux-kernel - Re: [PATCH bpf-next v5 2/9] libbpf: Add support for extended bpf syscall

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: <CAEf4Bzbig7bZoaOgOWvcv1W46iUe6m77NpToghu+vZCvQYsMpA@mail.gmail.com>
Date: Fri, 16 Jan 2026 14:27:38 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Leon Hwang <leon.hwang@...ux.dev>
Cc: bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Shuah Khan <shuah@...nel.org>, Christian Brauner <brauner@...nel.org>, 
	Seth Forshee <sforshee@...nel.org>, Yuichiro Tsuji <yuichtsu@...zon.com>, 
	Andrey Albershteyn <aalbersh@...hat.com>, Willem de Bruijn <willemb@...gle.com>, 
	Jason Xing <kerneljasonxing@...il.com>, Tao Chen <chen.dylane@...ux.dev>, 
	Mykyta Yatsenko <yatsenko@...a.com>, Kumar Kartikeya Dwivedi <memxor@...il.com>, 
	Anton Protopopov <a.s.protopopov@...il.com>, Amery Hung <ameryhung@...il.com>, 
	Rong Tao <rongtao@...tc.cn>, linux-kernel@...r.kernel.org, linux-api@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, kernel-patches-bot@...com
Subject: Re: [PATCH bpf-next v5 2/9] libbpf: Add support for extended bpf syscall

On Fri, Jan 16, 2026 at 5:58 AM Leon Hwang <leon.hwang@...ux.dev> wrote:
>
>
>
> On 2026/1/16 08:42, Andrii Nakryiko wrote:
> > On Mon, Jan 12, 2026 at 6:58 AM Leon Hwang <leon.hwang@...ux.dev> wrote:
> >>
> >> To support the extended BPF syscall introduced in the previous commit,
> >> introduce the following internal APIs:
> >>
> >> * 'sys_bpf_ext()'
> >> * 'sys_bpf_ext_fd()'
> >>   They wrap the raw 'syscall()' interface to support passing extended
> >>   attributes.
> >> * 'probe_sys_bpf_ext()'
> >>   Check whether current kernel supports the extended attributes.
> >>
> >> Signed-off-by: Leon Hwang <leon.hwang@...ux.dev>
> >> ---
> >>  tools/lib/bpf/bpf.c             | 34 +++++++++++++++++++++++++++++++++
> >>  tools/lib/bpf/features.c        |  8 ++++++++
> >>  tools/lib/bpf/libbpf_internal.h |  3 +++
> >>  3 files changed, 45 insertions(+)
> >>
> >> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> >> index 21b57a629916..d44e667aaf02 100644
> >> --- a/tools/lib/bpf/bpf.c
> >> +++ b/tools/lib/bpf/bpf.c
> >> @@ -69,6 +69,40 @@ static inline __u64 ptr_to_u64(const void *ptr)
> >>         return (__u64) (unsigned long) ptr;
> >>  }
> >>
> >> +static inline int sys_bpf_ext(enum bpf_cmd cmd, union bpf_attr *attr,
> >> +                             unsigned int size,
> >> +                             struct bpf_common_attr *common_attr,
> >
> > nit: kernel uses consistent attr_common/size_common pattern, but here
> > you are inverting attr_common -> common_attr, let's not?
> >
>
> Ack.
>
> I'll keep the same pattern.
>
> >> +                             unsigned int size_common)
> >> +{
> >> +       cmd = common_attr ? (cmd | BPF_COMMON_ATTRS) : (cmd & ~BPF_COMMON_ATTRS);
> >> +       return syscall(__NR_bpf, cmd, attr, size, common_attr, size_common);
> >> +}
> >> +
> >> +static inline int sys_bpf_ext_fd(enum bpf_cmd cmd, union bpf_attr *attr,
> >> +                                unsigned int size,
> >> +                                struct bpf_common_attr *common_attr,
> >> +                                unsigned int size_common)
> >> +{
> >> +       int fd;
> >> +
> >> +       fd = sys_bpf_ext(cmd, attr, size, common_attr, size_common);
> >> +       return ensure_good_fd(fd);
> >> +}
> >> +
> >> +int probe_sys_bpf_ext(void)
> >> +{
> >> +       const size_t attr_sz = offsetofend(union bpf_attr, prog_token_fd);
> >> +       union bpf_attr attr;
> >> +       int fd;
> >> +
> >> +       memset(&attr, 0, attr_sz);
> >> +       fd = syscall(__NR_bpf, BPF_PROG_LOAD | BPF_COMMON_ATTRS, &attr, attr_sz, NULL,
> >> +                    sizeof(struct bpf_common_attr));
> >> +       if (fd >= 0)
> >> +               close(fd);
> >
> > hm... close can change errno, this is fragile. If fd >= 0, something
> > is wrong with our detection, just return error right away?
> >
>
> How about capture errno before closing?
>
> err = errno;
> if (fd >= 0)
>         close(fd);
> return err = EFAULT;

not sure what this code is trying to do, but yes, preserving errno is
one way to fix an immediate problem.

But fd should really not be >= 0, and if it is -- it's some problem,
so I'd return an error in that case to keep us aware, which is why I'm
saying I'd just return inside if (fd >= 0) { }

>
> Then, we can wrap all details in probe_sys_bpf_ext().
>
> >> +       return errno == EFAULT;
> >> +}
> >> +

[...]