Description of problem: $ kexec -s -l /boot/vmlinuz-4.15.6-300.fc27.x86_64 kexec_file_load failed: Required key not available Omitting the '-s' switch obviously results in Operation not permitted: $ kexec -l /boot/vmlinuz-4.15.6-300.fc27.x86_64 kexec_load failed: Operation not permitted Expected Result: kexec the specified kernel Version-Release number of selected component (if applicable): $ rpm -q kernel kexec-tools kernel-4.15.6-300.fc27.x86_64 kexec-tools-2.0.15-12.fc27.1.x86_64 How reproducible: reproduced on 2 systems with fresh fedora installations (secureboot enabled with custom platform key) Additional info: $ cat /proc/keys |grep keys 014d9b4a I------ 2 perm 1f0b0000 0 0 keyring .builtin_trusted_keys: 1 0b0a4d52 I------ 1 perm 1f0b0000 0 0 keyring .builtin_regdb_keys: 1 14650506 I------ 1 perm 1f0f0000 0 0 keyring .secondary_trusted_keys: 2 $ keyctl show %:.builtin_trusted_keys Keyring 21863242 ---lswrv 0 0 keyring: .builtin_trusted_keys 861972143 ---lswrv 0 0 \_ asymmetric: Fedora kernel signing key: be1a4ad639e889cd5f3a93baef1020c030702902 $ keyctl show %:.secondary_trusted_keys Keyring 342164742 ---lswrv 0 0 keyring: .secondary_trusted_keys 21863242 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 861972143 ---lswrv 0 0 | \_ asymmetric: Fedora kernel signing key: be1a4ad639e889cd5f3a93baef1020c030702902 165535613 ---lswrv 0 0 \_ asymmetric: sakaki's kernel-signing key: 454e8b07338c50085ae60be0fcce5eef21804dc4 $ dmesg | grep -i secure [ 0.000000] secureboot: Secure boot enabled [ 0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7 $ dmesg | grep -i cert [ 1.095762] Loading compiled-in X.509 certificates [ 1.131181] Loaded X.509 cert 'Fedora kernel signing key: be1a4ad639e889cd5f3a93baef1020c030702902' [ 1.131461] Loaded UEFI:db cert 'sakaki's kernel-signing key: 454e8b07338c50085ae60be0fcce5eef21804dc4' linked to secondary sys keyring
I have also reproduced this with the default secure boot keys (the report above was with a custom PK installed): $ keyctl show %:.secondary_trusted_keys Keyring 385126999 ---lswrv 0 0 keyring: .secondary_trusted_keys 145791242 ---lswrv 0 0 \_ keyring: .builtin_trusted_keys 94839686 ---lswrv 0 0 | \_ asymmetric: Fedora kernel signing key: be1a4ad639e889cd5f3a93baef1020c030702902 1041585827 ---lswrv 0 0 \_ asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42 2017816 ---lswrv 0 0 \_ asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4 162878868 ---lswrv 0 0 \_ asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53 $ dmesg |grep cert [ 1.091382] Loading compiled-in X.509 certificates [ 1.124311] Loaded X.509 cert 'Fedora kernel signing key: be1a4ad639e889cd5f3a93baef1020c030702902' [ 1.124440] Loaded UEFI:db cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' linked to secondary sys keyring [ 1.124460] Loaded UEFI:db cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to secondary sys keyring [ 1.124698] Loaded UEFI:MokListRT cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to secondary sys keyring $ kexec -s -l /boot/vmlinuz-4.15.6-300.fc27.x86_64 kexec_file_load failed: Required key not available
I am no kernel developer, but maybe this helps: in arch/x86/kernel/kexec-bzimage64.c, verify_pefile_signature is called to verify the signature like this: verify_pefile_signature(kernel, kernel_len, NULL, VERIFYING_KEXEC_PE_SIGNATURE); int verify_pefile_signature(const void *pebuf, unsigned pelen, struct key *trusted_keys, enum key_being_used_for usage) Notice, trusted_keys is being set to NULL. verify_pefile_signature then calls verify_pkcs7_signature passing on the aforementioned NULL as trusted_keys. verify_pkcs7_signature: * @trusted_keys: Trusted keys to use (NULL for builtin trusted keys only, * (void *)1UL for all trusted keys). if (!trusted_keys) { trusted_keys = builtin_trusted_keys; } else if (trusted_keys == (void *)1UL) { #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING trusted_keys = secondary_trusted_keys; #else trusted_keys = builtin_trusted_keys; #endif } The kernel is signed with the "Fedora Secure Boot CA" key: $ /usr/local/bin/sbverify --list /boot/vmlinuz-4.15.6-300.fc27.x86_64 image signature issuers: - /CN=Fedora Secure Boot CA image signature certificates: - subject: /CN=Fedora Secure Boot Signer issuer: /CN=Fedora Secure Boot CA - subject: /CN=Fedora Secure Boot CA issuer: /CN=Fedora Secure Boot CA As the kernel is validated against the builtin_trusted_keys only, while the "Fedora Secure Boot CA" key actually resides in the secondary_trusted_keys, the validation fails. Assuming all this is correct, I would propose passing (void *)1UL instead of NULL as trusted_keys to verify_pefile_signature.
Same on F28.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
Same on F28 with kernel 4.17.7-200.fc28
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.18.10-300.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
This is actually a bug with shim 15, where it is not copying over the MokList to MokListRT if the former is empty, while it should still copy the embedded vendor certificates. An upstream patch for this is available, so hopefully it should get fixed sometime soon.
@Patrick, no this bug was fixed in upstream with my patch "Fix kexec forbidding kernels signed with keys in the secondary keyring to boot" which was merged about 3 months ago. I dont't know what you are really can talking about, can you give a LKML reference? I'm pretty sure that it's a different bug though.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days