On Mon, Dec 9, 2024 at 5:31 PM Mihai Limbășan <mihai@xxxxxxxxxxx> wrote:
>
> 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.
Sorry, I missed that.
Before you, another guy asked me the same question off-list.
Multiple people contacted me off-list for the same question.
Presumably, asking this in the ML is better because
other people may find the answer and avoid duplicated questions.
>
> 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.
I do not think removal of the .config is a problem because
another copy, include/config/auto.conf exists in the package.
DKMS can parse "${kernel_source_dir}/include/config/auto.conf
for CONFIG options.
Masahiro
> 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
>
>
--
Best Regards
Masahiro Yamada
