netdev - Re: [PATCH net-next] libbpf: use map

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:   Thu, 28 Sep 2017 23:44:58 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Craig Gallek <kraigatgoog@...il.com>
CC:     Alexei Starovoitov <ast@...com>,
        "David S . Miller" <davem@...emloft.net>,
        Chonggang Li <chonggangli@...gle.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] libbpf: use map_flags when creating maps

On 09/28/2017 07:33 PM, Craig Gallek wrote:
> On Wed, Sep 27, 2017 at 6:03 PM, Daniel Borkmann <daniel@...earbox.net> wrote:
>> On 09/27/2017 06:29 PM, Alexei Starovoitov wrote:
>>> On 9/27/17 7:04 AM, Craig Gallek wrote:
>>>> From: Craig Gallek <kraig@...gle.com>
[...]
>>>
>>> yes it will break loading of pre-compiled .o
>>> Instead of breaking, let's fix the loader to do it the way
>>> samples/bpf/bpf_load.c does.
>>> See commit 156450d9d964 ("samples/bpf: make bpf_load.c code compatible
>>> with ELF maps section changes")
>>
>> +1, iproute2 loader also does map spec fixup
>>
>> For libbpf it would be good also such that it reduces the diff
>> further between the libbpf and bpf_load so that it allows move
>> to libbpf for samples in future.
>
> Fair enough, I'll try to get this to work more dynamically.  I did
> noticed that the fields of struct bpf_map_def in
> selftests/.../bpf_helpers.h and iproute2's struct bpf_elf_map have
> diverged. The flags field is the only thing missing from libbpf right
> now (and they are at the same offset for both), so it won't be an
> issue for this change, but it is going to make unifying all of these
> things under libbpf not trivial at some point...

Yes, iproute2 uses its own loader with own specifics related to
iproute2. With the above I rather meant that we can reduce the
gap between libbpf and bpf_load from the BPF samples, so that
it would allow us to migrate samples over entirely, there was
unfortunately never a follow-up on 156450d9d964 though, but given
there is need to extend libbpf (I guess mostly due to lpm map
handling ;)), we need to do a similar thing there as well to not
break existing obj files.