netdev - Re: [PATCH bpf-next 2/2] libbpf: Implement API for generating BTF for ebpf objects

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:   Thu, 28 Oct 2021 15:48:05 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Mauricio Vásquez Bernal <mauricio@...volk.io>
Cc:     Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Rafael David Tinoco <rafaeldtinoco@...il.com>,
        Rafael David Tinoco <rafael.tinoco@...asec.com>,
        Lorenzo Fontana <lorenzo.fontana@...stic.co>
Subject: Re: [PATCH bpf-next 2/2] libbpf: Implement API for generating BTF for
 ebpf objects

On Thu, Oct 28, 2021 at 3:42 PM Mauricio Vásquez Bernal
<mauricio@...volk.io> wrote:
>
> > I don't think it's necessary for libbpf to expose all these new APIs.
> > The format of CO-RE relocations and .BTF.ext is open and fixed. You
> > don't really need to simulate full CO-RE relocation logic to figure
> > out which types are necessary. Just go over all .BTF.ext records for
> > CO-RE relocations, parse spec (simple format as well) and see which
> > fields are accessed.
>
> How do you suggest to match the types for the target BTF without
> simulating the CO-RE relocation? Are you suggesting to match them only
> by name? We want to generate the minimal BTF that is needed by a given
> object. Consider that we could generate these files for thousands of
> kernels, size is very important for us. For this reason we chose to
> simulate the relocation generating only the types (and members) that
> are really needed.
>

How many unnecessary structs are matching if you match by name only?

Keep in mind, if your kernel BTF has task_struct and task_struct___2,
then CO-RE relocation will keep matching both; and that's not an error
for libbpf if all the field offsets will be consistent.

In short, I think simple name matching for trimming down BTF is
completely adequate. CO-RE relocation has to be more strict about
matching, but the subset of types that are used will be the same or
almost the same.


> > Either way, this is not libbpf's problem to solve. It's a tooling problem.
>
> I agree. When I started working on this I tried to implement it
> without using the libbpf relocation logic, but very soon I realized I
> was  reimplementing the same logic. Another possibility we have
> considered is to expose this relocation logic in the libbpf API,
> however I fear it's too complicated and invasive too...