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]

Message-ID: <87d00svjgx.fsf@toke.dk>
Date:   Wed, 04 Nov 2020 23:35:26 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Edward Cree <ecree@...arflare.com>
Cc:     Hangbin Liu <haliu@...hat.com>, David Ahern <dsahern@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        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>
Subject: Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <ecree@...arflare.com> wrote:
>>
>> On 04/11/2020 03:11, Alexei Starovoitov wrote:
>> > The user will do 'tc -V'. Does version mean anything from bpf loading pov?
>> > It's not. The user will do "ldd `which tc`" and then what?
>> Is it beyond the wit of man for 'tc -V' to output somethingabout
>>  libbpf version?
>> Other libraries seem to solve these problems all the time, I
>>  haven't seen anyone explain what makes libbpf so special that it
>>  has to be different.
>
> slow vger? Please see Daniel and Andrii detailed explanations.
>
> libbpf is not your traditional library.
> Looking through the installed libraries on my devserver in /lib64/ directory
> I think the closest is libbfd.so
> Then think why gdb always statically links it.

The distinguishing feature is the tool, not the library. For a tool that
intimately depends detailed behaviour, sure it makes sense to statically
link to know exactly which version you have. But for BPF, that is
bpftool, not iproute2.

For iproute2, libbpf serves a very simple function: load a BPF program
from an object file and turn it into an fd that can be attached. For
that, dynamic linking is the right thing to do so library upgrades can
bring in new support without touching the tool itself.

Daniel's example from upthread illustrates it:

bpftool prog load | tc attach

i.e., decoupling load from attach. Which is *exactly* what dynamic
linking in iproute2 would mean, except using ld(1) instead of a pipe!

-Toke