UEFI Secure boot is a signature verification mechanism, designed to prevent malicious code being loaded and executed at the early boot stage. This makes sure that code executed is trusted by firmware.
Previously, with kexec_file_load() interface, kernel prevents unsigned kernel image from being loaded if secure boot is enabled. So kdump will detect whether secure boot is enabled firstly, then decide which interface is chosen to execute, kexec_load() or kexec_file_load(). Otherwise unsigned kernel loading will fail if secure boot enabled, and kexec_file_load() is entered.
Now, the implementation of kexec_file_load() is adjusted in below commit. With this change, if CONFIG_KEXEC_SIG_FORCE is not set, unsigned kernel still has a chance to be allowed to load under some conditions.
commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
And in the current Fedora, the CONFIG_KEXEC_SIG_FORCE is not set, only the CONFIG_KEXEC_SIG and CONFIG_BZIMAGE_VERIFY_SIG are set on x86_64 by default. It's time to spread kexec_file_load() onto all systems of x86_64, including Secure-boot platforms and legacy platforms. Please refer to the following form.
.----------------------------------------------------------------------. | . | signed kernel | unsigned kernel | | . types |-----------------------|-----------------------| | . |Secure boot| Legacy |Secure boot| Legacy | | . |-----------|-----------|-----------|-----------| | options . | prev| now | prev| now | | | prev| now | | . |(file|(file|(only|(file| prev| now |(only|(file| | . |load)|load)|load)|load)| | |load)|load)| |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | X | X |succ |succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE is not set | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | X | X |succ |fail | |not set | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | X | X |succ |fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE=y | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | X | X |succ |fail | |not set | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG is not set | | | | | | | | | |SIG_FORCE is not set | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | X | X |succ |succ | |not set | | | | | | | | | ---------------------------------------------------------------------- Note: [1] The 'X' indicates that the 1st kernel(unsigned) can not boot when the Secure boot is enabled.
Hence, in this patch, if on x86_64, let's use the kexec_file_load() only. See if anything wrong happened in this case, in Fedora firstly for the time being.
Signed-off-by: Lianbo Jiang lijiang@redhat.com --- Changes since v1: [1] Improve patch log. [2] Change the is_secure_boot_enforced() to use_kexec_file_load(). [3] Aamend the code comment. [4] Add the form for the kbuild options.
Changes since v2: [1] Improve patch log. [2] Also rewrite the form for the kbuild options.
Changes since v3: [1] Improve patch log. [2] Display an error message and ask user to try kexec_load() once the kexec_file_load() failed.
Changes since v4: [1] Improve patch log. [2] Remove the unused is_secure_boot_enforced() from kdump-lib.sh. [3] Add a new option 'KDUMP_FILE_LOAD', which provides a chance for user to choose the kexec load or kexec file load. And use the kexec file load by default.
Changes since v5: [1] Improve the code comment for the kdump.sysconfig.x86_64, also say that the "on" is the only valid value to enable the kexec file load, anything else is equal to the "off".
dracut-early-kdump.sh | 5 +++-- kdump-lib.sh | 29 ----------------------------- kdump.sysconfig.x86_64 | 6 ++++++ kdumpctl | 13 +++++++------ 4 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..6788a6b83431 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -2,6 +2,7 @@
KEXEC=/sbin/kexec standard_kexec_args="-p" +KDUMP_FILE_LOAD=""
EARLY_KDUMP_INITRD="" EARLY_KDUMP_KERNEL="" @@ -43,8 +44,8 @@ early_kdump_load()
EARLY_KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}")
- if is_secure_boot_enforced; then - echo "Secure Boot is enabled. Using kexec file based syscall." + if [ "$KDUMP_FILE_LOAD" == "on" ]; then + echo "Using kexec file based syscall." EARLY_KEXEC_ARGS="$EARLY_KEXEC_ARGS -s" fi
diff --git a/kdump-lib.sh b/kdump-lib.sh index f393c76b9cbb..a79c1a70cc07 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,35 +589,6 @@ need_64bit_headers() print (strtonum("0x" r[2]) > strtonum("0xffffffff")); }'` }
-# Check if secure boot is being enforced. -# -# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and -# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four -# bytes are the attributes associated with the variable and can safely be -# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot -# is 1 and SetupMode is 0, then secure boot is being enforced. -# -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() -{ - local secure_boot_file setup_mode_file - local secure_boot_byte setup_mode_byte - - secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null) - setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null) - - if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then - secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5) - setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5) - - if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then - return 0 - fi - fi - - return 1 -} - # # prepare_kexec_args <kexec args> # This function prepares kexec argument. diff --git a/kdump.sysconfig.x86_64 b/kdump.sysconfig.x86_64 index 09de2ebe798e..7894ccc840b2 100644 --- a/kdump.sysconfig.x86_64 +++ b/kdump.sysconfig.x86_64 @@ -38,3 +38,9 @@ KDUMP_IMG="vmlinuz"
#What is the images extension. Relocatable kernels don't have one KDUMP_IMG_EXT="" + +# Using kexec file based syscall by default +# +# Here, the "on" is the only valid value to enable the kexec file load and +# anything else is equal to the "off"(disable). +KDUMP_FILE_LOAD="on" diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..97fe54110447 100755 --- a/kdumpctl +++ b/kdumpctl @@ -4,6 +4,7 @@ KEXEC=/sbin/kexec KDUMP_KERNELVER="" KDUMP_COMMANDLINE="" KEXEC_ARGS="" +KDUMP_FILE_LOAD="" KDUMP_CONFIG_FILE="/etc/kdump.conf" MKDUMPRD="/sbin/mkdumprd -f" DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt" @@ -678,11 +679,8 @@ load_kdump() KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}") KDUMP_COMMANDLINE=$(prepare_cmdline "${KDUMP_COMMANDLINE}" "${KDUMP_COMMANDLINE_REMOVE}" "${KDUMP_COMMANDLINE_APPEND}")
- # For secureboot enabled machines, use new kexec file based syscall. - # Old syscall will always fail as it does not have capability to - # to kernel signature verification. - if is_secure_boot_enforced; then - echo "Secure Boot is enabled. Using kexec file based syscall." + if [ "$KDUMP_FILE_LOAD" == "on" ]; then + echo "Using kexec file based syscall." KEXEC_ARGS="$KEXEC_ARGS -s" fi
@@ -694,6 +692,9 @@ load_kdump() return 0 else echo "kexec: failed to load kdump kernel" >&2 + if [ "$KDUMP_FILE_LOAD" == "on" ]; then + echo "kexec_file_load() failed, please try kexec_load()" >&2 + fi return 1 fi } @@ -1162,7 +1163,7 @@ stop_fadump()
stop_kdump() { - if is_secure_boot_enforced; then + if [ "$KDUMP_FILE_LOAD" == "on" ]; then $KEXEC -s -p -u else $KEXEC -p -u
On Thu, Jan 16, 2020 at 1:48 PM Lianbo Jiang lijiang@redhat.com wrote:
UEFI Secure boot is a signature verification mechanism, designed to prevent malicious code being loaded and executed at the early boot stage. This makes sure that code executed is trusted by firmware.
Previously, with kexec_file_load() interface, kernel prevents unsigned kernel image from being loaded if secure boot is enabled. So kdump will detect whether secure boot is enabled firstly, then decide which interface is chosen to execute, kexec_load() or kexec_file_load(). Otherwise unsigned kernel loading will fail if secure boot enabled, and kexec_file_load() is entered.
Now, the implementation of kexec_file_load() is adjusted in below commit. With this change, if CONFIG_KEXEC_SIG_FORCE is not set, unsigned kernel still has a chance to be allowed to load under some conditions.
commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
And in the current Fedora, the CONFIG_KEXEC_SIG_FORCE is not set, only the CONFIG_KEXEC_SIG and CONFIG_BZIMAGE_VERIFY_SIG are set on x86_64 by default. It's time to spread kexec_file_load() onto all systems of x86_64, including Secure-boot platforms and legacy platforms. Please refer to the following form.
.----------------------------------------------------------------------. | . | signed kernel | unsigned kernel | | . types |-----------------------|-----------------------| | . |Secure boot| Legacy |Secure boot| Legacy | | . |-----------|-----------|-----------|-----------| | options . | prev| now | prev| now | | | prev| now | | . |(file|(file|(only|(file| prev| now |(only|(file| | . |load)|load)|load)|load)| | |load)|load)| |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | X | X |succ |succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE is not set | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | X | X |succ |fail | |not set | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | X | X |succ |fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG=y | | | | | | | | | |SIG_FORCE=y | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | X | X |succ |fail | |not set | | | | | | | | | |----------------------|-----|-----|-----|-----|-----|-----|-----|-----| |KEXEC_SIG is not set | | | | | | | | | |SIG_FORCE is not set | | | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | X | X |succ |succ | |not set | | | | | | | | |
Note: [1] The 'X' indicates that the 1st kernel(unsigned) can not boot when the Secure boot is enabled.
Hence, in this patch, if on x86_64, let's use the kexec_file_load() only. See if anything wrong happened in this case, in Fedora firstly for the time being.
Signed-off-by: Lianbo Jiang lijiang@redhat.com
Changes since v1: [1] Improve patch log. [2] Change the is_secure_boot_enforced() to use_kexec_file_load(). [3] Aamend the code comment. [4] Add the form for the kbuild options.
Changes since v2: [1] Improve patch log. [2] Also rewrite the form for the kbuild options.
Changes since v3: [1] Improve patch log. [2] Display an error message and ask user to try kexec_load() once the kexec_file_load() failed.
Changes since v4: [1] Improve patch log. [2] Remove the unused is_secure_boot_enforced() from kdump-lib.sh. [3] Add a new option 'KDUMP_FILE_LOAD', which provides a chance for user to choose the kexec load or kexec file load. And use the kexec file load by default.
Changes since v5: [1] Improve the code comment for the kdump.sysconfig.x86_64, also say that the "on" is the only valid value to enable the kexec file load, anything else is equal to the "off".
dracut-early-kdump.sh | 5 +++-- kdump-lib.sh | 29 ----------------------------- kdump.sysconfig.x86_64 | 6 ++++++ kdumpctl | 13 +++++++------ 4 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..6788a6b83431 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -2,6 +2,7 @@
KEXEC=/sbin/kexec standard_kexec_args="-p" +KDUMP_FILE_LOAD=""
EARLY_KDUMP_INITRD="" EARLY_KDUMP_KERNEL="" @@ -43,8 +44,8 @@ early_kdump_load()
EARLY_KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}")
- if is_secure_boot_enforced; then
echo "Secure Boot is enabled. Using kexec file based syscall."
- if [ "$KDUMP_FILE_LOAD" == "on" ]; then
fiecho "Using kexec file based syscall." EARLY_KEXEC_ARGS="$EARLY_KEXEC_ARGS -s"
diff --git a/kdump-lib.sh b/kdump-lib.sh index f393c76b9cbb..a79c1a70cc07 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,35 +589,6 @@ need_64bit_headers() print (strtonum("0x" r[2]) > strtonum("0xffffffff")); }'` }
-# Check if secure boot is being enforced. -# -# Per Peter Jones, we need check efivar SecureBoot-$(the UUID) and -# SetupMode-$(the UUID), they are both 5 bytes binary data. The first four -# bytes are the attributes associated with the variable and can safely be -# ignored, the last bytes are one-byte true-or-false variables. If SecureBoot -# is 1 and SetupMode is 0, then secure boot is being enforced. -# -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() -{
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- secure_boot_file=$(find /sys/firmware/efi/efivars -name SecureBoot-* 2>/dev/null)
- setup_mode_file=$(find /sys/firmware/efi/efivars -name SetupMode-* 2>/dev/null)
- if [ -f "$secure_boot_file" ] && [ -f "$setup_mode_file" ]; then
secure_boot_byte=$(hexdump -v -e '/1 "%d\ "' $secure_boot_file|cut -d' ' -f 5)
setup_mode_byte=$(hexdump -v -e '/1 "%d\ "' $setup_mode_file|cut -d' ' -f 5)
if [ "$secure_boot_byte" = "1" ] && [ "$setup_mode_byte" = "0" ]; then
return 0
fi
- fi
- return 1
-}
# # prepare_kexec_args <kexec args> # This function prepares kexec argument. diff --git a/kdump.sysconfig.x86_64 b/kdump.sysconfig.x86_64 index 09de2ebe798e..7894ccc840b2 100644 --- a/kdump.sysconfig.x86_64 +++ b/kdump.sysconfig.x86_64 @@ -38,3 +38,9 @@ KDUMP_IMG="vmlinuz"
#What is the images extension. Relocatable kernels don't have one KDUMP_IMG_EXT=""
+# Using kexec file based syscall by default +# +# Here, the "on" is the only valid value to enable the kexec file load and +# anything else is equal to the "off"(disable). +KDUMP_FILE_LOAD="on" diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..97fe54110447 100755 --- a/kdumpctl +++ b/kdumpctl @@ -4,6 +4,7 @@ KEXEC=/sbin/kexec KDUMP_KERNELVER="" KDUMP_COMMANDLINE="" KEXEC_ARGS="" +KDUMP_FILE_LOAD="" KDUMP_CONFIG_FILE="/etc/kdump.conf" MKDUMPRD="/sbin/mkdumprd -f" DRACUT_MODULES_FILE="/usr/lib/dracut/modules.txt" @@ -678,11 +679,8 @@ load_kdump() KEXEC_ARGS=$(prepare_kexec_args "${KEXEC_ARGS}") KDUMP_COMMANDLINE=$(prepare_cmdline "${KDUMP_COMMANDLINE}" "${KDUMP_COMMANDLINE_REMOVE}" "${KDUMP_COMMANDLINE_APPEND}")
# For secureboot enabled machines, use new kexec file based syscall.
# Old syscall will always fail as it does not have capability to
# to kernel signature verification.
if is_secure_boot_enforced; then
echo "Secure Boot is enabled. Using kexec file based syscall."
if [ "$KDUMP_FILE_LOAD" == "on" ]; then
echo "Using kexec file based syscall." KEXEC_ARGS="$KEXEC_ARGS -s" fi
@@ -694,6 +692,9 @@ load_kdump() return 0 else echo "kexec: failed to load kdump kernel" >&2
if [ "$KDUMP_FILE_LOAD" == "on" ]; then
echo "kexec_file_load() failed, please try kexec_load()" >&2
fi return 1 fi
} @@ -1162,7 +1163,7 @@ stop_fadump()
stop_kdump() {
if is_secure_boot_enforced; then
if [ "$KDUMP_FILE_LOAD" == "on" ]; then $KEXEC -s -p -u else $KEXEC -p -u
-- 2.17.1
Hi Lianbo, thanks for the work, I think it looks good. On Fedora 31 I imported my custom signed key into Mok and everything works.
And an infomation for anyone want to try secure boot with Fedora 31, there is a shim bug that still haven't been fixed, so need to import the Mok key manually. Or both kexec_load and kexec_file_load will fail with default kernel.
Acked-by: Kairui Song kasong@redhat.com
-- Best Regards, Kairui Song
在 2020年02月06日 21:56, Kairui Song 写道:
And an infomation for anyone want to try secure boot with Fedora 31, there is a shim bug that still haven't been fixed, so need to import the Mok key manually. Or both kexec_load and kexec_file_load will fail with default kernel.
How did you reproduce the shim bug? I enrolled the key to the shim installation via the mokutil tool, but I didn't see any errors.
Thanks. Lianbo
On Fri, Feb 7, 2020 at 12:36 PM lijiang lijiang@redhat.com wrote:
在 2020年02月06日 21:56, Kairui Song 写道:
And an infomation for anyone want to try secure boot with Fedora 31, there is a shim bug that still haven't been fixed, so need to import the Mok key manually. Or both kexec_load and kexec_file_load will fail with default kernel.
How did you reproduce the shim bug? I enrolled the key to the shim installation via the mokutil tool, but I didn't see any errors.
Thanks. Lianbo
Hi Lianbo,
On my laptop, with secure boot enabled and firmware Mok Keyring is empty, Fedora 31 can boot, but neither kexec_load or kexec_file_load will work.
Fedora shim's signature is trusted by Microsoft Corporation UEFI CA which is part of stock keyring so it worked. But the kernel is signed by Fedora Secure Boot CA, it's included in shim, and shim should pass it to kernel via Mok keyring but it didn't.
The keyring on my machine before I import the Mok key manually: Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo Ltd.: ThinkPad Product CA 2012: 838b1f54c1550463f45f98700640f11069265949' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo UEFI CA 2014: 4b91a68732eaefdd2c8ffffc6b027ec3449e9c8f' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
There is a known bug that shim will skip passing Mok keyring if the firmware Mok keyring is empty, and after I import a custom Mok keyring manually, I can see shim passing the right kerying (notice Fedora Secure Boot CA get loaded):
Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo Ltd.: ThinkPad Product CA 2012: 838b1f54c1550463f45f98700640f11069265949' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo UEFI CA 2014: 4b91a68732eaefdd2c8ffffc6b027ec3449e9c8f' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:MokListRT Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'SomeOrg: Kairui Song: 866ba9a71803004ef4a1dc0a56995ba6e993c717' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:MokListRT Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'
This a shim bug and this patch works well, there is no workaround we can do for kexec-tools, we can only wait for shim to fix it.
在 2020年02月07日 14:15, Kairui Song 写道:
On Fri, Feb 7, 2020 at 12:36 PM lijiang lijiang@redhat.com wrote:
在 2020年02月06日 21:56, Kairui Song 写道:
And an infomation for anyone want to try secure boot with Fedora 31, there is a shim bug that still haven't been fixed, so need to import the Mok key manually. Or both kexec_load and kexec_file_load will fail with default kernel.
How did you reproduce the shim bug? I enrolled the key to the shim installation via the mokutil tool, but I didn't see any errors.
Thanks. Lianbo
Hi Lianbo,
On my laptop, with secure boot enabled and firmware Mok Keyring is empty, Fedora 31 can boot, but neither kexec_load or kexec_file_load will work.
Fedora shim's signature is trusted by Microsoft Corporation UEFI CA which is part of stock keyring so it worked. But the kernel is signed by Fedora Secure Boot CA, it's included in shim, and shim should pass it to kernel via Mok keyring but it didn't.
The keyring on my machine before I import the Mok key manually: Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo Ltd.: ThinkPad Product CA 2012: 838b1f54c1550463f45f98700640f11069265949' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo UEFI CA 2014: 4b91a68732eaefdd2c8ffffc6b027ec3449e9c8f' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 15:12:16 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
There is a known bug that shim will skip passing Mok keyring if the firmware Mok keyring is empty, and after I import a custom Mok keyring manually, I can see shim passing the right kerying (notice Fedora Secure Boot CA get loaded):
Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo Ltd.: ThinkPad Product CA 2012: 838b1f54c1550463f45f98700640f11069265949' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Lenovo UEFI CA 2014: 4b91a68732eaefdd2c8ffffc6b027ec3449e9c8f' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:db Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:MokListRT Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'SomeOrg: Kairui Song: 866ba9a71803004ef4a1dc0a56995ba6e993c717' Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loading X.509 certificate: UEFI:MokListRT Feb 06 22:15:46 kasong-rh-laptop kernel: integrity: Loaded X.509 cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42'
This a shim bug and this patch works well, there is no workaround we can do for kexec-tools, we can only wait for shim to fix it.
OK. Thanks for the explanation in detail.