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

Message-ID: <20251202112039-b03af7ec-ae06-41ab-914b-703940cc98a2@linutronix.de>
Date: Tue, 2 Dec 2025 11:31:51 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Ahmad Fatoum <a.fatoum@...gutronix.de>
Cc: Simon Glass <sjg@...omium.org>, 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

On Wed, Nov 26, 2025 at 12:26:49PM +0100, Ahmad Fatoum wrote:
> 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.

The idea sounds good.

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

That works, but it is not what the patch under discussion does, or did.

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

The single target idea would require 'modules-cpio-pkg' to not be a PHONY
target anymore but to properly track dependencies. Otherwise the CPIO and FIT
image will be rebuilt even if no sources change. Proper dependencies are always
better than PHONY targets, but it will be a bit of additional work.

> It can always follow later.

Yep. But for the patch as it is proposed I am still wondering how it will work
without modules.dep and friends.

(...)