Message-Id: <20211116164208.164245-1-mauricio@kinvolk.io>
Date:   Tue, 16 Nov 2021 11:42:04 -0500
From:   Mauricio Vásquez <mauricio@...volk.io>
To:     netdev@...r.kernel.org, bpf@...r.kernel.org
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Rafael David Tinoco <rafaeldtinoco@...il.com>,
        Lorenzo Fontana <lorenzo.fontana@...stic.co>,
        Leonardo Di Donato <leonardo.didonato@...stic.co>
Subject: [PATCH bpf-next v2 0/4] libbpf: Provide APIs for BTFGen

CO-RE requires to have BTF information describing the types of the
kernel in order to perform the relocations. This is usually provided by
the kernel itself when it's configured with CONFIG_DEBUG_INFO_BTF.
However, this configuration is not enabled in all the distributions and
it's not available on older kernels.

It's possible to use CO-RE in kernels without CONFIG_DEBUG_INFO_BTF
support by providing the BTF information from an external source.
BTFHub[0] contains BTF files to each released kernel not supporting BTF,
for the most popular distributions.

Providing this BTF file for a given kernel has some challenges: 1. Each
BTF file is a few MBs big, then it's not possible to ship the eBPF
program with all the BTF files needed to run in different kernels. (The
BTF files will be in the order of GBs if you want to support a high
number of kernels) 2. Downloading the BTF file for the current kernel at
runtime delays the start of the program and it's not always possible to
reach an external host to download such a file.

Providing the BTF file with the information about all the data types of
the kernel for running an eBPF program is an overkill in many of the
cases. Usually the eBPF programs access only some kernel fields.

This series extends libbpf to provide an API that can be used for this
purpose. The major proposed change is to introduce a new
bpf_object__prepare() method that performs all the preparation steps
without creating the maps nor loading the programs.

This idea was discussed during the "Towards truly portable eBPF"[1]
presentation at Linux Plumbers 2021.

We prepared a BTFGen repository[2] with an example of how this API can
be used. Our plan is to include this support in bpftool once it's merged
in libbpf.

There is also a good example[3] on how to use BTFGen and BTFHub together
to generate multiple BTF files, to each existing/supported kernel,
tailored to one application. For example: a complex bpf object might
support nearly 400 kernels by having BTF files summing only 1.5 MB.

[0]: https://github.com/aquasecurity/btfhub/
[1]: https://www.youtube.com/watch?v=igJLKyP1lFk&t=2418s
[2]: https://github.com/kinvolk/btfgen
[3]: https://github.com/aquasecurity/btfhub/tree/main/tools

Changelog:

v1 > v2:
- introduce bpf_object__prepare() and ‘record_core_relos’ to expose
  CO-RE relocations instead of bpf_object__reloc_info_gen()
- rename btf__save_to_file() to btf__raw_data()

v1: https://lore.kernel.org/bpf/20211027203727.208847-1-mauricio@kinvolk.io/

Mauricio Vásquez (4):
  libbpf: Implement btf__save_raw()
  libbpf: Introduce 'btf_custom' to 'bpf_obj_open_opts'
  libbpf: Introduce 'bpf_object__prepare()'
  libbpf: Expose CO-RE relocation results

 tools/lib/bpf/btf.c       |  30 ++++++
 tools/lib/bpf/btf.h       |   2 +
 tools/lib/bpf/libbpf.c    | 213 +++++++++++++++++++++++++++++++-------
 tools/lib/bpf/libbpf.h    |  58 ++++++++++-
 tools/lib/bpf/libbpf.map  |   4 +
 tools/lib/bpf/relo_core.c |  28 ++++-
 tools/lib/bpf/relo_core.h |  21 +---
 7 files changed, 294 insertions(+), 62 deletions(-)

-- 
2.25.1

Powered by blists - more mailing lists