PKCS#7 signature not signed with a trusted key
Hi, some kernels that do boot on my old UEFI computer with legacy boot enabled, don't boot on my new UEFI computer were the Intel processor graphics doesn't allow to enable legacy boot, but at least _secure boot_ is _disabled_. What can I do to get rid of the error? The kernel parameter "module.sig_enforce=1" is _never_ used. A kernel that fails to boot with "PKCS#7 signature not signed with a trusted key": [rocketmouse@archlinux ~]$ ls -hl /lib/modules/4.19.271-rt120-0.300-cornflower/updates/dkms/ .rw-r--r-- root root 65 KB Sun Apr 2 15:42:39 2023 r8125.ko.xz .rw-r--r-- root root 142 KB Wed Mar 1 20:17:25 2023 vboxdrv.ko.xz .rw-r--r-- root root 4.6 KB Wed Mar 1 20:17:25 2023 vboxnetadp.ko.xz .rw-r--r-- root root 14 KB Wed Mar 1 20:17:25 2023 vboxnetflt.ko.xz [rocketmouse@archlinux ~]$ grep MODULE_SIG /lib/modules/4.19.271-rt120-0.300-cornflower/build/.config CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" A kernel that doesn't fail: [rocketmouse@archlinux ~]$ ls -hl /lib/modules/6.2.10-arch1-1/updates/dkms/ .rw-r--r-- root root 116 KB Sun Apr 9 13:32:10 2023 r8125.ko.zst .rw-r--r-- root root 221 KB Sun Apr 9 13:31:59 2023 vboxdrv.ko.zst .rw-r--r-- root root 27 KB Sun Apr 9 13:31:59 2023 vboxnetadp.ko.zst .rw-r--r-- root root 47 KB Sun Apr 9 13:31:59 2023 vboxnetflt.ko.zst [rocketmouse@archlinux ~]$ grep MODULE_SIG /lib/modules/6.2.10-arch1-1/build/.config CONFIG_MODULE_SIG_FORMAT=y CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" # CONFIG_MODULE_SIG_KEY_TYPE_RSA is not set CONFIG_MODULE_SIG_KEY_TYPE_ECDSA=y Regards, Ralf
On 4/12/23 03:55, Ralf Mardorf wrote:
Hi,
Bit hard to say from above - clearly these need 2 different keys (right?) also you dont say what CONFIG_MODULE_COMPRESS_xx are set to either since you have 2 different module compressions as well as keys being different. Maybe post the actual fatal kernel error exactly - is it possible the error you printed was non-fatal and something else kiilled boot? My understanding of out of tree signed kernel modules (and some tools) is captured here (wiki is similar but likely bit out of date vs GH): https://github.com/gene-git/Arch-SKM That all said, it appears you've built the kernel with one cert and signed using a different one - maybe? best, gene
On Wed, 2023-04-12 at 06:54 -0400, Genes Lists wrote:
On 4/12/23 03:55, Ralf Mardorf wrote Bit hard to say from above - clearly these need 2 different keys (right?) also you dont say what CONFIG_MODULE_COMPRESS_xx are set to either since you have 2 different module compressions as well as keys being different.
Hi, thank you. I try to post complete logs via pastebin or something else soon, but for the next hours I need to shut down the machine, to do some work, among other things I'll copy the Arch install from the original SATA SSD to a NVMe SSD. [rocketmouse@archlinux ~]$ grep MODULE_COMPRESS /lib/modules/4.19.271- rt120-0.300-cornflower/build/.config CONFIG_MODULE_COMPRESS=y # CONFIG_MODULE_COMPRESS_GZIP is not set CONFIG_MODULE_COMPRESS_XZ=y [rocketmouse@archlinux ~]$ grep MODULE_COMPRESS /lib/modules/6.2.10- arch1-1/build/.config # CONFIG_MODULE_COMPRESS_NONE is not set # CONFIG_MODULE_COMPRESS_GZIP is not set # CONFIG_MODULE_COMPRESS_XZ is not set CONFIG_MODULE_COMPRESS_ZSTD=y
Maybe post the actual fatal kernel error exactly - is it possible the error you printed was non-fatal and something else kiilled boot?
That's possible. At the moment I've got 4 Arch Linux kernels that fail
to boot. 3 were build by me, 1 is from an official Arch repo.
[rocketmouse@archlinux ~]$ grep -ePKCS -eunknown /mnt/m1.xubu20.04/boot/grub/grub.cfg
menuentry " Arch Linux Rt Cornflower, PKCS#7 signature not signed with a trusted key" {
menuentry " Arch Linux Rt Pussytoes, PKCS#7 signature not signed with a trusted key" {
menuentry " Arch Linux Rt Securityink, PKCS#7 signature not signed with a trusted key" {
menuentry " Arch extra/linux-rt-lts, unknown issue" {
The one from the repo doesn't spit a PKCS#7 signature error message,
just the kernels build by me do so. All 4 kernels are rt patched
kernels. However, the non-lts rt from the repos, extra/linux-rt
6.2.0.3.realtime1-3 does finish startup without a problem.
I've got a lot of way older (and other new) kernels for different Linux
distros that don't fail to boot, just two other kernels also fail to
boot, but with an "too old" error message.
The kernel parameter "module.sig_enforce=0" was just a test. At some
point after the startup hanged I pushed either Ctrl+Alt+Del or the reset
or power off button.
[rocketmouse@archlinux ~]$ journalctl -b -2
Apr 12 09:25:45 archlinux kernel: Linux version 4.19.271-rt120-0.300-cornflower (linux-rt-cornflower@archlinux) (gcc version 12.2.1 20230111 (GCC)) #1 SMP PREEMPT RT Sat, 04 Feb 2023 02:01:3>
Apr 12 09:25:45 archlinux kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux-rt-cornflower root=/dev/disk/by-label/s3.archlinux ro module.sig_enforce=0
[snip]
Apr 12 09:25:45 archlinux kernel: Loading compiled-in X.509 certificates
Apr 12 09:25:45 archlinux kernel: Loaded X.509 cert 'Build time autogenerated kernel key: f1c3403526458c3d1252b029fd8c628d7fa915df'
[snip]
Apr 12 09:25:47 archlinux libvirtd[422]: libvirt version: 9.2.0
Apr 12 09:25:47 archlinux libvirtd[422]: hostname: archlinux
Apr 12 09:25:47 archlinux libvirtd[422]: internal error: Missing udev property 'ID_VENDOR_ID' on '1-11'
Apr 12 09:25:47 archlinux libvirtd[422]: internal error: Missing udev property 'ID_VENDOR_ID' on '1-7'
Apr 12 09:25:47 archlinux libvirtd[422]: internal error: Missing udev property 'ID_VENDOR_ID' on 'usb2'
Apr 12 09:25:47 archlinux kernel: pci 0000:05:00.0: invalid short VPD tag 00 at offset 1
Apr 12 09:25:47 archlinux kernel: acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
Apr 12 09:25:47 archlinux kernel: acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)
Apr 12 09:25:47 archlinux kernel: PKCS#7 signature not signed with a trusted key
Apr 12 09:25:47 archlinux kernel: r8125: loading out-of-tree module taints kernel.
Apr 12 09:25:47 archlinux kernel: r8125: module verification failed: signature and/or required key missing - tainting kernel
Apr 12 09:25:47 archlinux kernel: r8125 2.5Gigabit Ethernet driver 9.011.00-NAPI loaded
Apr 12 09:25:47 archlinux kernel: r8125: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
Apr 12 09:25:47 archlinux kernel: r8125 Copyright (C) 2022 Realtek NIC software team
My understanding of out of tree signed kernel modules (and some tools) is captured here (wiki is similar but likely bit out of date vs GH):
https://github.com/gene-git/Arch-SKM
That all said, it appears you've built the kernel with one cert and signed using a different one - maybe?
I don't understand it. If it should be a signing issue, then it does matter when using one mobo and doesn't matter, if the same SSD holding the Arch Linux install is connected to another mobo? It only matters when UEFI booting (with secure boot disabled), but doesn't matter when legacy booting is enabled by the older mobo? Isn't this signing independent of the used boot mechanism? Maybe the culprit is something else, but I couldn't identify something else. Regards, Ralf
On 4/12/23 07:54, Ralf Mardorf wrote:
I don't understand it. If it should be a signing issue, then it does matter when using one mobo and doesn't matter, if the same SSD holding the Arch Linux install is connected to another mobo? It only matters when UEFI booting (with secure boot disabled), but doesn't matter when legacy booting is enabled by the older mobo? Isn't this signing independent of the used boot mechanism?
Maybe the culprit is something else, but I couldn't identify something else.
1) Nothing you've shared so far indicates a fatal module signing issue - right? All I've seen is benign warning. 2) uefi vs mbr are not related directly to signed modules in-tree or out-of-tree (OOT) - no. 3) That said, if OOT signed modules are somehow making a warning or error, please keep in mind that dkms is -supposed- to use the appropriate key to sign the modules - and that can happen on every boot with dkms if it decides to rebuild the out-of-tree module. My comment was simply make sure you always have the correct keys available for dkms to sign with - correct being the same one compiled into the kernel of course as I describe on my gh page. That way, when those OOT modules do get signed (via dkms) they at least get signed with a key the kernel trusts (the same one used when building that kernel).
On 12-04-2023 09:55, Ralf Mardorf wrote:
Hi,
some kernels that do boot on my old UEFI computer with legacy boot enabled, don't boot on my new UEFI computer were the Intel processor graphics doesn't allow to enable legacy boot, but at least _secure boot_ is _disabled_.
What can I do to get rid of the error?
[rocketmouse@archlinux ~]$ grep MODULE_SIG /lib/modules/4.19.271-rt120-0.300-cornflower/build/.config CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
A kernel that doesn't fail:
[rocketmouse@archlinux ~]$ grep MODULE_SIG /lib/modules/6.2.10-arch1-1/build/.config CONFIG_MODULE_SIG_FORMAT=y CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_SIG_ALL=y # CONFIG_MODULE_SIG_SHA1 is not set # CONFIG_MODULE_SIG_SHA224 is not set # CONFIG_MODULE_SIG_SHA256 is not set # CONFIG_MODULE_SIG_SHA384 is not set CONFIG_MODULE_SIG_SHA512=y CONFIG_MODULE_SIG_HASH="sha512" CONFIG_MODULE_SIG_KEY="certs/signing_key.pem" # CONFIG_MODULE_SIG_KEY_TYPE_RSA is not set CONFIG_MODULE_SIG_KEY_TYPE_ECDSA=y
Regards, Ralf
The booting 6.2.10 kernel sets 2 options the non-booting 4.19.271 kernel doesn't : CONFIG_MODULE_SIG_FORMAT=y and CONFIG_MODULE_SIG_KEY_TYPE_ECDSA=y Does it make a difference if you add those options to the 4.19.271 kernel build ? LW
On Wed, 2023-04-12 at 06:54 -0400, Genes Lists wrote:
Maybe post the actual fatal kernel error exactly - is it possible the error you printed was non-fatal and something else kiilled boot?
Hi, yes, it is something else. $ grep -i module_sig /lib/modules/4.19.277-rt122-0.300-securityink/build/.config # CONFIG_MODULE_SIG is not set $ journalctl -b -1 Apr 17 00:49:36 archlinux kernel: Linux version 4.19.277-rt122-0.300-securityink (linux-rt-securityink@archlinux) (gcc version 12.2.1 20230201 (GCC)) #1 SMP PREEMPT RT Sun, 16 Apr 2023 23:41> Apr 17 00:49:36 archlinux kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux-rt-securityink root=/dev/disk/by-label/m1.archlinux ro [snip] Apr 17 00:49:49 archlinux systemd[1]: Finished Alice DHCP. Apr 17 00:49:49 archlinux systemd[1]: Reached target Multi-User System. Apr 17 00:49:49 archlinux systemd[1]: Reached target Graphical Interface. Apr 17 00:49:49 archlinux systemd[1]: Starting Realtime IRQ thread system tuning... Apr 17 00:49:50 archlinux rtirq[822]: Setting IRQ priorities: start [xhci.hcd] irq=130 pid=200 prio=90: OK. Apr 17 00:49:50 archlinux rtirq[822]: Setting IRQ priorities: start [snd_hdsp] irq=16 pid=401 prio=85: OK. Apr 17 00:49:50 archlinux systemd[1]: Finished Realtime IRQ thread system tuning. Apr 17 00:49:50 archlinux systemd[1]: Startup finished in 8.885s (firmware) + 17.170s (loader) + 5.765s (kernel) + 13.587s (userspace) = 45.408s. Apr 17 00:49:58 archlinux dhcpcd[506]: enp5s0: failed to request DHCPv6 information Apr 17 00:49:58 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:08 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:18 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:28 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:38 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:48 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:50:58 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:51:08 archlinux dhcpcd[506]: enp5s0: requesting DHCPv6 information Apr 17 00:51:09 archlinux systemd[1]: Received SIGINT. Apr 17 00:51:09 archlinux systemd[1]: Activating special unit System Reboot... [snip] At this time boot hanged and I pushed Ctrl+Alt+Del. However, "enp5s0: requesting DHCPv6 information" is seemingly not the culprit. This kernel does finish startup: $ journalctl -b Apr 17 00:52:51 archlinux kernel: Linux version 6.2.11-arch1-1 (linux@archlinux) (gcc (GCC) 12.2.1 20230201, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Thu, 13 Apr 2023 16:59:24 +0000 Apr 17 00:52:51 archlinux kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=/dev/disk/by-label/m1.archlinux ro [snip] Apr 17 00:52:52 archlinux systemd[1]: Finished Alice DHCP. Apr 17 00:52:52 archlinux systemd[1]: Reached target Multi-User System. Apr 17 00:52:52 archlinux systemd[1]: Reached target Graphical Interface. Apr 17 00:52:52 archlinux kernel: intel_tcc_cooling: TCC Offset locked Apr 17 00:52:52 archlinux kernel: intel_rapl_common: Found RAPL domain package Apr 17 00:52:52 archlinux kernel: intel_rapl_common: Found RAPL domain core Apr 17 00:52:52 archlinux kernel: intel_rapl_common: Found RAPL domain uncore Apr 17 00:52:52 archlinux systemd[1]: Starting Realtime IRQ thread system tuning... Apr 17 00:52:52 archlinux kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0 Apr 17 00:52:52 archlinux kernel: ACPI: video: Video Device [GFX0] (multi-head: yes rom: no post: no) Apr 17 00:52:52 archlinux kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7 Apr 17 00:52:52 archlinux kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) Apr 17 00:52:52 archlinux dhcpcd[373]: enp5s0: waiting for carrier Apr 17 00:52:52 archlinux dhcpcd[373]: enp5s0: waiting for carrier Apr 17 00:52:52 archlinux kernel: fbcon: i915drmfb (fb0) is primary device Apr 17 00:52:52 archlinux systemd[1]: Finished Realtime IRQ thread system tuning. Apr 17 00:52:52 archlinux kernel: Console: switching to colour frame buffer device 240x67 Apr 17 00:52:52 archlinux systemd[1]: Startup finished in 8.873s (firmware) + 1min 23.388s (loader) + 5.268s (kernel) + 2.265s (userspace) = 1min 39.796s. [snip] $ journalctl -b | grep "enp5s0: requesting DHCPv6 information" | head Apr 17 00:53:01 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:53:11 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:53:21 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:53:31 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:53:41 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:53:51 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:54:01 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:54:11 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:54:21 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information Apr 17 00:54:31 archlinux dhcpcd[373]: enp5s0: requesting DHCPv6 information It's an issue, but not the cause that prevents the other kernel from finishing startup, https://bbs.archlinux.org/viewtopic.php?id=275022 . The journal of the other kernel shows much yellow and read lines. I don't have time today to take a closer look at it. Regards, Ralf
participants (3)
-
Genes Lists
-
Lone_Wolf
-
Ralf Mardorf