Hi!
Would like to report a DKMS build system impacting bug with kernel 6.12+
introduced in commit aaed5c7739be81ebdd6008aedc8befd98c88e67a . Hope I'm
addressing this following proper protocol by mailing linux-kbuild, tried
mailing the maintainer directly on 2024-11-20 but received no feedback;
my apologies otherwise, it's my first kernel bug report.
Specifically, the commit changes scripts/package/install-extmod-build to
remove the shipped copy of the kernel configuration as .config in the
generated package. Unfortunately, this breaks DKMS when secure boot is
being used and any locally compiled the modules need to be signed. DKMS
needs it to extract various characteristics of the built kernel, among
which CONFIG_MODULE_SIG_HASH so that it can sign the .ko files it
creates. It's likely that it also uses various other symbols from the
kernel config, e.g. clang-related stuff, but I didn't test that.
The removal of the other formerly shipped files doesn't appear to cause
any problems, at least not in this scenario.
In detail:
DKMS sets its path to the kernel config into the kernel_config var in
this function:
https://github.com/dell/dkms/blob/93bf2bd79704c0a8a39b240a52b001610cdc419b/dkms.in#L274
DKMS then uses it to extract CONFIG_MODULE_SIG_HASH in this function:
https://github.com/dell/dkms/blob/93bf2bd79704c0a8a39b240a52b001610cdc419b/dkms.in#L1021
If kernel_config isn't set, the build process issues "Kernel config
${kernel_config} not found, modules won't be signed" and skips signing
the built .ko files, subsequently resulting in a runtime failure to load
the corresponding module with "Loading of unsigned module is rejected"
when secure boot is being used.
While it's possible to supply the path to the kernel config manually
when invoking DKMS, it would need manual intervention after every kernel
header package installation. This would be rather clumsy and
inconvenient compared to the current set-and-forget approach where a
kernel headers package install hook auto-builds and installs modules.
Unfortunately there's no viable workaround via a config snippet or any
sort of build hook, DKMS would need to be patched to somehow figure out
the relationships between the installed packages and the various kernel
config file placement conventions across distros.
Is there any chance for .config to be shipped again when generating the
headers package? This would be a simple two-line change, restoring the
shipped copy of the kernel config. I.e. something like the below. Have
tested that patch and can confirm it restores proper modsign functionality.
Thank you very much!
Mihai Limbasan
diff -Naur linux.orig/scripts/package/install-extmod-build
linux/scripts/package/install-extmod-build
--- linux.orig/scripts/package/install-extmod-build 2024-12-09
10:28:03.000000000 +0200
+++ linux/scripts/package/install-extmod-build 2024-12-09
10:30:28.871498366 +0200
@@ -76,4 +76,6 @@
rm -f "${destdir}/Kbuild" "${destdir}/scripts/Kbuild"
fi
+# copy .config manually to be where it's expected to be
+cp "${KCONFIG_CONFIG}" "${destdir}/.config"
find "${destdir}" \( -name '.*.cmd' -o -name '*.o' \) -delete
