linux-kernel - Re: [PATCH v6 6/8] kbuild: Allow adding modules into the FIT ramdisk

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: <28e18785-1336-4fbc-9f2b-69aa6bb06375@pengutronix.de>
Date: Wed, 26 Nov 2025 12:26:49 +0100
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 Simon Glass <sjg@...omium.org>
Cc: linux-arm-kernel@...ts.infradead.org,
 Masahiro Yamada <masahiroy@...nel.org>, Tom Rini <trini@...sulko.com>,
 J. Neuschäfer <j.ne@...teo.net>,
 Nicolas Schier <nicolas@...sle.eu>, Chen-Yu Tsai <wenst@...omium.org>,
 Nicolas Schier <nsc@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
 Ard Biesheuvel <ardb@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <kees@...nel.org>,
 Miguel Ojeda <ojeda@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>,
 Rong Xu <xur@...gle.com>, Tamir Duberstein <tamird@...il.com>,
 Will Deacon <will@...nel.org>, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 6/8] kbuild: Allow adding modules into the FIT ramdisk

Hi,

On 11/26/25 8:16 AM, Thomas Weißschuh wrote:
> On Tue, Nov 25, 2025 at 02:58:12PM -0700, Simon Glass wrote:
>> On Thu, 20 Nov 2025 at 00:49, Thomas Weißschuh
>> <thomas.weissschuh@...utronix.de> wrote:
>>>
>>> On Wed, Nov 19, 2025 at 11:13:27AM -0700, Simon Glass wrote:
> 
> (...)
> 
>>>>  quiet_cmd_fit = FIT     $@
>>>>        cmd_fit = $(MAKE_FIT) -o $@ --arch $(UIMAGE_ARCH) --os linux \
>>>> -             --name '$(UIMAGE_NAME)' \
>>>> +             --name '$(UIMAGE_NAME)' $(MAKE_FIT_FLAGS) \
>>>
>>> Remnant of a previous revision?
>>
>> The flags are there to allow extra options to be passed if needed.
> 
> Are they necessary for the module functionality added here?
> If not I'd put them into a dedicated commit.
> 
>>>
>>>>               $(if $(findstring 1,$(KBUILD_VERBOSE)),-v) \
>>>>               $(if $(FIT_DECOMPOSE_DTBS),--decompose-dtbs) \
>>>> +             $(if $(FIT_MODULES),--modules @$(objtree)/modules.order) \
>>>
>>> I am wondering how module dependencies work without the depmod invocation
>>> and modules.dep file.
>>
>> We have a mechanism to place a pre-build initrd with the filesystem,
>> etc. into the FIT. But for this particular feature (suggested by Ahmad
>> Fatoum) we are just providing the raw modules. Presumably another
>> initrd would be needed to provide the startup files?
> 
> modules.dep is more than optional and generic startup files but an integral
> part of a module tree. Without it, any module depending on another module's
> symbols will fail to load. Also the modules will be unsigned, potentially
> making them unloadable.

I'll use the occasion to elaborate a bit on why I thought adding modules
is a good idea.

- You have a system boot from FIT and maybe even a r/o rootfs
- You want to boot a different kernel without any userspace changes,
e.g. to bisect
- Fortunately, you have a build target that generates you a FIT with
kernel, enabled device trees and all modules (including deps and such)
- In the bootloader[1], you specify that a CPIO with a minimal init[2]
that bindmounts /lib/modules in the initramfs over the rootfs modules
before pivot_root

and that's it, you are running your new kernel with the old rootfs
unchanged. I believe this would be really handy, which is why I
suggested it.

> Ahmad's patch does produce a complete and fully
> functional module tree by means of 'make headers_install'.

I originally thought that we could generate the CPIO normally as part of
the kernel build and then we can readily depend on it in the rule that
invokes make_fit.py.

If this proves to be too cumbersome, I think it's already an improvement
if the user can manually run make modules-cpio-pkg and then make
image.fit with the initrd specified. A single target would be neater of
course, but I didn't intend for this to stall the series.

It can always follow later.

[1]: For my particular usage, I intend to extend the barebox boot
override mechanism. Currently, it's possible to do:
barebox$ boot -o bootm.initrd=/mnt/tftp/my-ramdisk.cpio /mnt/tftp/my-fit
and I want to extend it to allow appending any number of CPIOs:
barebox$ boot -o bootm.initrd=":/mnt/tftp/my-init.cpio" /mnt/tftp/my-fit

[2]: The bind mount logic for the initramfs init will probably go into
https://github.com/pengutronix/rsinit, which I can compile once per
architecture, put into my TFTP srv path and then not have to worry about it.

Cheers,
Ahmad

> 
>>>>               --compress $(FIT_COMPRESSION) -k $< @$(word 2,$^)
>>>>
>>>>  # XZ
>>>> --
>>>> 2.43.0
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |