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

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

Date:   Tue, 3 Nov 2020 18:45:59 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Hangbin Liu <haliu@...hat.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>,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On Tue, Nov 03, 2020 at 06:40:44PM -0700, David Ahern wrote:
> On 11/3/20 3:55 PM, Alexei Starovoitov wrote:
> > The bpf support in "tc" command instead of being obviously old and obsolete
> > will be sort-of working with unpredictable delay between released kernel
> > and released iproute2 version. The iproute2 release that suppose to match kernel
> > release will be meaningless.
> 
> iproute2, like all userspace commands, is written to an API and for well
> written APIs the commands should be backward and forward compatible
> across kernel versions. Kernel upgrades do not force an update of the
> entire ecosystem. New userspace on old kernels should again just work.
> New functionality in the new userpsace will not, but detection of that
> is a different problem and relies on kernel APIs doing proper data
> validation.

commands ?!
libbpf is not a library that translates user input into kernel syscalls.
It's not libmnl that is a wrapper for netlink.
It's not libelf either.
libbpf probes kernel features and does different things depending on what it found.
libbpf is the only library I know that is backward and forward compatible.
All other libraries are backwards compatible only.
iproute2 itself is backward compatible only as well.
New devlink feature in iproute2 won't do anything on the kernel that doesn't
have the support.
libbpf, on the other side, has to work on older kernels. New libbpf features
have to gradually degrade when possible.
The users can upgrade and downgrade libbpf version at any time.
They can upgrade and downgrade kernel while keeping libbpf version the same.
The users can upgrade llvm as well and libbpf has to expect unexpected
and deal with all combinations.

> 
> > More so, the upgrade of shared libbpf.so can make older iproute2/tc to do 
> > something new and unpredictable.
> 
> How so? If libbpf is written against kernel APIs and properly versioned,
> it should just work. A new version of libbpf changes the .so version, so
> old commands will not load it.

Please point out where do you see this happening in the patch set.
See tools/lib/bpf/README.rst to understand the versioning.