linux-kernel - Re: vmlinux BTF as a module (was Re: [PATCH bpf-next v4 0/3] Allow mmap of /sys/kernel/btf/vmlinux)

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: <CAADnVQLAbQPWw_=F5WY_5-MY0GsSrnn5Ds_yE5BFC0=uuqnWug@mail.gmail.com>
Date: Thu, 22 May 2025 18:04:19 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Alan Maguire <alan.maguire@...cle.com>
Cc: Tony Ambardar <tony.ambardar@...il.com>, Andrii Nakryiko <andrii@...nel.org>, 
	Arnd Bergmann <arnd@...db.de>, Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Eduard <eddyz87@...il.com>, Hao Luo <haoluo@...gle.com>, 
	John Fastabend <john.fastabend@...il.com>, Jiri Olsa <jolsa@...nel.org>, 
	KP Singh <kpsingh@...nel.org>, linux-arch <linux-arch@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, Lorenz Bauer <lmb@...valent.com>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Mykola Lysenko <mykolal@...com>, 
	Stanislav Fomichev <sdf@...ichev.me>, Shuah Khan <shuah@...nel.org>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>
Subject: Re: vmlinux BTF as a module (was Re: [PATCH bpf-next v4 0/3] Allow
 mmap of /sys/kernel/btf/vmlinux)

On Wed, May 21, 2025 at 8:00 AM Alan Maguire <alan.maguire@...cle.com> wrote:
>
> > Hi Alan,
> >
> > Thanks for taking a look at this. I've been following your related effort
> > to allow /sys/kernel/btf/vmlinux as a module in support of small systems
> > with kernel-size constraints, and wondered how this series might affect
> > that work? Such support would be well-received in the embedded space when
> > it happens, so am keen to understand.
> >
> > Thanks,
> > Tony
>
> hi Tony
>
> I had something nearly working a few months back but there are a bunch
> of complications that made it a bit trickier than I'd first anticipated.
> One challenge for example is that we want /sys/kernel/btf to behave just
> as it would if vmlinux BTF was not a module. My original hope was to
> just have the vmlinux BTF module forceload early, but the request module
> approach won't work since the vmlinux_btf.ko module would have to be
> part of the initrd image. A question for you on this - I presume that's
> what you want to avoid, right? So I'm assuming that we need to extract
> the .BTF section out of the vmlinu[xz] binary and out of initrd into a
> later-loading vmlinux_btf.ko module for small-footprint systems. Is that
> correct?
>
> The reason I ask is having a later-loading vmlinux_btf.ko is a bit of a
> pain since we need to walk the set of kernel modules and load their BTF,
> relocate it and do kfunc registration. If we can simplify things via a
> shared module dependency on vmlinux_btf.ko that would be great, but I'd
> like to better understand the constraints from the small system
> perspective first. Thanks!

We cannot require other modules to depend on vmlinux_btf.ko.
Some of them might load during the boot. So adding to the dependency
will defeat the point of vmlinux_btf.ko.
The only option I see is to let modules load and ignore their BTFs
and vmlinux BTF is not present.
Later vmlinux_btf.ko can be loaded and modules loaded after that
time will succeed in loading their BTFs too.
So some modules will have their BTF and some don't.
I don't think it's an issue.

If an admin loads a module with kfuncs and vmlixnu_btf.ko is not loaded yet
the kfunc registration will fail, of course. It's an issue,
but I don't think we need to fix it right now by messing with depmod.

The bigger issue is how to split vmlinux_btf.ko itself.
The kernel has a bunch of kfuncs and they need BTF ids for protos
and for all types they reference, so vmlinux BTF cannot be empty.
minimize_btf() can probably help.
So before we proceed with vmlinux_btf.ko we need to see the data
how big the mandatory part of vmlinux BTF will be vs
the rest of BTF in vmlinux_btf.ko.