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: <ace72324-6395-4e9b-8406-7d99d57018dd@oracle.com>
Date: Wed, 21 May 2025 16:00:19 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: tony.ambardar@...il.com
Cc: alan.maguire@...cle.com, andrii@...nel.org, arnd@...db.de, ast@...nel.org,
        bpf@...r.kernel.org, daniel@...earbox.net, eddyz87@...il.com,
        haoluo@...gle.com, john.fastabend@...il.com, jolsa@...nel.org,
        kpsingh@...nel.org, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        lmb@...valent.com, martin.lau@...ux.dev, mykolal@...com,
        sdf@...ichev.me, shuah@...nel.org, song@...nel.org,
        yonghong.song@...ux.dev
Subject: vmlinux BTF as a module (was Re: [PATCH bpf-next v4 0/3] Allow mmap
 of /sys/kernel/btf/vmlinux)

> 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!

Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ