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:   Wed, 11 Nov 2020 09:33:05 -0700
From:   David Ahern <dsahern@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jiri Benc <jbenc@...hat.com>,
        Edward Cree <ecree@...arflare.com>,
        Hangbin Liu <haliu@...hat.com>,
        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>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

On 11/11/20 8:06 AM, Daniel Borkmann wrote:
> 
> Not really. What you imply here is that we're living in a perfect world
> and that
> all distros follow suite and i) add libbpf dependency to their official
> iproute2
> package, ii) upgrade iproute2 package along with new kernel releases and
> iii)
> upgrade libbpf along with it so that users are able to develop BPF
> programs against
> the feature set that the kernel offers (as intended). These are a lot of
> moving parts
> to get right, and as I pointed out earlier in the conversation, it took
> major distros
> 2 years to get their act together to officially include bpftool as a
> package -

Yes, there are lot of moving parts and that puts a huge burden on
distributions. The trend that related s/w is outdated 2-3 months after a
release can be taken as a sign that bpf is not stable and ready for
distributions to take on and support.

bpftool is only 3 years old (Oct 2017 is first kernel commit). You can
not expect distributions to chase every whim from kernel developers, so
bpftool needed to evolve and prove its usefulness. It has now, so really
the disappointment should be limited to distributions over the past 12
months, especially Ubuntu 20.04 (most recent LTS) not having a libbpf
and bpftool releases. But again, 20.04 was too old for BTF 3 months
after it was released and that comes back to the bigger question of
whether bpf is really ready for distributions to support. More below.

Focusing on the future: for Ubuntu (and Debian?) bpftool is in the
linux-tools-common package. perf has already trained distributions to
release a tools package with kernel releases. That means bpftool updates
follow the kernel cadence. bpftool requires libbpf and I believe given
the feature dependencies will force libbpf versions to follow kernel
releases, so I believe your goal is going to be achieved by those
dependencies.

But there is an on-going nagging problem which needs to be acknowledged
and solved. As an *example*, Ubunutu has kernel updates to get new
hardware support (HWE releases). Updating kernels on an LTS is
problematic when the kernel update requires toolchain updates to
maintain features (DEBUG_INFO_BTF) and library updates to get tools for
that kernel version working. That is a huge disruption to their
customers who want stability — the whole reason for LTS distributions.