modprobe: when is using `--force-vermagic` safe?

Message

leyvi · Post by **leyvi** » Mon Nov 24, 2025 9:02 pm

I have built the same kernel version twice. The first time, with an out-of-tree module. Trying to load it while running the second kernel yields a version-magic error. There exists an argument for modprobe called --force-vermagic, which does exactly what you'd think: it forces the kernel to ignore the version magic. Is it safe to use this argument? If not always, then at least tell me this: how about if the module in-question already has all its dependencies loaded?

Post by **sam_** » Mon Nov 24, 2025 10:43 pm

It is only safe if you have compared the magic for the two binaries, understand why it differs, and are confident that the specific differences in an instance are fine to mix at runtime.

leyvi · Post by **leyvi** » Mon Nov 24, 2025 11:36 pm

sam_ wrote:It is only safe if you have compared the magic for the two binaries, understand why it differs, and are confident that the specific differences in an instance are fine to mix at runtime.

Well, the module in-question hasn't been updated in over a month. It works with this kernel version, and I used modprobe to check its dependencies and they are all either loaded by default or built-in. I dotn know how the version magic works; I always assumed it was magic and never really questioned it.

Post by **NeddySeagoon** » Tue Nov 25, 2025 9:37 am

leyvi,

Code: Select all

modinfo <module>

will show you the version magic.
It should match the kernel version magic.
Look at another module, that does load.

leyvi · Post by **leyvi** » Tue Nov 25, 2025 10:21 am

NeddySeagoon wrote:leyvi,
Code: Select all
modinfo <module>
will show you the version magic.
It should match the kernel version magic.
Look at another module, that does load.

It doesn't match. How important is that? Check it out:

Code: Select all

filename:       /lib/modules/6.17.8-gentoo/kernel/drivers/gpu/drm/drm.ko.xz
author:         Ajay Kumar <ajaykumar.rs@samsung.com>
description:    DRM bridge infrastructure
license:        GPL and additional rights
author:         Gareth Hughes, Leif Delgass, José Fonseca, Jon Smirl
description:    DRM shared core routines
license:        GPL and additional rights
import_ns:      DMA_BUF
author:         Thierry Reding <treding@nvidia.com>
description:    DRM panel infrastructure
license:        GPL and additional rights
author:         Jocelyn Falempe
description:    DRM panic handler
license:        GPL
name:           drm
intree:         Y
depends:        backlight
vermagic:       6.17.8-gentoo SMP preempt mod_unload modversions RANDSTRUCT_97a7************************************************************
retpoline:      Y
sig_id:         PKCS#7
signer:
sig_key:
sig_hashalgo:   unknown
signature:
parm:           panic_screen:Choose what will be displayed by drm_panic, 'user' or 'kmsg' [default=kmsg] (string)
parm:           timestamp_precision_usec:Max. error on timestamps [usecs] (int)
parm:           vblankoffdelay:Delay until vblank irq auto-disable [msecs] (0: never disable, <0: disable immediately) (int)
parm:           debug:Enable debug output, where each bit enables a debug category.
		Bit 0 (0x01)  will enable CORE messages (drm core code)
		Bit 1 (0x02)  will enable DRIVER messages (drm controller code)
		Bit 2 (0x04)  will enable KMS messages (modesetting code)
		Bit 3 (0x08)  will enable PRIME messages (prime code)
		Bit 4 (0x10)  will enable ATOMIC messages (atomic code)
		Bit 5 (0x20)  will enable VBL messages (vblank code)
		Bit 7 (0x80)  will enable LEASE messages (leasing code)
		Bit 8 (0x100) will enable DP messages (displayport code) (ulong)
parm:           edid_fixup:Minimum number of valid EDID header bytes (0-8, default 6) (int)

Code: Select all

filename:       /lib/modules/6.17.8-gentoo/extra/framework_laptop.ko.xz
description:    Framework Laptop Platform Driver
author:         Dustin L. Howett <dustin@howett.net>
license:        GPL
alias:          platform:framework_laptop
softdep:        pre: cros_ec_lpcs
name:           framework_laptop
depends:        cros-ec-proto,led-class
alias:          dmi*:svn*Framework*:pn*Laptop*:
alias:          acpi*:FRMW0001:*
alias:          acpi*:FRMW0004:*
vermagic:       6.17.8-gentoo SMP preempt mod_unload modversions RANDSTRUCT_2a86************************************************************
retpoline:      Y
sig_id:         PKCS#7
signer:
sig_key:
sig_hashalgo:   unknown
signature:

Post by Hu » Tue Nov 25, 2025 1:53 pm

leyvi wrote:It doesn't match. How important is that?

As sam_ said, it depends on what is different.

leyvi wrote:Check it out:

Code: Select all

filename:       /lib/modules/6.17.8-gentoo/kernel/drivers/gpu/drm/drm.ko.xz
vermagic:       6.17.8-gentoo SMP preempt mod_unload modversions RANDSTRUCT_97a7************************************************************

Code: Select all

filename:       /lib/modules/6.17.8-gentoo/extra/framework_laptop.ko.xz
vermagic:       6.17.8-gentoo SMP preempt mod_unload modversions RANDSTRUCT_2a86************************************************************

In this case, I would say it is extremely likely this will not work, since it looks like you built the two modules with different randstruct seeds, in which case they will not agree on the layout of randomized kernel structures. I expect at least memory corruption, if not outright crashes, if you force the load anyway.

I should also note that in the time you spent asking us this and waiting for responses, you could have built a self-consistent setup and rebooted into it. Why are you trying so hard to avoid that?

leyvi · Post by **leyvi** » Tue Nov 25, 2025 2:58 pm

Hu wrote:I should also note that in the time you spent asking us this and waiting for responses, you could have built a self-consistent setup and rebooted into it. Why are you trying so hard to avoid that?

Because I build my kernel in tmpfs, so as soon as I reboot, I have to rebuild the entire kernel again. This takes a long time. (Generally speaking though, building the kernel this way has more benefits than detriments. The first build goes way faster if you're building in tmpfs, and most of the time I only have to build once.)
As you may know, building an out-of-tree module requires that the built sources be present. This means that after (re)booting, if I want to rebuild an out-of-tree module, I've gotta rebuild the whole kernel first.

Post by **NeddySeagoon** » Tue Nov 25, 2025 6:06 pm

leyvi,

You can keep the kernel sources wherever you want and still put the build products in tmpfs.
You need to keep the random seed somehow and probably the config.
That may be enough for the out of tree module to build against.

leyvi · Post by **leyvi** » Tue Nov 25, 2025 7:45 pm

NeddySeagoon wrote:You need to keep the random seed somehow and probably the config.
That may be enough for the out of tree module to build against.

Does anyone know where the seed goes?

leyvi · Post by **leyvi** » Tue Nov 25, 2025 8:26 pm

I think I might have found it in scripts/Makefile.randstruct. It should get stored at $KBUILD_OUTPUT/scripts/basic/randstruct.seed but maybe I misunderstood...

Post by **NeddySeagoon** » Tue Nov 25, 2025 9:00 pm

leyvi,

Time to test your theory with a kernel build then.

Compare $KBUILD_OUTPUT/scripts/basic/randstruct.seed with the seed in the Version Magic for your new kernel.

leyvi · Post by **leyvi** » Wed Nov 26, 2025 3:20 pm

NeddySeagoon wrote:leyvi,

Time to test your theory with a kernel build then.

Compare $KBUILD_OUTPUT/scripts/basic/randstruct.seed with the seed in the Version Magic for your new kernel.

I have done the following:

Rebuilt the kernel.
Copied randstruct.seed into my root filesystem, took note of resulting version magic.
Rebooted.
Copy randstruct.seed from last build to the appropriate path.
Rebuilt kernel.
Compare current version magic and seed with old version magic and seed.

...after all that, it would appear that the kernel makes a new seed every time you run the default make target (I assume)...

Post by Hu » Wed Nov 26, 2025 3:37 pm

If the kernel changes the seed on every build, then repeating step 5 several times should show the seed change after each repetition, even without rebooting and cleaning the object directory. Does that happen? From my cursory read of the kernel build system, it should not.

The kernel documentation also seems to say that what you did should work. See Documentation/kbuild/reproducible-builds.rst, which is effectively what you are trying to do. You want to reproduce a build for which you did not save the intermediate results.

leyvi · Post by **leyvi** » Wed Nov 26, 2025 5:09 pm

Hu wrote:If the kernel changes the seed on every build, then repeating step 5 several times should show the seed change after each repetition, even without rebooting and cleaning the object directory. Does that happen? From my cursory read of the kernel build system, it should not.

The kernel documentation also seems to say that what you did should work. See Documentation/kbuild/reproducible-builds.rst, which is effectively what you are trying to do. You want to reproduce a build for which you did not save the intermediate results.

You're right, I forgot I had written my build script wrapper to run make clean before building... yeah, obviously that regenerates the seed, but if you just build again, it might work fine. I've edited the script, and am testing again.

leyvi · Post by **leyvi** » Wed Nov 26, 2025 5:36 pm

No... make clean keeps randstruct.seed... it's getting re-generated for sure.

Post by **sam_** » Wed Nov 26, 2025 6:56 pm

If you claim it is being regenerated, please share the full script that shows this.

Also, I suggest reading the document Hu referenced.