netdev - Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically

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:   Tue, 3 Dec 2019 21:52:11 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Michael Petlan <mpetlan@...hat.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        Quentin Monnet <quentin.monnet@...ronome.com>
Subject: Re: [PATCHv4 0/6] perf/bpftool: Allow to link libbpf dynamically

On Mon, Dec 2, 2019 at 1:15 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Ah, that is my mistake: I was getting dynamic libbpf symbols with this
> approach, but that was because I had the version of libbpf.so in my
> $LIBDIR that had the patch to expose the netlink APIs as versioned
> symbols; so it was just pulling in everything from the shared library.
>
> So what I was going for was exactly what you described above; but it
> seems that doesn't actually work. Too bad, and sorry for wasting your
> time on this :/

bpftool is currently tightly coupled with libbpf and very likely
in the future the dependency will be even tighter.
In that sense bpftool is an extension of libbpf and libbpf is an extension
of bpftool.
Andrii is working on set of patches to generate user space .c code
from bpf program.
bpftool will be generating the code that is specific for the version
bpftool and for
the version of libbpf. There will be compatibility layers as usual.
But in general the situation where a bug in libbpf is so criticial
that bpftool needs to repackaged is imo less likely than a bug in
bpftool that will require re-packaging of libbpf.
bpftool is quite special. It's not a typical user of libbpf.
The other way around is more correct. libbpf is a user of the code
that bpftool generates and both depend on each other.
perf on the other side is what typical user space app that uses
libbpf will look like.
I think keeping bpftool in the kernel while packaging libbpf
out of github was an oversight.
I think we need to mirror bpftool into github/libbpf as well
and make sure they stay together. The version of libbpf == version of bpftool.
Both should come from the same package and so on.
May be they can be two different packages but
upgrading one should trigger upgrade of another and vice versa.
I think one package would be easier though.
Thoughts?