netdev - Re: [PATCH bpf-next 4/6] libbpf: add kernel module BTF support for CO-RE relocations

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: <CAEf4BzbzcjjiqN=dReEp8xTcBHsFJmewKUyvU83S2sU+0_FTjg@mail.gmail.com>
Date:   Thu, 19 Nov 2020 19:31:54 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Maciej Fijalkowski <maciej.fijalkowski@...el.com>
Cc:     Andrii Nakryiko <andrii@...nel.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 4/6] libbpf: add kernel module BTF support for
 CO-RE relocations

On Thu, Nov 19, 2020 at 6:14 PM Maciej Fijalkowski
<maciej.fijalkowski@...el.com> wrote:
>
> On Thu, Nov 19, 2020 at 05:24:43PM -0800, Andrii Nakryiko wrote:
> > On Thu, Nov 19, 2020 at 4:55 PM Maciej Fijalkowski
> > <maciej.fijalkowski@...el.com> wrote:
> > >
> > > On Thu, Nov 19, 2020 at 03:22:42PM -0800, Andrii Nakryiko wrote:
> > > > Teach libbpf to search for candidate types for CO-RE relocations across kernel
> > > > modules BTFs, in addition to vmlinux BTF. If at least one candidate type is
> > > > found in vmlinux BTF, kernel module BTFs are not iterated. If vmlinux BTF has
> > > > no matching candidates, then find all kernel module BTFs and search for all
> > > > matching candidates across all of them.
> > > >
> > > > Kernel's support for module BTFs are inferred from the support for BTF name
> > > > pointer in BPF UAPI.
> > > >
> > > > Signed-off-by: Andrii Nakryiko <andrii@...nel.org>
> > > > ---
> > > >  tools/lib/bpf/libbpf.c | 185 ++++++++++++++++++++++++++++++++++++++---
> > > >  1 file changed, 172 insertions(+), 13 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > > +static int probe_module_btf(void)
> > > > +{
> > > > +     static const char strs[] = "\0int";
> > > > +     __u32 types[] = {
> > > > +             /* int */
> > > > +             BTF_TYPE_INT_ENC(1, BTF_INT_SIGNED, 0, 32, 4),
> > > > +     };
> > > > +     struct bpf_btf_info info;
> > > > +     __u32 len = sizeof(info);
> > > > +     char name[16];
> > > > +     int fd, err;
> > > > +
> > > > +     fd = libbpf__load_raw_btf((char *)types, sizeof(types), strs, sizeof(strs));
> > > > +     if (fd < 0)
> > > > +             return 0; /* BTF not supported at all */
> > > > +
> > > > +     len = sizeof(info);
> > >
> > > nit: reinit of len
> > >
> >
> > oops, right, I'll remove it
> >
> >
> > > > +     memset(&info, 0, sizeof(info));
> > >
> > > use len in memset
> >
> > why?
>
> Hm, just to make use of local var? We might argue that current version is

I agree, I think sizeof(info) is more readable. But my point is that
if you suggest something, please provide at least some argument for
why you think it's better or why existing code is worse or wrong (if
you think it is).

> more readable, but then again I would question the len's existence.

len is passed to the kernel by reference and the kernel is updating it
with the actual length it has (which could be <, ==, or > than what
the program specified). So it has to be in a variable.

>
> Do whatever you want, these were just nits :)
>
> >
> > >
> > > > +     info.name = ptr_to_u64(name);
> > > > +     info.name_len = sizeof(name);
> > > > +
> > > > +     /* check that BPF_OBJ_GET_INFO_BY_FD supports specifying name pointer;
> > > > +      * kernel's module BTF support coincides with support for
> > > > +      * name/name_len fields in struct bpf_btf_info.
> > > > +      */
> > > > +     err = bpf_obj_get_info_by_fd(fd, &info, &len);

here -------------------------------------------------^^^^

> > > > +     close(fd);
> > > > +     return !err;
> > > > +}
> > >
> > > [...]