Signature problem using Fedora Kernel Copr 5.15 Lts

[enigma131]

Signature problem using Fedora Kernel Copr 5.15 Lts

[enigma131]

I've upgraded kernel.
Still same problem, dkms build the modules with signature, but at reboot is rejected by Dkms service under secure boot.
A way to solve the problem ?

[xuzhen]

Before the machine keyring was introduced with kernel 5.18, all MOK keys were loaded into the platform keyring. You can see them with sudo keyctl list %:.platform. The only problem is, the platform keyring is not used for module signature verification.

Fedora and many other distributions used an out of tree patch to allow the keys contained within the platform
keyring to be used for module verification.

Here is the relevant part of file patch-5.15-redhat.patch in https://kojipkgs.fedoraproject.org//packages/kernel/5.15.18/200.fc35/src/kernel-5.15.18-200.fc35.src.rpm

diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 8723ae70ea1f..fb2d773498c2 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -38,8 +38,15 @@ int mod_verify_sig(const void *mod, struct load_info *info)
 	modlen -= sig_len + sizeof(ms);
 	info->len = modlen;

-	return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+	ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
 				      VERIFY_USE_SECONDARY_KEYRING,
 				      VERIFYING_MODULE_SIGNATURE,
 				      NULL, NULL);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+		ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+				VERIFY_USE_PLATFORM_KEYRING,
+				VERIFYING_MODULE_SIGNATURE,
+				NULL, NULL);
+	}
+	return ret;
 }

You need to ask the maintainer of https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/packages/ to add this patch.

[enigma131]

Thanks fo answer.
I had let a post at https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/ at bottom of page since feb the 10th , no response. Is he reading there ?
Kernel 5.15 is under 5.18, it is working fine on partitions Red hat 8 (kernel 4.18) , Debian 11 (kernel 5.10), Mint 20.3 (kernel 5.4) on same computer. Mok from Dkms is registered in Nvram and is identical for signing on all 4 partitions, only Fedora's signatures are not valid, why ?
Is something missing in the Copr kernel and if yes how to debug ?
Other kernel Copr's modules are signed by "Red Hat Test Certificate".

New readings, at botom : https://bugzilla.redhat.com/show_bug.cgi?id=2139560

[xuzhen]

Kernel 5.15 is under 5.18, it is working fine on partitions Red hat 8 (kernel 4.18) , Debian 11 (kernel 5.10), Mint 20.3 (kernel 5.4) on same computer. Mok from Dkms is registered in Nvram and is identical for signing on all 4 partitions, only Fedora's signatures are not valid, why ?

As I said before, they all applied that patch except the copr kernels. You can find that patch in their source codes.

RHEL 8/CentOS 8: kernel/module_signing.c is already patched in https://vault.centos.org/8.5.2111/BaseOS/Source/SPackages/kernel-4.18.0-348.7.1.el8_5.src.rpm

Debian 11: debian/patches/features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch in https://ftp.debian.org/debian/pool/main/l/linux/linux_5.10.162-1.debian.tar.xz

Mint 20.3/Ubuntu 20.04.5: line 990191-990218 of http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_5.4.0-144.161.diff.gz

And the kernels provided by https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/packages/, does not have that patch in their source code repo: https://copr-dist-git.fedorainfracloud.org/cgit/kwizart/kernel-longterm-5.15/kernel-longterm.git/tree/?h=f37

[enigma131]

Ok, I've done a comment on https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/
and https://bugzilla.redhat.com/show_bug.cgi?id=2139560
Wait and see

[evelikov]

In light of some signature related digging yesterday, I'm wondering if we shouldn't disable signing if the kernel_config is missing/CONFIG_MODULE_SIG_HASH isn't found. @xuzhen what do you think?

[enigma131]

I've posted there too : https://bugzilla.redhat.com/show_bug.cgi?id=2070866

[kwizart]

Thanks for rising the issue to me for the 5.15 LT kernel.
Any idea why this patch isn't merged upstream ?

[enigma131]

I don't know. What we know is that all main distributions have this patch , including Ubuntu, Debian, Redhat ...
Did your sources comes from Kernel.org or Fedora ?

[kwizart]

My sources only comes from kernel.org upstream. There this specific issue is unfixed. (I've checked up to 6.1 LT kernel).

[enigma131]

On kernel.org I agree. I don't know if someone can push the patch there. I've seen a new build in progress, did it include the patch ?

[xuzhen]

Any idea why this patch isn't merged upstream ?

That patch was rejected by upstream several times.
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/

[xuzhen]

@evelikov

I'm wondering if we shouldn't disable signing if the kernel_config is missing/CONFIG_MODULE_SIG_HASH isn't found.

Currently we don't disable signing in those cases. DKMS will use sha512 instead.

dkms/dkms.in

Lines 984 to 990 in 2bb211d

	if [[ -f "${kernel_config}" ]]; then
	sign_hash="$(grep "^CONFIG_MODULE_SIG_HASH=" "${kernel_config}" | sed 's/CONFIG_MODULE_SIG_HASH=//;s/"//g')"
	# The kernel may be built without module signing facility. CONFIG_MODULE_SIG_HASH is unset in kconfig
	sign_hash="${sign_hash:-sha512}"
	else
	sign_hash="sha512"
	fi

[enigma131]

Hi, last version from yesterday is working, thanks to you.

[Arcitec]

Kwizart knows about it and will add the dkms patch in the next "kernel-longterm" update:

https://bugzilla.redhat.com/show_bug.cgi?id=2070866#c5

He posted that message on March 3rd 2023.