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] [day] [month] [year] [list]

Date:   Wed, 05 Feb 2020 11:37:44 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     David Ahern <dsahern@...il.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)

David Ahern <dsahern@...il.com> writes:

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

Sure, can do.

-Toke