linux-kernel - Re: [PATCH bpf-next v1 0/4] resolve_btfids: Support for BTF modifications

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] [day] [month] [year] [list]

Message-ID: <5bd0b578-e9ff-4958-b01c-fa3e9336eecb@oracle.com>
Date: Wed, 26 Nov 2025 12:36:50 +0000
From: Alan Maguire <alan.maguire@...cle.com>
To: Ihor Solodrai <ihor.solodrai@...ux.dev>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau
 <martin.lau@...ux.dev>,
        Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
        Yonghong Song <yonghong.song@...ux.dev>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nicolas Schier <nicolas.schier@...ux.dev>,
        Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
        Bill Wendling <morbo@...gle.com>,
        Justin Stitt <justinstitt@...gle.com>
Cc: bpf@...r.kernel.org, dwarves@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org, Donglin Peng <dolinux.peng@...il.com>
Subject: Re: [PATCH bpf-next v1 0/4] resolve_btfids: Support for BTF
 modifications

On 26/11/2025 01:26, Ihor Solodrai wrote:
> This series changes resolve_btfids and kernel build scripts to enable
> BTF transformations in resolve_btfids. Main motivation for enhancing
> resolve_btfids is to reduce dependency of the kernel build on pahole
> capabilities [1] and enable BTF features and optimizations [2][3]
> particular to the kernel.
> 
> Patches #1-#3 in the series are non-functional refactoring in
> resolve_btfids. The last patch (#4) makes significant changes in
> resolve_btfids and introduces scripts/gen-btf.sh. Implementation
> changes are described in detail in the patch description.
> 
> One RFC item in this patchset is the --distilled_base [4] handling.
> Before this patchset .BTF.base was generated and added to target
> binary by pahole, based on these conditions [5]:
>   * pahole version >=1.28
>   * the kernel module is out-of-tree (KBUILD_EXTMOD)
> 
> Since BTF finalization is now done by resolve_btfids, it requires
> btf__distill_base() to happen there. However, in my opinion, it is
> unnecessary to add and pass through a --distilled_base flag for
> resolve_btfids.
>
hi Ihor,

Can you say more about what constitutes BTF finalization and why BTF
distillation prior to finalization (i.e. in pahole) isn't workable? Is
it the concern that we eliminate types due to filtering, or is it a
problem with sorting/tracking type ids? Are there operations we
do/anticipate that make prior distillation infeasbile? Thanks!

> Logically, any split BTF referring to kernel BTF is not very useful
> without the .BTF.base, which is why the feature was developed in the
> first place. Therefore it makes sense to always emit .BTF.base for all
> modules, unconditionally. This is implemented in the series.
> 
> However it might be argued that .BTF.base is redundant for in-tree
> modules: it takes space the module ELF and triggers unnecessary
> btf__relocate() call on load [6]. It can be avoided by special-casing
> in-tree module handling in resolve_btfids either with a flag or by
> checking env variables. The trade-off is slight performance impact vs
> code complexity.
> 

I would say avoid distillation for in-tree modules if possible, as it
imposes runtime costs in relocation/type renumbering on module load. For
large modules (amdgpu take a bow) that could be non-trivial time-wise.
IMO the build-time costs/complexities are worth paying to avoid a
runtime tax on module load.

> [1] https://lore.kernel.org/dwarves/ba1650aa-fafd-49a8-bea4-bdddee7c38c9@linux.dev/
> [2] https://lore.kernel.org/bpf/20251029190113.3323406-1-ihor.solodrai@linux.dev/
> [3] https://lore.kernel.org/bpf/20251119031531.1817099-1-dolinux.peng@gmail.com/
> [4] https://docs.kernel.org/bpf/btf.html#btf-base-section
> [5] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/scripts/Makefile.btf#n29
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/tree/kernel/bpf/btf.c#n6358
> 
> Ihor Solodrai (4):
>   resolve_btfids: rename object btf field to btf_path
>   resolve_btfids: factor out load_btf()
>   resolve_btfids: introduce enum btf_id_kind
>   resolve_btfids: change in-place update with raw binary output
> 
>  MAINTAINERS                     |   1 +
>  scripts/Makefile.modfinal       |   5 +-
>  scripts/gen-btf.sh              | 166 ++++++++++++++++++++++
>  scripts/link-vmlinux.sh         |  42 +-----
>  tools/bpf/resolve_btfids/main.c | 234 +++++++++++++++++++++++---------
>  5 files changed, 348 insertions(+), 100 deletions(-)
>  create mode 100755 scripts/gen-btf.sh
>