As per kernel test week recommendation, I'm to report any bugs (?) and/or things out of the ordinary; not seen this kind of error prior to the 6.5 kernel series. I can boot my desktop, login and use it like normal, with the only exception for having the "integrity: Problem loading X.509 certificate -126" error/warning in my system logs. Did it work previously in Fedora? If so, what kernel version did the issue appear? - I didn't have it prior to the 6.5 kernel series. Can you reproduce this issue? - Yes, always, when updating to the latest 6.5.x kernel series. Does this problem occur with the latest rawhide kernel? - Yes. Are you running any modules that not shipped with directly Fedora's kernel?: - No, not to my knowledge; other than the "kernel", "kernel-core", "kernel-modules", "kernel-modules-core" and "kernel-modules-extra" packages. kernel-6.4.15-200.fc38.x86_64 (ok) kernel-6.4.16-200.fc38.x86_64 (ok) kernel-6.5.2-300.fc38.x86_64 (warning) [0.740002] integrity: Problem loading X.509 certificate -126 kernel-6.5.3-300.fc38.x86_64 (warning) [0.742365] integrity: Problem loading X.509 certificate -126 kernel-6.6.0-0.rc1.20230915git9fdfb15a3dbf.17.fc40.x86_64 (warning) [0.714577] integrity: Problem loading X.509 certificate -126 Default Fedora 38 install with encrypted main partition and secure boot enabled. sep 17 14:53:59 REDACTED kernel: Loading compiled-in X.509 certificates sep 17 14:53:59 REDACTED kernel: Loaded X.509 cert 'Fedora kernel signing key: REDACTED' sep 17 14:53:59 REDACTED kernel: page_owner is disabled sep 17 14:53:59 REDACTED kernel: Key type .fscrypt registered sep 17 14:53:59 REDACTED kernel: Key type fscrypt-provisioning registered sep 17 14:53:59 REDACTED kernel: Btrfs loaded, zoned=yes, fsverity=yes sep 17 14:53:59 REDACTED kernel: Key type big_key registered sep 17 14:53:59 REDACTED kernel: Key type encrypted registered sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:db sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'ASUSTeK MotherBoard SW Key Certificate: REDACTED' sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:db sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'ASUSTeK Notebook SW Key Certificate: REDACTED' sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:db sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: REDACTED' sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:db sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: REDACTED' sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:db sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: REDACTED' sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) sep 17 14:53:59 REDACTED kernel: integrity: Problem loading X.509 certificate -126 sep 17 14:53:59 REDACTED kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) sep 17 14:53:59 REDACTED kernel: integrity: Loaded X.509 cert 'Fedora Secure Boot CA: REDACTED' sep 17 14:53:59 REDACTED kernel: ima: No TPM chip found, activating TPM-bypass! sep 17 14:53:59 REDACTED kernel: Loading compiled-in module X.509 certificates sep 17 14:53:59 REDACTED kernel: Loaded X.509 cert 'Fedora kernel signing key: REDACTED'
removing the security tag, that is reserved for the CVE process.
I just upgraded to 6.5.5 on F38 and have noticed the same issue. Laptop is Dell XPS13 9315, booting in UEFI mode, secure boot, encrypted / and encrypted /boot. It was not there for previous kernels. Filtering messages for X.509 on the last boot: Oct 06 09:56:53 XXX kernel: Loading compiled-in X.509 certificates Oct 06 09:56:53 XXX kernel: Loaded X.509 cert 'Fedora kernel signing key: XXX' Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:db Oct 06 09:56:53 XXX kernel: integrity: Loaded X.509 cert 'Dell Inc.: Dell Bios DB Key: XXX' Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:db Oct 06 09:56:53 XXX kernel: integrity: Loaded X.509 cert 'Dell Inc.: Dell Bios FW Aux Authority 2018: XXX' Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:db Oct 06 09:56:53 XXX kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: XXX' Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:db Oct 06 09:56:53 XXX kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: XXX' Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) Oct 06 09:56:53 XXX kernel: integrity: Problem loading X.509 certificate -126 Oct 06 09:56:53 XXX kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table) Oct 06 09:56:53 XXX kernel: integrity: Loaded X.509 cert 'Fedora Secure Boot CA: XXX' Oct 06 09:56:53 XXX kernel: Loading compiled-in module X.509 certificates Oct 06 09:56:53 XXX kernel: Loaded X.509 cert 'Fedora kernel signing key: XXX' Oct 06 09:57:26 XXX kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database Oct 06 09:57:26 XXX kernel: Loaded X.509 cert 'sforshee: XXX'
Still present for me on Fedora 39 and latest kernel 6.5.11-300.fc39.x86_64. I can confirm this was not happening few kernel versions back. 6.5 was probably the breaking point for me too, can't really test it now.
Fresh install of f39 on a Dell system has similar messages with 6.6.2-201.fc39.x86_64. The system started with F36 and was updated to 37 and 38.
Marking as regression as previous releases didn't show this message
Hi, Thank you for filing the bug report! I've sent a patch [1] to address this issue. I wonder if I can have your first name and family name as one review feedback requests it to be included in the "Reported-by" field. [1] https://lore.kernel.org/lkml/39e5612eb2d4dea2759310ccce39c1ad40b5388f.camel@linux.ibm.com/T/
Coiby did the fix land in mainstream? Is it already included in Fedora rawhide?
Hi, same problem in RHEL9.3, kernel-5.14.0-362.18.1.el9_3.x86_64
(In reply to Sandro Bonazzola from comment #7) > Coiby did the fix land in mainstream? Is it already included in Fedora > rawhide? It did not, it has not landed in linux-next yet. Once it does, I can backport it to stable Fedora.
i
Im not good at english, but i know how to solve this problem. At use Ima/Evm, I get this problem In \linux-4.14.98\security\integrity\Kconfig, I read this: config INTEGRITY_TRUSTED_KEYRING bool "Require all keys on the integrity keyrings be signed" depends on SYSTEM_TRUSTED_KEYRING depends on INTEGRITY_ASYMMETRIC_KEYS default y help This option requires that all keys added to the .ima and .evm keyrings be signed by a key on the system trusted keyring. In linux-4.14.98\certs\Kconfig, I read this: config SYSTEM_TRUSTED_KEYRING bool "Provide system-wide ring of trusted keys" depends on KEYS depends on ASYMMETRIC_KEY_TYPE help Provide a system keyring to which trusted keys can be added. Keys in the keyring are considered to be trusted. Keys may be added at will by the kernel from compiled-in data and from hardware key stores, but userspace may only add extra keys if those keys can be verified by keys already in the keyring. Keys in this keyring are used by module signature checking. config SYSTEM_TRUSTED_KEYS string "Additional X.509 keys for default system keyring" depends on SYSTEM_TRUSTED_KEYRING help If set, this option should be the filename of a PEM-formatted file containing trusted X.509 certificates to be included in the default system keyring. Any certificate used for module signing is implicitly also trusted. NOTE: If you previously provided keys for the system keyring in the form of DER-encoded *.x509 files in the top-level build directory, those are no longer used. You will need to set this option instead. So, I recompile My kernel, Add SYSTEM_TRUSTED_KEYS(Additional X.509 keys for default system keyring),It is depend on asymmetric key pares, In compile(not run). Then use trused.crt sign x509_ima.der(/etc/x509_ima.der). [ 3.610235] Loaded X.509 cert 'Test modsign key: fdf65914e66cdecee66a7370fd8f0f6b4919eb9f'(trusted.crt) [ 3.765478] integrity: Loaded X.509 cert 'Test modsign key: b543dd61c701894d8692b78f1e0eabc7c6fa1f52': /etc/keys/x509_ima.der
(In reply to Sandro Bonazzola from comment #7) > Coiby did the fix land in mainstream? Is it already included in Fedora > rawhide? No, v2 [2] is still waiting for the maintainer to pick it up. [2] https://lore.kernel.org/lkml/39e5612eb2d4dea2759310ccce39c1ad40b5388f.camel@linux.ibm.com/T/#md1bddae1dd79f41b3a2460467f1aea774956fb9d
(In reply to xzk from comment #11) > Im not good at english, but i know how to solve this problem. At use > Ima/Evm, I get this problem > In \linux-4.14.98\security\integrity\Kconfig, I read this: > ... > config SYSTEM_TRUSTED_KEYS > string "Additional X.509 keys for default system keyring" > depends on SYSTEM_TRUSTED_KEYRING > help > If set, this option should be the filename of a PEM-formatted file > containing trusted X.509 certificates to be included in the default > system keyring. Any certificate used for module signing is implicitly > also trusted. > > NOTE: If you previously provided keys for the system keyring in the > form of DER-encoded *.x509 files in the top-level build directory, > those are no longer used. You will need to set this option instead. > > So, I recompile My kernel, Add SYSTEM_TRUSTED_KEYS(Additional X.509 keys for > default system keyring),It is depend on asymmetric key pares, In compile(not > run). Then use trused.crt sign x509_ima.der(/etc/x509_ima.der). > [ 3.610235] Loaded X.509 cert 'Test modsign key: > fdf65914e66cdecee66a7370fd8f0f6b4919eb9f'(trusted.crt) > [ 3.765478] integrity: Loaded X.509 cert 'Test modsign key: > b543dd61c701894d8692b78f1e0eabc7c6fa1f52': /etc/keys/x509_ima.der Thanks for sharing your thought! Using the SYSTEM_TRUSTED_KEYS config option is one way to load IMA certs but it's unrelated to this bug.
I can confirm this issue has been revolved with the release of 6.8.0-63.fc41.x86_64.
Will this be backported to RHEL?
(In reply to Leon Fauster from comment #15) > Will this be backported to RHEL? Yes, it will.