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, 10 Nov 2020 12:47:28 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Jamal Hadi Salim <jhs@...atatu.com>,
        David Ahern <dsahern@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Hangbin Liu <haliu@...hat.com>
CC:     Andrii Nakryiko <andrii.nakryiko@...il.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 05/11/2020 14:05, Jamal Hadi Salim wrote:
> On 2020-11-04 10:19 p.m., David Ahern wrote:
>
> [..]
>> Similarly, it is not realistic or user friendly to *require* general
>> Linux users to constantly chase latest versions of llvm, clang, dwarves,
>> bcc, bpftool, libbpf, (I am sure I am missing more)
>
> 2cents feedback from a dabbler in ebpf on user experience:
>
> What David described above *has held me back*.
If we're doing 2¢... I gave up on trying to keep ebpf_asmabreast
 of all the latest BPF and BTF features quite some time ago, since
 there was rarely any documentation and the specifications for BPF
 elves were basically "whatever latest clang does".
The bpf developers seem to have taken the position that since
 they're in control of clang, libbpf and the kernel, they can make
 their changes across all three and not bother with the specs that
 would allow other toolchains to interoperate.  As a result of
 which, that belief has now become true — while ebpf_asm will
 still work for what it always did (simple XDP programs), it is
 unlikely ever to gain CO-RE support so is no longer a live
 alternative to clang for BPF in general.
Of course the bpf developers are well within their rights to not
 care about that.  But I think it illustrates why having to
 interoperate with systems outside their control and mix-and-match
 versioning of various components provides external discipline that
 is sorely needed if the BPF ecosystem is to remain healthy.
That is why I am opposed to iproute2 'vendoring' libbpf.

-ed