netdev - Re: [PATCH bpf-next 2/6] libbpf: move bpf_helpers.h, bpf

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]

Date:   Tue, 1 Oct 2019 12:44:23 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        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 2/6] libbpf: move bpf_helpers.h, bpf_endian.h
 into libbpf

On Tue, Oct 1, 2019 at 12:18 PM John Fastabend <john.fastabend@...il.com> wrote:
>
> Toke Høiland-Jørgensen wrote:
> >
> > > +struct bpf_map_def {
> > > +   unsigned int type;
> > > +   unsigned int key_size;
> > > +   unsigned int value_size;
> > > +   unsigned int max_entries;
> > > +   unsigned int map_flags;
> > > +   unsigned int inner_map_idx;
> > > +   unsigned int numa_node;
> > > +};
> >
> > Didn't we agree on no new bpf_map_def ABI in libbpf, and that all
> > additions should be BTF-based?
> >
> > -Toke
> >
>
> We use libbpf on pre BTF kernels so in this case I think it makes
> sense to add these fields. Having inner_map_idx there should allow
> us to remove some other things we have sitting around.

We had a discussion about supporting non-BTF and non-standard BPF map
definition before and it's still on my TODO list to go and do a proof
of concept how that can look like and what libbpf changes we need to
make. Right now libbpf doesn't support those new fields anyway, so we
shouldn't add them to public API.

>
> .John