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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 30 Jul 2021 21:23:02 +0100
From:   Quentin Monnet <quentin@...valent.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.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, 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.

>
> >
> > 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.