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:40:44 -0700
From:   David Ahern <dsahern@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...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 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.

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