netdev - Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)

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: <d5434db9-1899-776d-c4cd-918e2418175d@gmail.com>
Date:   Tue, 4 Feb 2020 16:13:19 -0700
From:   David Ahern <dsahern@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        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>
Subject: Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)

On 2/4/20 3:35 PM, Toke Høiland-Jørgensen wrote:
> 
>> Most likely, making iproute2 use libbpf statically is going to be
>> challenging and I am not sure it is the right thing to do (unless the
>> user is building a static version of iproute2 commands).
> 
> Linking dynamically would imply a new dependency. I'm not necessarily
> against that, but would it be acceptable from your PoV? And if so,
> should we keep the current internal BPF code for when libbpf is not
> available, or would it be acceptable to not be able to load BPF programs
> if libbpf is not present (similar to how the libelf dependency works
> today)?

iproute2 recently gained the libmnl dependency for extack. Seems like
libbpf falls into the similar category.

> 
>> 2. git submodules can be a PITA to deal with (e.g., jumping between
>> branches and versions), so there needs to be a good reason for it.
> 
> Yes, totally with you on that. Another option could be to just copy the
> files into the iproute2 tree, and update them the same way the kernel
> headers are? Or maybe doing fancy things like this:
> https://github.com/apenwarr/git-subtrac

kernel uapi is a totally different reason to import the headers. bpf
functionality is an add-on.

I would like to see iproute2 work with libbpf. Given libbpf's current
status and availability across OS'es that is going to be a challenge for
a lot of OS'es which is why I suggested the HAVE_LIBBPF check falls back
to existing code if libbpf is not installed.

> 
>> 3. iproute2 code needs to build for a wide range of OSes and not lose
>> functionality compared to what it has today.
> 
> Could you be a bit more specific about "a wide range of OSes"? I guess
> we could do the work to make sure libbpf builds on all the same
> platforms iproute2 supports, but we'd need something a bit more definite
> to go on...
> 

rhel5/centos5? definitely rhel6/centos6 time frame and forward.

Stephen: has the backwards lifetime ever been stated?

Changing configure to check for existence and fall back to existing code
seems to me the safest option.