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]

Message-ID: <20201117181931.4gcbp4ubs2dccw4k@ast-mbp>
Date:   Tue, 17 Nov 2020 10:19:31 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Jesper Dangaard Brouer <brouer@...hat.com>,
        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>
Subject: Re: [PATCHv5 iproute2-next 0/5] iproute2: add libbpf support

On Mon, Nov 16, 2020 at 08:38:15PM -0700, David Ahern wrote:
> 
> 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.

Your own nexthop enhancements in the kernel code follow 1-1 with iproute2
changes. So the users do chase the latest kernel and the latest iproute2
if they want the networking feature.
Yet you're arguing that for bpf features they shouldn't have such expectations
with iproute2 which will not support the latest kernel bpf features.
I sense a lot of bias here.

> 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.

Please stop this misinformation spread.
Multiple people explained numerous times that libbpf takes care of
backward compatibility.

> That said, the legacy bpf code in iproute2 has created some
> expectations, and iproute2 can not simply remove existing capabilities.

It certainly can remove them by moving to libbpf.

> 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.

In other words you're saying that upstream iproute2 is a kitchen sink
of untested combinations of libraries and distros suppose to do a ton
of extra work to provide their users a quality iproute2.