netdev - Re: [PATCHv5 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20201117023757.qypmhucuws3sajyb@ast-mbp>
Date:   Mon, 16 Nov 2020 18:37:57 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Hangbin Liu <haliu@...hat.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        David Ahern <dsahern@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Jiri Benc <jbenc@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCHv5 iproute2-next 0/5] iproute2: add libbpf support

On Mon, Nov 16, 2020 at 03:54:46PM +0100, Jesper Dangaard Brouer wrote:
> 
> Thus, IMHO we MUST move forward and get started with converting
> iproute2 to libbpf, and start on the work to deprecate the build in
> BPF-ELF-loader.  I would prefer ripping out the BPF-ELF-loader and
> replace it with libbpf that handle the older binary elf-map layout, but
> I do understand if you want to keep this around. (at least for the next
> couple of releases).

I don't understand why legacy code has to be around.
Having the legacy code and an option to build tc without libbpf creates
backward compatibility risk to tc users:
Newer tc may not load bpf progs that older tc did.

> I actually fear that it will be a bad user experience, when we start to
> have multiple userspace tools that load BPF, but each is compiled and
> statically linked with it own version of libbpf (with git submodule an
> increasing number of tools will have more variations!).

So far people either freeze bpftool that they use to load progs
or they use libbpf directly in their applications.
Any other way means that the application behavior will be unpredictable.
If a company built a bpf-based product and wants to distibute such
product as a package it needs a way to specify this dependency in pkg config.
'tc -V' is not something that can be put in a spec.
The main iproute2 version can be used as a dependency, but it's meaningless
when presence of libbpf and its version is not strictly derived from
iproute2 spec.
The users should be able to write in their spec:
BuildRequires: iproute-tc >= 5.10
and be confident that tc will load the prog they've developed and tested.

> I actually thinks it makes sense to have iproute2 require a specific
> libbpf version, and also to move this version requirement forward, as
> the kernel evolves features that gets added into libbpf. 

+1