netdev - Re: [PATCH bpf-next v3 0/8] libbpf: rename btf__get_from_id() and btf_

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]

Date:   Fri, 30 Jul 2021 14:54:03 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Quentin Monnet <quentin@...valent.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v3 0/8] libbpf: rename btf__get_from_id() and
 btf__load() APIs, support split BTF

On Fri, Jul 30, 2021 at 1:23 PM Quentin Monnet <quentin@...valent.com> wrote:
>
> On Fri, 30 Jul 2021 at 18:24, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>
> [...]
>
> > > > The right approach will be to define
> > > > LIBBPF_MAJOR_VERSION/LIBBPF_MINOR_VERSION in some sort of
> > > > auto-generated header, included from libbpf_common.h and installed as
> > > > part of libbpf package.
> > >
> > > So generating this header is easy. Installing it with the other headers
> > > is simple too. It becomes a bit trickier when we build outside of the
> > > directory (it seems I need to pass -I$(OUTPUT) to build libbpf).
> >
> > Not sure why using the header is tricky. We auto-generate
> > bpf_helper_defs.h, which is included from bpf_helpers.h, which is
> > included in every single libbpf-using application. Works good with no
> > extra magic.
>
> bpf_helper_defs.h is the first thing I looked at, and I processed
> libbpf_version.h just like it. But there is a difference:
> bpf_helper_defs.h is _not_ included in libbpf itself, nor is it needed
> in bpftool at the bootstrap stage (it is only included from the eBPF
> skeletons for profiling or showing PIDs etc., which are compiled after
> libbpf). The version header is needed in both cases.

Oh, in that sense. Yeah, sure, I didn't think that would qualify as
tricky. But yeah, -I$(OUTPUT) or something along those lines is fine.

>
> >
> > >
> > > The step I'm most struggling with at the moment is bpftool, which
> > > bootstraps a first version of itself before building libbpf, by looking
> > > at the headers directly in libbpf's directory. It means that the
> > > generated header with the version number has not yet been generated. Do
> > > you think it is worth changing bpftool's build steps to implement this
> > > deprecation helper?
> >
> > If it doesn't do that already, bpftool should do `make install` for
> > libbpf, not just build. Install will put all the headers, generated or
> > otherwise, into a designated destination folder, which should be
> > passed as -I parameter. But that should be already happening due to
> > bpf_helper_defs.h.
>
> bpftool does not run "make install". It compiles libbpf passing
> "OUTPUT=$(LIBBPF_OUTPUT)", sets LIBBPF_PATH to the same directory, and
> then adds "-I$(LIBBPF_PATH)" for accessing bpf_helper_defs.h and compile
> its eBPF programs. It is possible to include libbpf_version.h the same
> way, but only after libbpf has been compiled, after the bootstrap.
>
> I'll look into updating the Makefile to compile and install libbpf
> before the bootstrap, when I have some time.

Cool, `make install` is the best way as it prevents accidental usage
of libbpf's internal header. So it's a good change to make.