netdev - Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need

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: <87tv7olzwd.fsf@toke.dk>
Date:   Fri, 01 Nov 2019 10:16:50 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jiri Olsa <jolsa@...hat.com>
Cc:     Björn Töpel <bjorn.topel@...il.com>,
        Magnus Karlsson <magnus.karlsson@...il.com>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Björn Töpel <bjorn.topel@...el.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Network Development <netdev@...r.kernel.org>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        bpf <bpf@...r.kernel.org>, degeneloy@...il.com,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup

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

> On Thu, Oct 31, 2019 at 12:18 PM Jiri Olsa <jolsa@...hat.com> wrote:
>> >
>> > yes. older vmlinux and newer installed libbpf.so
>> > or any version of libbpf.a that is statically linked into apps
>> > is something that libbpf code has to support.
>> > The server can be rebooted into older than libbpf kernel and
>> > into newer than libbpf kernel. libbpf has to recognize all these
>> > combinations and work appropriately.
>> > That's what backward and forward compatibility is.
>> > That's what makes libbpf so difficult to test, develop and code review.
>> > What that particular server has in /usr/include is irrelevant.
>>
>> sure, anyway we can't compile following:
>>
>>         tredaell@...ebaran ~ $ echo "#include <bpf/xsk.h>" | gcc -x c -
>>         In file included from <stdin>:1:
>>         /usr/include/bpf/xsk.h: In function ‘xsk_ring_prod__needs_wakeup’:
>>         /usr/include/bpf/xsk.h:82:21: error: ‘XDP_RING_NEED_WAKEUP’ undeclared (first use in this function)
>>            82 |  return *r->flags & XDP_RING_NEED_WAKEUP;
>>         ...
>>
>>         XDP_RING_NEED_WAKEUP is defined in kernel v5.4-rc1 (77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10).
>>         XSK_UNALIGNED_BUF_ADDR_MASK and XSK_UNALIGNED_BUF_OFFSET_SHIFT are defined in kernel v5.4-rc1 (c05cd3645814724bdeb32a2b4d953b12bdea5f8c).
>>
>> with:
>>   kernel-headers-5.3.6-300.fc31.x86_64
>>   libbpf-0.0.5-1.fc31.x86_64
>>
>> if you're saying this is not supported, I guess we could be postponing
>> libbpf rpm releases until we have the related fedora kernel released
>
> why? github/libbpf is the source of truth for building packages
> and afaik it builds fine.
>
>> or how about inluding uapi headers in libbpf-devel.. but that might
>> actualy cause more confusion
>
> Libraries (libbpf or any other) should not install headers that
> typically go into /usr/include/
> if_xdp.h case is not unique.
> We'll surely add another #define, enum, etc to uapi/linux/bpf.h tomorrow.
> And we will not copy paste these constants and types into tools/lib/bpf/.
> In kernel tree libbpf development is using kernel tree headers.
> No problem there for libbpf developers.
> Packages are built out of github/libbpf that has a copy of uapi headers
> necessary to create packages.
> No problem there for package builders either.
> But libbpf package is not going to install those uapi headers.
> libbpf package installs only libbpf own headers (like libbpf.h)
> The users that want to build against the latest libbpf package need
> to install corresponding uapi headers package.
> I don't think such dependency is specified in rpm scripts.
> May be it is something to fix? Or may be not.
> Some folks might not want to update all of /usr/include to bring libbpf-devel.
> Then it would be their responsibility to get fresh /usr/include headers.

We can certainly tie libbpf to the kernel version. The obvious way to do
that is to just ship the version of libbpf that's in the kernel tree of
whatever kernel version the distro ships. But how will we handle
bugfixes, then? You've explicitly stated that libbpf gets no bugfixes
outside of bpf-next...

-Toke