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 11:45:18 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Mauricio Vásquez <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 Wed, Oct 27, 2021 at 1:37 PM Mauricio Vásquez <mauricio@...volk.io> wrote:
>
> This commit implements a new set of "bpf_reloc_info__" functions for
> generating a BTF file with the types a given set of eBPF objects need
> for their CO-RE relocations. This code reuses all the existing CO-RE
> logic (candidate lookup, matching, etc). The workflow is the same as
> when an eBPF program is being loaded, but instead of patching the eBPF
> instruction, we save the type involved in the relocation.
>
> A new struct btf_reloc_info is defined to save the BTF types needed by a
> set of eBPF objects. It is created with the bpf_reloc_info__new()
> function and populated with bpf_object__reloc_info_gen() for each eBPF
> object, finally the BTF file is generated with
> bpf_reloc_info__get_btf(). Please take at a look at BTFGen[0] to get a
> complete example of how this API can be used.
>
> bpf_object__reloc_info_gen() ends up calling btf_reloc_info_gen_field()
> that uses the access spec to add all the types needed by a given
> relocation. The root type is added and, if it is a complex type, like a
> struct or union, the members involved in the relocation are added as
> well. References are resolved and all referenced types are added. This
> function can be called multiple times to add the types needed for
> different objects into the same struct btf_reloc_info, this allows the
> user to create a BTF file that contains the BTF information for multiple
> eBPF objects.
>
> The bpf_reloc_info__get_btf() generates the BTF file from a given struct
> btf_reloc_info. This function first creates a new BTF object and copies
> all the types saved in the struct btf_reloc_info there. For structures
> and unions, only the members involved in a relocation are copied. While
> adding the types to the new BTF object, a map is filled with the type
> IDs on the old and new BTF structures.  This map is then used later on
> to fix all the IDs in the new BTF object.
>
> Right now only support for field based CO-RE relocations is supported.
>
> [0]: https://github.com/kinvolk/btfgen
>
> Signed-off-by: Mauricio Vásquez <mauricio@...volk.io>
> Signed-off-by: Rafael David Tinoco <rafael.tinoco@...asec.com>
> Signed-off-by: Lorenzo Fontana <lorenzo.fontana@...stic.co>
> ---

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. The only extra bit is ignoring ___<suffix>,
that's it. bpftool (or whatever other tool that's going to be used for
this) can do that on its own by using existing libbpf APIs to work
with BTF. Good bit of optimization would be to only emit forward
declarations for structs that are never used, but are referenced by
structs that are used.

Either way, this is not libbpf's problem to solve. It's a tooling problem.


>  tools/lib/bpf/Makefile    |   2 +-
>  tools/lib/bpf/libbpf.c    |  28 ++-
>  tools/lib/bpf/libbpf.h    |   4 +
>  tools/lib/bpf/libbpf.map  |   5 +
>  tools/lib/bpf/relo_core.c | 514 +++++++++++++++++++++++++++++++++++++-
>  tools/lib/bpf/relo_core.h |  11 +-
>  6 files changed, 554 insertions(+), 10 deletions(-)
>

[...]