netdev - Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201104111708.0595e2a3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 4 Nov 2020 11:17:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.com>,
        David Ahern <dsahern@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Jiri Benc <jbenc@...hat.com>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On Wed, 4 Nov 2020 14:12:47 +0100 Daniel Borkmann wrote:
> If we would have done lib/bpf.c as a dynamic library back then, we wouldn't be
> where we are today since users might be able to start consuming BPF functionality
> just now, don't you agree? This was an explicit design choice back then for exactly
> this reason. If we extend lib/bpf.c or import libbpf one way or another then there
> is consistency across distros and users would be able to consume it in a predictable
> way starting from next major releases. And you could start making this assumption
> on all major distros in say, 3 months from now. The discussion is somehow focused
> on the PoV of /a/ distro which is all nice and good, but the ones consuming the
> loader shipping software /across/ distros are users writing BPF progs, all I'm
> trying to say is that the _user experience_ should be the focus of this discussion
> and right now we're trying hard making it rather painful for them to consume it.

IIUC you're saying that we cannot depend on libbpf updates from distro.
Isn't that a pretty bad experience for all users who would like to link
against it? There are 4 components (kernel, lib, tools, compiler) all
need to be kept up to date for optimal user experience. Cutting corners
with one of them leads nowhere medium term IMHO.

Unless what you guys are saying is that libbpf is _not_ supposed to be
backward compatible from the user side, and must be used a submodule.
But then why bother defining ABI versions, or build it as an .so at all.

I'm also confused by the testing argument. Surely the solution is to
add unit / system tests for iproute2. Distros will rebuild packages
when dependencies change and retest. If we have 0 tests doesn't matter
what update strategy there is.