[bpf-next,0/4] libbpf: add bpf_program__insns() accessor

Message

Andrii Nakryiko Oct. 25, 2021, 10:45 p.m. UTC

Add libbpf APIs to access BPF program instructions. Both before and after
libbpf processing (before and after bpf_object__load()). This allows to
inspect what's going on with BPF program assembly instructions as libbpf
performs its processing magic.

But in more practical terms, this allows to do a no-brainer BPF program
cloning, which is something you need when working with fentry/fexit BPF
programs to be able to attach the same BPF program code to multiple kernel
functions. Currently, kernel needs multiple copies of BPF programs, each
loaded with its own target BTF ID. retsnoop is one such example that
previously had to rely on bpf_program__set_prep() API to hijack program
instructions ([0] for before and after).

Speaking of bpf_program__set_prep() API and the whole concept of
multiple-instance BPF programs in libbpf, all that is scheduled for
deprecation in v0.7. It doesn't work well, it's cumbersome, and it will become
more broken as libbpf adds more functionality. So deprecate and remove it in
libbpf 1.0. It doesn't seem to be used by anyone anyways (except for that
retsnoop hack, which is now much cleaner with new APIs as can be seen in [0]).

  [0] https://github.com/anakryiko/retsnoop/pull/1

Andrii Nakryiko (4):
  libbpf: fix off-by-one bug in bpf_core_apply_relo()
  libbpf: add ability to fetch bpf_program's underlying instructions
  libbpf: deprecate multi-instance bpf_program APIs
  libbpf: deprecate ambiguously-named bpf_program__size() API

 tools/lib/bpf/libbpf.c   | 36 ++++++++++++++++++++++-----------
 tools/lib/bpf/libbpf.h   | 43 +++++++++++++++++++++++++++++++++++++---
 tools/lib/bpf/libbpf.map |  2 ++
 3 files changed, 66 insertions(+), 15 deletions(-)

Comments

Alexei Starovoitov Oct. 26, 2021, 1:38 a.m. UTC | #1

On Mon, Oct 25, 2021 at 03:45:27PM -0700, Andrii Nakryiko wrote:
> Add libbpf APIs to access BPF program instructions. Both before and after
> libbpf processing (before and after bpf_object__load()). This allows to
> inspect what's going on with BPF program assembly instructions as libbpf
> performs its processing magic.
> 
> But in more practical terms, this allows to do a no-brainer BPF program
> cloning, which is something you need when working with fentry/fexit BPF
> programs to be able to attach the same BPF program code to multiple kernel
> functions. Currently, kernel needs multiple copies of BPF programs, each
> loaded with its own target BTF ID. retsnoop is one such example that
> previously had to rely on bpf_program__set_prep() API to hijack program
> instructions ([0] for before and after).
> 
> Speaking of bpf_program__set_prep() API and the whole concept of
> multiple-instance BPF programs in libbpf, all that is scheduled for
> deprecation in v0.7. It doesn't work well, it's cumbersome, and it will become
> more broken as libbpf adds more functionality. So deprecate and remove it in
> libbpf 1.0. It doesn't seem to be used by anyone anyways (except for that
> retsnoop hack, which is now much cleaner with new APIs as can be seen in [0]).
> 
>   [0] https://github.com/anakryiko/retsnoop/pull/1

Applied, Thanks