netdev - Re: [PATCHv5 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:   Mon, 16 Nov 2020 20:38:15 -0700
From:   David Ahern <dsahern@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Hangbin Liu <haliu@...hat.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, Jiri Benc <jbenc@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCHv5 iproute2-next 0/5] iproute2: add libbpf support

On 11/16/20 7:54 AM, Jesper Dangaard Brouer wrote:
> When compiled against dynamic libbpf, then I would use 'ldd' command to
> see what libbpf lib version is used.  When compiled/linked statically
> against a custom libbpf version (already supported via LIBBPF_DIR) then
> *I* think is difficult to figure out that version of libbpf I'm using.
> Could we add the libbpf version info in 'tc -V', as then it would
> remove one of my concerns with static linking.

Adding libbpf version to 'tc -V' and 'ip -V' seems reasonable.

As for the bigger problem, trying to force user space components to
constantly chase latest and greatest S/W versions is not the right answer.

The crux of the problem here is loading bpf object files and what will
most likely be a never ending stream of enhancements that impact the
proper loading of them. bpftool is much more suited to the job of
managing bpf files versus iproute2 which is the de facto implementation
for networking APIs. bpftool ships as part of a common linux tools
package, so it will naturally track kernel versions for those who want /
need latest and greatest versions. Users who are not building their own
agents for managing bpf files (which I think is much more appropriate
for production use cases than forking command line utilities) can use
bpftool to load files, manage maps which are then attached to the
programs, etc, and then invoke iproute2 to handle the networking attach
/ detach / list with detailed information.

That said, the legacy bpf code in iproute2 has created some
expectations, and iproute2 can not simply remove existing capabilities.
Moving iproute2 to libbpf provides an improvement over the current
status by allowing ‘modern’ bpf object files to be loaded without
affecting legacy users, even if it does not allow latest and greatest
bpf capabilities at every moment in time (again, a constantly moving
reference point).

iproute2 is a networking configuration tool, not a bpf management tool.
Hangbin’s approach gives full flexibility to those who roll their own
and for distributions who value stability, it allows iproute2 to use
latest and greatest libbpf for those who want to chase the pot of gold
at the end of the rainbow, or they can choose stability with an OS
distro’s libbpf or legacy bpf. I believe this is the right compromise at
this point in time.