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:   Thu, 12 Nov 2020 23:36:25 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        David Ahern <dsahern@...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

Daniel Borkmann <daniel@...earbox.net> writes:

>> Besides, for the entire history of BPF support in iproute2 so far, the
>> benefit has come from all the features that libbpf has just started
>> automatically supporting on load (BTF, etc), so users would have
>> benefited from automatic library updates had it *not* been vendored in.
>
> 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 - I'm not making this up, and this sort of pace
> is simply not sustainable. It's also not clear whether distros will
> get point iii) correct.

I totally get that you've been frustrated with the distro adoption and
packaging of BPF-related tools. And rightfully so. I just don't think
that the answer to this is to try to work around distros, but rather to
work with them to get things right.

I'm quite happy to take a shot at getting a cross-distro effort going in
this space; really, having well-supported BPF tooling ought to be in
everyone's interest!

-Toke

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ