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: <a7c0306e-4799-4c5c-a72c-367298e3fe3e@pengutronix.de>
Date: Thu, 11 Dec 2025 14:49:42 +0100
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Simon Glass <sjg@...omium.org>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: linux-arm-kernel@...ts.infradead.org,
 Masahiro Yamada <masahiroy@...nel.org>, Tom Rini <trini@...sulko.com>,
 J. Neuschäfer <j.ne@...teo.net>,
 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 Simon,

On 12/11/25 2:31 PM, Simon Glass wrote:
> Hi Thomas,
> 
> On Tue, 2 Dec 2025 at 03:31, Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
>>
>> 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.
>>
>> (...)
> 
> I'm going to send a v7 and perhaps Ahmad can help to refine this.
> Unfortunately the modules generation has turned into a significant
> detour. We can either drop it, or continue to try to resolve this.

I'd suggest to drop it and tackle that separately.

Sorry for the inconvenience,
Ahmad

> 
> Regards,
> SImon
> 

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