netdev - Re: [PATCH bpf-next] libbpf: add BTF-defined map-in-map 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] [day] [month] [year] [list]

Date:   Wed, 22 Apr 2020 10:30:49 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next] libbpf: add BTF-defined map-in-map support

On Wed, Apr 22, 2020 at 4:19 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Andrii Nakryiko <andriin@...com> writes:
>
> > As discussed at LPC 2019 ([0]), this patch brings (a quite belated) support
> > for declarative BTF-defined map-in-map support in libbpf. It allows to define
> > ARRAY_OF_MAPS and HASH_OF_MAPS BPF maps without any user-space initialization
> > code involved.
> >
> > Additionally, it allows to initialize outer map's slots with references to
> > respective inner maps at load time, also completely declaratively.
> >
> > Despite a weak type system of C, the way BTF-defined map-in-map definition
> > works, it's actually quite hard to accidentally initialize outer map with
> > incompatible inner maps. This being C, of course, it's still possible, but
> > even that would be caught at load time and error returned with helpful debug
> > log pointing exactly to the slot that failed to be initialized.
> >
> > Here's the relevant part of libbpf debug log showing pretty clearly of what's
> > going on with map-in-map initialization:
> >
> > libbpf: .maps relo #0: for 6 value 0 rel.r_offset 96 name 260 ('inner_map1')
> > libbpf: .maps relo #0: map 'outer_arr' slot [0] points to map 'inner_map1'
> > libbpf: .maps relo #1: for 7 value 32 rel.r_offset 112 name 249 ('inner_map2')
> > libbpf: .maps relo #1: map 'outer_arr' slot [2] points to map 'inner_map2'
> > libbpf: .maps relo #2: for 7 value 32 rel.r_offset 144 name 249 ('inner_map2')
> > libbpf: .maps relo #2: map 'outer_hash' slot [0] points to map 'inner_map2'
> > libbpf: .maps relo #3: for 6 value 0 rel.r_offset 176 name 260 ('inner_map1')
> > libbpf: .maps relo #3: map 'outer_hash' slot [4] points to map 'inner_map1'
> > libbpf: map 'inner_map1': created successfully, fd=4
> > libbpf: map 'inner_map2': created successfully, fd=5
> > libbpf: map 'outer_arr': created successfully, fd=7
> > libbpf: map 'outer_arr': slot [0] set to map 'inner_map1' fd=4
> > libbpf: map 'outer_arr': slot [2] set to map 'inner_map2' fd=5
> > libbpf: map 'outer_hash': created successfully, fd=8
> > libbpf: map 'outer_hash': slot [0] set to map 'inner_map2' fd=5
> > libbpf: map 'outer_hash': slot [4] set to map 'inner_map1' fd=4
> >
> > See also included selftest with some extra comments explaining extra details
> > of usage.
>
> Could you please put an example of usage in the commit message as well?
> Easier to find that way, especially if the selftests are not handy (such
> as in the libbpf github repo).

Yes, good point. I will add it in v2 after I get some initial feedback on v1.

>
> -Toke
>