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, 01 Oct 2019 15:00:21 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        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

Andrii Nakryiko wrote:
> 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.

I'm carrying around a patch for perf_event_open_probe() to get it working
without BTF I'll send that out today/tomorrow. It seems enough to get
all the basic prog load, maps reused/pinned, etc at least for my use
case.

> 
> >
> > .John