linux-kernel - Re: [PATCH 2/2] libbpf: BPF programs dynamic loading and attaching

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]

Message-ID: <CAEf4Bzajxh4xvg-aCaBhLQdNOZdhwceYUD2UsCcWku4ZBca_Hw@mail.gmail.com>
Date: Fri, 24 Jan 2025 10:31:19 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Slava Imameev <slava.imameev@...wdstrike.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 
	martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org, 
	yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org, 
	sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, mykolal@...com, 
	shuah@...nel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, martin.kelly@...wdstrike.com, 
	mark.fontana@...wdstrike.com
Subject: Re: [PATCH 2/2] libbpf: BPF programs dynamic loading and attaching

On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
<slava.imameev@...wdstrike.com> wrote:
>
> BPF programs designated as dynamically loaded can be loaded and
> attached independently after the initial bpf_object loading and
> attaching.
>
> These programs can also be reloaded and reattached multiple times,
> enabling more flexible management of a resident BPF program set.
>
> A key motivation for this feature is to reduce load times for
> utilities that include hundreds of BPF programs. When the selection
> of a resident BPF program set cannot be determined at the time of
> bpf_object loading and attaching, all BPF programs would otherwise
> need to be marked as autoload, leading to unnecessary overhead.
> This patch addresses that inefficiency.

Can you elaborate on why it's impossible to determine which BPF
programs should be loaded before BPF object load step?

In general, I'm not too excited about these complications, it's
error-prone enough with just normal autoload (true/false) logic and
various interactions between different features. Adding the third "may
be loaded much later" state just doesn't seem worth the complexit.

Also, for subsequent submissions, please make sure you have [PATCH
bpf-next] subject prefix.

>
> Signed-off-by: Slava Imameev <slava.imameev@...wdstrike.com>
> ---
>  tools/lib/bpf/libbpf.c                        | 144 +++++++++++++++--
>  tools/lib/bpf/libbpf.h                        |   5 +-
>  tools/lib/bpf/libbpf.map                      |   2 +
>  .../selftests/bpf/prog_tests/dynamicload.c    | 145 ++++++++++++++++++
>  .../selftests/bpf/prog_tests/load_type.c      |  61 ++++++++
>  .../selftests/bpf/progs/test_dynamicload.c    |  31 ++++
>  .../selftests/bpf/progs/test_load_type.c      |   8 +

and let's keep selftests in a separate patch from kernel and/or libbpf changes

>  7 files changed, 385 insertions(+), 11 deletions(-)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/dynamicload.c
>  create mode 100644 tools/testing/selftests/bpf/progs/test_dynamicload.c
>

[...]