Bug#1030200: linux-image-6.1.0-3-amd64: "Loading of module with unavailable key is rejected", /proc/keys says key is loaded; system unbootable

[наб]

Naturally, by
but the kernel says it doesn't have a matching signature.
I meant
but the kernel says it doesn't have a matching certificate.

In both the 6.1 and 6.0 dmesg I see, for /cert/:
[ 0.737895] Loading compiled-in X.509 certificates
[ 0.751773] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 0.751784] Loaded X.509 cert 'Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f'
[ 0.756673] integrity: Loading X.509 certificate: UEFI:db
[ 0.757146] integrity: Loaded X.509 cert 'babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6'
[ 0.757147] integrity: Loading X.509 certificate: UEFI:db
[ 0.757296] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 0.758493] ima: No TPM chip found, activating TPM-bypass!
[ 0.758497] ima: Allocated hash algorithm: sha256
(but 6.0 also says "ima: No architecture policies found").

Attaching a full 6.0 dmesg for comparison since i forgor 💀 and it was 6am.

For your convenience, here's also a trimmed-down (time and stochastic
assignment effects removed) diff:
-- >8 --
--- dmesg-6.0-notime 2023-02-01 14:44:19.263754069 +0100
+++ dmesg-6.1-notime 2023-02-01 14:44:24.591989769 +0100
@@ -1,6 +1,6 @@
microcode: microcode updated early to revision 0xf4, date = 2022-07-31
-Linux version 6.0.0-5-amd64 (debian...@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.10-1 (2022-11-26)
-Command line: initrd=\klapki\731b69f0dac147efadfed92f12712736\6.0.0-5-amd64\initrd.img-6.0.0-5-amd64 root=zfs:AUTO fbcon=rotate:3 intel_iommu=on zfs.zfs_arc_max=12884901888 quiet module.sig_enforce=1
+Linux version 6.1.0-3-amd64 (debian...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29)
+Command line: initrd=\klapki\731b69f0dac147efadfed92f12712736\6.1.0-3-amd64\initrd.img-6.1.0-3-amd64 root=zfs:AUTO fbcon=rotate:3 intel_iommu=on zfs.zfs_arc_max=12884901888 quiet module.sig_enforce=1
x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
@@ -37,8 +37,7 @@ BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000046effffff] usable
NX (Execute Disable) protection: active
efi: EFI v2.70 by American Megatrends
-efi: ACPI 2.0=0x8c8c7000 ACPI=0x8c8c7000 SMBIOS=0x8ce15000 SMBIOS 3.0=0x8ce14000 MEMATTR=0x885fd018 ESRT=0x88627f98 RNG=0x8c8c6018
-efi: seeding entropy pool
+efi: ACPI 2.0=0x8c8c7000 ACPI=0x8c8c7000 SMBIOS=0x8ce15000 SMBIOS 3.0=0x8ce14000 MEMATTR=0x88602018 ESRT=0x88626d98 INITRD=0x8510df18 RNG=0x8c8c6018
random: crng init done
Kernel is locked down from EFI Secure Boot; see man kernel_lockdown.7
secureboot: Secure boot enabled
@@ -51,10 +50,10 @@ e820: remove [mem 0x000a0000-0x000fffff] usable
last_pfn = 0x46f000 max_arch_pfn = 0x400000000
x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
last_pfn = 0x8d000 max_arch_pfn = 0x400000000
-esrt: Reserving ESRT space from 0x0000000088627f98 to 0x0000000088627fd0.
-e820: update [mem 0x88627000-0x88627fff] usable ==> reserved
+esrt: Reserving ESRT space from 0x0000000088626d98 to 0x0000000088626dd0.
+e820: update [mem 0x88626000-0x88626fff] usable ==> reserved
Using GB pages for direct mapping
-RAMDISK: [mem 0x7edb1000-0x7fffffff]
+RAMDISK: [mem 0x7ed5a000-0x7fffffff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000008C8C7000 000024 (v02 ALASKA)
ACPI: XSDT 0x000000008C8C70C0 000104 (v01 ALASKA A M I 01072009 AMI 00010013)
@@ -167,7 +166,7 @@ PM: hibernation: Registered nosave memory: [mem 0x0009e000-0x000fffff]
PM: hibernation: Registered nosave memory: [mem 0x40000000-0x403fffff]
PM: hibernation: Registered nosave memory: [mem 0x84ff1000-0x84ff1fff]
PM: hibernation: Registered nosave memory: [mem 0x84ff2000-0x84ff2fff]
-PM: hibernation: Registered nosave memory: [mem 0x88627000-0x88627fff]
+PM: hibernation: Registered nosave memory: [mem 0x88626000-0x88626fff]
PM: hibernation: Registered nosave memory: [mem 0x8bc67000-0x8c8b5fff]
PM: hibernation: Registered nosave memory: [mem 0x8c8b6000-0x8c90bfff]
PM: hibernation: Registered nosave memory: [mem 0x8c90c000-0x8c96bfff]
@@ -195,16 +194,16 @@ pcpu-alloc: [0] 0 1 2 3 4 5 6 7
Fallback order for Node 0: 0
Built 1 zonelists, mobility grouping on. Total pages: 4106436
Policy zone: Normal
-Kernel command line: initrd=\klapki\731b69f0dac147efadfed92f12712736\6.0.0-5-amd64\initrd.img-6.0.0-5-amd64 root=zfs:AUTO fbcon=rotate:3 intel_iommu=on zfs.zfs_arc_max=12884901888 quiet module.sig_enforce=1
+Kernel command line: initrd=\klapki\731b69f0dac147efadfed92f12712736\6.1.0-3-amd64\initrd.img-6.1.0-3-amd64 root=zfs:AUTO fbcon=rotate:3 intel_iommu=on zfs.zfs_arc_max=12884901888 quiet module.sig_enforce=1
DMAR: IOMMU enabled
Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear)
Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
mem auto-init: stack:all(zero), heap alloc:on, heap free:off
software IO TLB: area num 8.
-Memory: 2251624K/16687112K available (12294K kernel code, 2264K rwdata, 8860K rodata, 2732K init, 5404K bss, 493420K reserved, 0K cma-reserved)
+Memory: 2206152K/16687112K available (14342K kernel code, 2300K rwdata, 13348K rodata, 2760K init, 5216K bss, 499928K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
-ftrace: allocating 39267 entries in 154 pages
-ftrace: allocated 154 pages with 4 groups
+ftrace: allocating 39944 entries in 157 pages
+ftrace: allocated 157 pages with 5 groups
Dynamic Preempt: voluntary
rcu: Preemptible hierarchical RCU implementation.
rcu: RCU restricting CPUs from NR_CPUS=8192 to nr_cpu_ids=8.
@@ -244,6 +243,7 @@ TOMOYO Linux initialized
LSM support for eBPF active
Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
+x86/cpu: SGX disabled by BIOS.
CPU0: Thermal monitoring enabled (TM1)
process: using mwait in idle threads
Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
@@ -257,7 +257,7 @@ Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
MMIO Stale Data: Mitigation: Clear CPU buffers
SRBDS: Mitigation: Microcode
-Freeing SMP alternatives memory: 32K
+Freeing SMP alternatives memory: 36K
smpboot: CPU0: Intel(R) Core(TM) i5-10210Y CPU @ 1.00GHz (family: 0x6, model: 0x8e, stepping: 0xc)
cblist_init_generic: Setting adjustable number of callback queues.
cblist_init_generic: Setting shift to 3 and lim to 1.
@@ -318,21 +318,18 @@ ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
-ACPI: Added _OSI(Linux-Dell-Video)
-ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
-ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
ACPI: 14 ACPI AML tables successfully acquired and loaded
ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0xFFFF9374C1827000 000441 (v02 PmRef Cpu0Ist 00003000 INTL 20160422)
+ACPI: SSDT 0xFFFF9DDE811D8000 000441 (v02 PmRef Cpu0Ist 00003000 INTL 20160422)
ACPI: \_PR_.PR00: _OSC native thermal LVT Acked
ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0xFFFF9374C182D000 0003FF (v02 PmRef Cpu0Cst 00003001 INTL 20160422)
+ACPI: SSDT 0xFFFF9DDE811BA800 0003FF (v02 PmRef Cpu0Cst 00003001 INTL 20160422)
ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0xFFFF9374C1837000 000D14 (v02 PmRef ApIst 00003000 INTL 20160422)
+ACPI: SSDT 0xFFFF9DDE81813000 000D14 (v02 PmRef ApIst 00003000 INTL 20160422)
ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0xFFFF9374C1829400 000317 (v02 PmRef ApHwp 00003000 INTL 20160422)
+ACPI: SSDT 0xFFFF9DDE811BA000 000317 (v02 PmRef ApHwp 00003000 INTL 20160422)
ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0xFFFF9374C1828800 00030A (v02 PmRef ApCst 00003000 INTL 20160422)
+ACPI: SSDT 0xFFFF9DDE811BA400 00030A (v02 PmRef ApCst 00003000 INTL 20160422)
ACPI: EC: EC started
ACPI: EC: interrupt blocked
ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
@@ -454,7 +451,7 @@ PCI: pci_cache_line_size set to 64 bytes
e820: reserve RAM buffer [mem 0x00058000-0x0005ffff]
e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
e820: reserve RAM buffer [mem 0x84ff1000-0x87ffffff]
-e820: reserve RAM buffer [mem 0x88627000-0x8bffffff]
+e820: reserve RAM buffer [mem 0x88626000-0x8bffffff]
e820: reserve RAM buffer [mem 0x8bc67000-0x8bffffff]
e820: reserve RAM buffer [mem 0x8d000000-0x8fffffff]
e820: reserve RAM buffer [mem 0x46f000000-0x46fffffff]
@@ -563,16 +560,17 @@ pci 0000:01:00.0: Adding to iommu group 12
pci 0000:02:00.0: Adding to iommu group 13
DMAR: Intel(R) Virtualization Technology for Directed I/O
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
-software IO TLB: mapped [mem 0x000000007adb1000-0x000000007edb1000] (64MB)
+software IO TLB: mapped [mem 0x000000007ad5a000-0x000000007ed5a000] (64MB)
platform rtc_cmos: registered platform RTC device (no PNP device found)
Initialise system trusted keyrings
Key type blacklist registered
workingset: timestamp_bits=36 max_order=22 bucket_order=0
zbud: loaded
integrity: Platform Keyring initialized
+integrity: Machine keyring initialized
Key type asymmetric registered
Asymmetric key parser 'x509' registered
-Freeing initrd memory: 18748K
+Freeing initrd memory: 19096K
alg: self-tests for CTR-KDF (hmac(sha256)) passed
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
io scheduler mq-deadline registered
@@ -631,7 +629,6 @@ integrity: Loading X.509 certificate: UEFI:db
integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
ima: No TPM chip found, activating TPM-bypass!
ima: Allocated hash algorithm: sha256
-ima: No architecture policies found
evm: Initialising EVM extended attributes:
evm: security.selinux
evm: security.SMACK64 (disabled)
@@ -642,12 +639,14 @@ evm: security.apparmor
evm: security.ima
evm: security.capability
evm: HMAC attrs: 0x1
+audit: type=1807 audit(1675224608.559:2): action=measure func=KEXEC_KERNEL_CHECK res=1
+audit: type=1807 audit(1675224608.559:3): action=measure func=MODULE_CHECK res=1
Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7
Freeing unused decrypted memory: 2036K
-Freeing unused kernel image (initmem) memory: 2732K
-Write protecting the kernel read-only data: 24576k
+Freeing unused kernel image (initmem) memory: 2760K
+Write protecting the kernel read-only data: 30720k
Freeing unused kernel image (text/rodata gap) memory: 2040K
-Freeing unused kernel image (rodata/data gap) memory: 1380K
+Freeing unused kernel image (rodata/data gap) memory: 988K
x86/mm: Checked W+X mappings: passed, no W+X pages found.
Run /init as init process
with arguments:

-...
+Loading of module with unavailable key is rejected
-- >8 --

The only other thing that jumps out is maybe that "integrity: Machine
keyring initialized" is also seen? But that's only additive
(to support the MOK mechanism, from a quick glance at
security/integrity/platform_certs/machine_keyring.c),
and the other certs are already loaded from before.

Similarly, security/integrity/platform_certs/platform_keyring.c was last
touched in 2019, and the interesting parts of
security/integrity/platform_certs/load_uefi.c
security/integrity/platform_certs/efi_parser.c
are of about the same vintage.
It's very much unclear to me what's happened here.

Best,
наб

[наб]

Turns out Debian .config includes dyndbg, so I tried booting with
dyndbg="+pfm; module iommu =_; module acpi =_" log_buf_len=4M
and got A Result.

In both cases I broke as in the initrd (too late, it seems),
echo MARK > /dev/kmsg
modprobe zfs
echo MARK > /dev/kmsg
modprobe vfat
echo MARK > /dev/kmsg
then i turned off dyndbg.

dmesg and journalctl -b in resp. files
(all compressed now, sorry; dmesgs are 4M and journals 6M per).

dkms-$kver is /lib/modules/.../dkms (with the DKMSed .kos)
and I also added vfat.ko for reference,
but that's, naturally, from the package.

Interesting bits: /both/ logs have this exact fragment
(time is different, of course):
[ 0.756794] integrity: Loaded X.509 cert 'babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6'
[ 0.756794] integrity: Loading X.509 certificate: UEFI:db
[ 0.756795] asymmetric_keys:asymmetric_key_preparse: Trying parser 'x509'
[ 0.756834] x509_key_parser:x509_note_sig_algo: X.509: PubKey Algo: 15
[ 0.756955] x509_key_parser:x509_process_extension: X.509: Extension: 44
[ 0.756973] x509_key_parser:x509_process_extension: X.509: Extension: 71
[ 0.756987] x509_key_parser:x509_note_OID: X.509: Unknown OID: [551] 2.16.840.1.113730.1.1
[ 0.756995] x509_key_parser:x509_process_extension: X.509: Extension: 98
[ 0.757013] x509_key_parser:x509_process_extension: X.509: Extension: 72
[ 0.757033] x509_key_parser:x509_process_extension: X.509: Extension: 65
[ 0.757052] x509_key_parser:x509_process_extension: X.509: Extension: 68
[ 0.757071] x509_key_parser:x509_process_extension: X.509: Extension: 64
[ 0.757072] x509_key_parser:x509_process_extension: X.509: subjkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
[ 0.757087] x509_key_parser:x509_note_tbs_certificate: X.509: x509_note_tbs_certificate(,4,04,8,646)!
[ 0.757106] x509_key_parser:x509_note_signature: X.509: Signature: alg=15, size=257
[ 0.757117] x509_key_parser:x509_akid_note_kid: X.509: AKID: keyid: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
[ 0.757118] x509_key_parser:x509_akid_note_kid: X.509: authkeyid 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
[ 0.757271] asymmetric_keys:asymmetric_key_preparse: Parser recognised the format (ret 0)
[ 0.757274] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 0.757687] integrity:load_uefi_certs: integrity: dbx variable wasn't found
[ 0.758064] integrity:load_uefi_certs: integrity: mokx variable wasn't found
[ 0.758435] integrity:load_moklist_certs: integrity: MokListRT variable wasn't found

And when loading vfat, both have this
(uargs and the mokx digest are different, that's expected):
[ 37.135400] MARK
[ 40.188878] main:__do_sys_finit_module: finit_module: fd=3, uargs=0000000061bb63d7, flags=0
[ 40.190252] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375 26081 726520426f6f74204341)
[ 40.190256] asymmetric_keys:find_asymmetric_key: Look up: "ex:32a0287f841a036fa393c1e065c43ae6b2422643311e301c0603550403131544656269616e2053656375726520426f6f74204341"
[ 40.191459] signing:mod_is_hash_blacklisted: 188779 digest: ba2fe77f90be3c8ca26422359c20213f9dd0f68c9b9bbd1f54f47e77e6e124cf
[ 40.191470] main:layout_sections: Core section allocation order:
[ 40.191472] main:layout_sections: .text
[ 40.191473] main:layout_sections: .text.unlikely
[ 40.191474] main:layout_sections: .exit.text

But when searching for 7e7595e2f222646de0dcfee034bd181ed37844b7
(to get the first instance of a DKMSed module being loaded;
that bit also matches the cert serial, apparently),
6.0.0-5-amd64 says this:
[ 1.757036] main:__do_sys_finit_module: finit_module: fd=3, uargs=00000000160ad9df, flags=0
[ 1.758562] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731)
[ 1.758566] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a"
[ 1.758572] asymmetric_keys:find_asymmetric_key: Request for key 'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a' err -11
[ 1.759871] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f7731)
[ 1.759872] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a"
[ 1.761421] signing:mod_is_hash_blacklisted: 233242 digest: f4bef7055edd1138e68926ab010f9925dd88680732d7f47042b879a7fd9ef66a
[ 1.761434] spl: loading out-of-tree module taints kernel.
[ 1.761443] main:layout_sections: Core section allocation order:
[ 1.761444] main:layout_sections: .text
[ 1.761445] main:layout_sections: .text.unlikely

But 6.1.0-3-amd64 says this:
[ 1.733680] main:__do_sys_finit_module: finit_module: fd=3, uargs=00000000822587e4, flags=0
[ 1.736878] pkcs7_message:pkcs7_find_key: PKCS7: Sig 1: Issuing X.509 cert not found (#7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b 27399 0c024442310f300d06035504070c064b72616b6f7731)
[ 1.736881] asymmetric_keys:find_asymmetric_key: Look up: "ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d060355040 27400 70c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a"
[ 1.736887] asymmetric_keys:find_asymmetric_key: Request for key 'ex:7e7595e2f222646de0dcfee034bd181ed37844b7310b300906035504061302504c310b3009060355040b0c024442310f300d06 27401 035504070c064b72616b6f773122302006035504030c19626162746f702e6e6162696a61637a6c6577656c692e78797a' err -11
[ 1.736890] Loading of module with unavailable key is rejected


What this means is unclear to me, but it's odd.

наб

[наб]

Control: found -1 6.1.20-1

Updated to linux-image-6.1.0-7-amd64 (6.1.20-1);
still happens.

наб

[наб]

If anyone has a faintest idea so as to what the problem may be, please help;
the only vaguely-related config change is
INTEGRITY_MACHINE_KEYRING going from unset to y,
but that shouldn't(! not that it doesn't, the code is an enigma to me,
but as i understand it and as i read the kconfig, it shouldn't)
change anything if you aren't a MOK user, and I'm not.

Please advise.

наб

[наб]

Control: retitle -1 linux-image-6.1.0-3-amd64: .platform keyring (EFI DB variable) no longer trusted to sign modules, regression against 6.0
Control: tags -1 + patch

In many ways I went wrong by limiting my search to the linux checkout,
and not the source package.

Upstream kernel/module/signing.c#mod_verify_sig() ends with:
return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
}

In 6.1.20-1 it ends with:
ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
pr_devel("verify_pkcs7_signature() = %d\n", ret);

/* checking hash of module is in blacklist */
if (!ret)
ret = mod_is_hash_blacklisted(mod, wholelen);

return ret;
}

But in 6.0.12-1 it ended with (excuse patch format):
@@ -116,6 +116,13 @@ int mod_verify_sig(const void *mod, stru
VERIFYING_MODULE_SIGNATURE,
NULL, NULL);
pr_devel("verify_pkcs7_signature() = %d\n", ret);
+ 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);
+ pr_devel("verify_pkcs7_signature() = %d\n", ret);
+ }

/* checking hash of module is in blacklist */
if (!ret)

So in 6.0.x, debian carried a patch
(features/all/db-mok-keyring/KEYS-Make-use-of-platform-keyring-for-module-signature.patch),
which was dropped in
commit 9aa15a22634335db058256092572fd2725ca674b
Author: Luca Boccassi <bl...@debian.org>
Date: Thu Oct 13 23:23:28 2022 +0100

Drop obsolete MODSIGN patches

Upstream loads keys from MoK, no need for the out-of-tree patches anymore
and that commit is included in all debian/6.1* tags on salsa.

On Fri, Mar 31, 2023 at 01:45:08AM +0200, наб wrote:
> keys-6.0:19c0bfbd I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 1
> keys-6.1:29a13614 I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 2
>
> Note how there's somehow a second key in .secondary_trusted_keys.
> Whether this means something or is an accounting difference
> is unclear to me at this time.

That patch was added for #935945, which also notes a method of having
keyctl dump keyring contents, which I couldn't figure out.

However, on 6.1 (dumped from the initrd):
# keyctl list %:.builtin_trusted_keys
2 keys in keyring:
672487752: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
874879581: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f
# keyctl list %:.platform
4 keys in keyring:
374796544: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6
116765678: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot DB 2023: 00befacaa0
20694596: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot CA: 00befa30fa
946336801: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
# keyctl list %:.secondary_trusted_keys
2 keys in keyring:
624245999: ---lswrv 0 0 keyring: .builtin_trusted_keys
996684961: ---lswrv 0 0 keyring: .machine
# keyctl list %:.machine
keyring is empty

And on 6.0:
# keyctl list %:.builtin_trusted_keys
Please touch the device.
2 keys in keyring:
417373165: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
726407570: ---lswrv 0 0 asymmetric: Debian Secure Boot Signer 2022 - linux: 14011249c2675ea8e5148542202005810584b25f
# keyctl list %:.platform
4 keys in keyring:
699875236: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz: 82b7fc21cc3f583ac4a7b05712d95377f41fbdd6
885300684: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot DB 2023: 00befacaa0
927553785: ---lswrv 0 0 asymmetric: babtop.nabijaczleweli.xyz SecureBoot CA: 00befa30fa
707478853: ---lswrv 0 0 asymmetric: Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1
# keyctl list %:.secondary_trusted_keys
1 key in keyring:
889210333: ---lswrv 0 0 keyring: .builtin_trusted_keys
# keyctl list %:.machine
Can't find 'keyring:.machine'

So, to summarise:
6.0 upstream trusts the built-in keys,
and carries a patch to trust the platform
6.1 upstream trusts the built-in keys and MOK
(debian just enables trusting MOK always)

See certs/system_keyring.c:
static __init struct key_restriction *get_builtin_and_secondary_restriction(void)
{
struct key_restriction *restriction;

restriction = kzalloc(sizeof(struct key_restriction), GFP_KERNEL);

if (!restriction)
panic("Can't allocate secondary trusted keyring restriction\n");

if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
restriction->check = restrict_link_by_builtin_secondary_and_machine;
else
restriction->check = restrict_link_by_builtin_and_secondary_trusted;

return restriction;
}

void __init set_machine_trusted_keys(struct key *keyring)
{
machine_trusted_keys = keyring;

if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
panic("Can't link (machine) trusted keyrings\n");
}
/**
* restrict_link_by_builtin_secondary_and_machine - Restrict keyring addition.
* @dest_keyring: Keyring being linked to.
* @type: The type of key being added.
* @payload: The payload of the new key.
* @restrict_key: A ring of keys that can be used to vouch for the new cert.
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in, the secondary, or
* the machine keyrings.
*/
int restrict_link_by_builtin_secondary_and_machine(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
if (machine_trusted_keys && type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &machine_trusted_keys->payload)
/* Allow the machine keyring to be added to the secondary */
return 0;

return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
payload, restrict_key);
}
security/integrity/digsig.c:
static int __init __integrity_init_keyring(const unsigned int id,
key_perm_t perm,
struct key_restriction *restriction)
{
const struct cred *cred = current_cred();
int err = 0;

keyring[id] = keyring_alloc(keyring_name[id], KUIDT_INIT(0),
KGIDT_INIT(0), cred, perm,
KEY_ALLOC_NOT_IN_QUOTA, restriction, NULL);
if (IS_ERR(keyring[id])) {
err = PTR_ERR(keyring[id]);
pr_info("Can't allocate %s keyring (%d)\n",
keyring_name[id], err);
keyring[id] = NULL;
} else {
if (id == INTEGRITY_KEYRING_PLATFORM)
set_platform_trusted_keys(keyring[id]);
if (id == INTEGRITY_KEYRING_MACHINE && trust_moklist())
set_machine_trusted_keys(keyring[id]);
if (id == INTEGRITY_KEYRING_IMA)
load_module_cert(keyring[id]);
}

return err;
}
(features/all/db-mok-keyring/trust-machine-keyring-by-default.patch
makes trust_moklist() be always true, hence why I see .machine linked
to secondary even though I don't use MOK).

And compare this with how the non-MOK restriction works:
/**
* restrict_link_by_builtin_and_secondary_trusted - Restrict keyring
* addition by both builtin and secondary keyrings
*
* Restrict the addition of keys into a keyring based on the key-to-be-added
* being vouched for by a key in either the built-in or the secondary system
* keyrings.
*/
int restrict_link_by_builtin_and_secondary_trusted(
struct key *dest_keyring,
const struct key_type *type,
const union key_payload *payload,
struct key *restrict_key)
{
/* If we have a secondary trusted keyring, then that contains a link
* through to the builtin keyring and the search will follow that link.
*/
if (type == &key_type_keyring &&
dest_keyring == secondary_trusted_keys &&
payload == &builtin_trusted_keys->payload)
/* Allow the builtin keyring to be added to the secondary */
return 0;

return restrict_link_by_signature(dest_keyring, type, payload,
secondary_trusted_keys);
}

#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
void __init set_platform_trusted_keys(struct key *keyring)
{
platform_trusted_keys = keyring;
}
#endif

It's relatively trivial to port what's done with the machine keyring
here to the platform keyring, but that'd extend the reach of the
platform keyring more than desired
(DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING,
pkcs7_preparse()).

But most places that use VERIFY_USE_SECONDARY_KEYRING also check for
VERIFY_USE_PLATFORM_KEYRING right after, so dropping that patch is
baffling to me, since it's very much a regression, and it was spelled in
an upstream-endorsed way (indeed, look no further than
kexec_kernel_verify_pe_sig() which is exactly the same).

Attaching, essentially, a re-generated version of the old patch;
I'll build-test and post a Salsa MR tomorrow.

Best,
наб

[наб]

https://salsa.debian.org/kernel-team/linux/-/merge_requests/691

наб