UEFI Secure boot is a verification mechanism, it can make sure that code launched is trusted by firmware. So Secure boot is designed to prevent malicious code being loaded and executed early at the boot stage.
Previously, kernel prevents unsigned kernel images from being loaded with kexec_file_load(). But now, kernel has evolved, the kexec_file_load() syscall checks for a valid signature of the kernel image if there is a signature(It must be valid). In addition, the images can still be loaded without a valid signature.
Currently, kernel enables the options KEXEC_SIG and KEXEC_BZIMAGE_VERIFY _SIG on x86_64 by default, it can cover signed or unsigned kernel images and allow to load them, please refer to the following form.
.-----------------------------------------------------------------------. | . | UEFI(signed) | non UEFI(unsigned) | | . types |-----------------------|------------------------| | . | | non | | | | . |secure boot|secure boot| prev | now | | options . |-----------|-----------| | | | . | prev| now | prev| now | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | succ | fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG is not set | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | succ | succ | |not set | | | | | | | ----------------------------------------------------------------------- Note: [1] 'prev': Without this patch [2] 'now': With this patch
So, it's time for switching to the kexec_file_load() syscall on x86_64 for kexec-tools.
Signed-off-by: Lianbo Jiang lijiang@redhat.com --- dracut-early-kdump.sh | 4 ++-- kdump-lib.sh | 31 +++++++++++-------------------- kdumpctl | 10 ++++------ 3 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..bfb923d6efa1 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -43,8 +43,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 use_kexec_file_load; 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..5b6684992553 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,30 +589,21 @@ 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. +# Currently, Secure Boot is only used on x86_64 and kernel enabled the +# kexec_file_load() on x86_64 by default. +# In addition, kernel also enables the option KEXEC_SIG, which makes the +# kexec_file_load() syscall checks for a valid signature of the kernel +# image if there is a signature(It must be valid). And the images can +# still be loaded without a valid signature. So let kexec-tools change +# as well. # -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() +use_kexec_file_load() { - local secure_boot_file setup_mode_file - local secure_boot_byte setup_mode_byte + local arch_name=`uname -m`
- 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 + if [ "$arch_name" == "x86_64" ]; then + return 0 fi
return 1 diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..d1c987773cf9 100755 --- a/kdumpctl +++ b/kdumpctl @@ -678,11 +678,9 @@ 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." + # On x86_64 machine, lets use kexec file based syscall by default. + if use_kexec_file_load; then + echo "Using kexec file based syscall." KEXEC_ARGS="$KEXEC_ARGS -s" fi
@@ -1162,7 +1160,7 @@ stop_fadump()
stop_kdump() { - if is_secure_boot_enforced; then + if use_kexec_file_load; then $KEXEC -s -p -u else $KEXEC -p -u
On Tue, Dec 3, 2019 at 3:11 PM Lianbo Jiang lijiang@redhat.com wrote:
UEFI Secure boot is a verification mechanism, it can make sure that code launched is trusted by firmware. So Secure boot is designed to prevent malicious code being loaded and executed early at the boot stage.
Previously, kernel prevents unsigned kernel images from being loaded with kexec_file_load(). But now, kernel has evolved, the kexec_file_load() syscall checks for a valid signature of the kernel image if there is a signature(It must be valid). In addition, the images can still be loaded without a valid signature.
Currently, kernel enables the options KEXEC_SIG and KEXEC_BZIMAGE_VERIFY _SIG on x86_64 by default, it can cover signed or unsigned kernel images and allow to load them, please refer to the following form.
.-----------------------------------------------------------------------. | . | UEFI(signed) | non UEFI(unsigned) | | . types |-----------------------|------------------------| | . | | non | | | | . |secure boot|secure boot| prev | now | | options . |-----------|-----------| | | | . | prev| now | prev| now | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | succ | fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG is not set | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | succ | succ | |not set | | | | | | |
Note: [1] 'prev': Without this patch [2] 'now': With this patch
So, it's time for switching to the kexec_file_load() syscall on x86_64 for kexec-tools.
Signed-off-by: Lianbo Jiang lijiang@redhat.com
dracut-early-kdump.sh | 4 ++-- kdump-lib.sh | 31 +++++++++++-------------------- kdumpctl | 10 ++++------ 3 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..bfb923d6efa1 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -43,8 +43,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 use_kexec_file_load; 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..5b6684992553 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,30 +589,21 @@ 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. +# Currently, Secure Boot is only used on x86_64 and kernel enabled the +# kexec_file_load() on x86_64 by default. +# In addition, kernel also enables the option KEXEC_SIG, which makes the +# kexec_file_load() syscall checks for a valid signature of the kernel +# image if there is a signature(It must be valid). And the images can +# still be loaded without a valid signature. So let kexec-tools change +# as well. # -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() +use_kexec_file_load() {
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- local arch_name=`uname -m`
- 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
if [ "$arch_name" == "x86_64" ]; then
return 0
fi
return 1
diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..d1c987773cf9 100755 --- a/kdumpctl +++ b/kdumpctl @@ -678,11 +678,9 @@ 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."
# On x86_64 machine, lets use kexec file based syscall by default.
if use_kexec_file_load; then
echo "Using kexec file based syscall." KEXEC_ARGS="$KEXEC_ARGS -s" fi
@@ -1162,7 +1160,7 @@ stop_fadump()
stop_kdump() {
if is_secure_boot_enforced; then
if use_kexec_file_load; then $KEXEC -s -p -u else $KEXEC -p -u
-- 2.17.1
Hi Lianbo, thank a lot for your work! And the test result table is extremely helpful!
But one thing I'm a bit confused, is that "UEFI(signed)" vs "non UEFI(unsigned)", did you mean "boot and kexec load a signed kernel" vs "boot and kexec an unsigned kernel on non-UEFI system"? Will things still work if you boot and kexec load a signed kernel on non-UEFI system? As rpm packaged kernel image is usually always signed on bot UEFI and non-UEFI system.
And one another concern, did you test with upstream kernel or fedora kernel? fedora kernel applies some custom patches, and this kexec-tools package is maintained for fedora.
And will it be a good idea to use non-file load as a fallback for non-secure boot case (and print a warning etc...)? That may cover some more cases.
-- Best Regards, Kairui Song
在 2019年12月11日 13:48, Kairui Song 写道:
On Tue, Dec 3, 2019 at 3:11 PM Lianbo Jiang lijiang@redhat.com wrote:
UEFI Secure boot is a verification mechanism, it can make sure that code launched is trusted by firmware. So Secure boot is designed to prevent malicious code being loaded and executed early at the boot stage.
Previously, kernel prevents unsigned kernel images from being loaded with kexec_file_load(). But now, kernel has evolved, the kexec_file_load() syscall checks for a valid signature of the kernel image if there is a signature(It must be valid). In addition, the images can still be loaded without a valid signature.
Currently, kernel enables the options KEXEC_SIG and KEXEC_BZIMAGE_VERIFY _SIG on x86_64 by default, it can cover signed or unsigned kernel images and allow to load them, please refer to the following form.
.-----------------------------------------------------------------------. | . | UEFI(signed) | non UEFI(unsigned) | | . types |-----------------------|------------------------| | . | | non | | | | . |secure boot|secure boot| prev | now | | options . |-----------|-----------| | | | . | prev| now | prev| now | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | succ | fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG is not set | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | succ | succ | |not set | | | | | | |
Note: [1] 'prev': Without this patch [2] 'now': With this patch
So, it's time for switching to the kexec_file_load() syscall on x86_64 for kexec-tools.
Signed-off-by: Lianbo Jiang lijiang@redhat.com
dracut-early-kdump.sh | 4 ++-- kdump-lib.sh | 31 +++++++++++-------------------- kdumpctl | 10 ++++------ 3 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..bfb923d6efa1 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -43,8 +43,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 use_kexec_file_load; 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..5b6684992553 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,30 +589,21 @@ 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. +# Currently, Secure Boot is only used on x86_64 and kernel enabled the +# kexec_file_load() on x86_64 by default. +# In addition, kernel also enables the option KEXEC_SIG, which makes the +# kexec_file_load() syscall checks for a valid signature of the kernel +# image if there is a signature(It must be valid). And the images can +# still be loaded without a valid signature. So let kexec-tools change +# as well. # -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() +use_kexec_file_load() {
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- local arch_name=`uname -m`
- 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
if [ "$arch_name" == "x86_64" ]; then
return 0
fi
return 1
diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..d1c987773cf9 100755 --- a/kdumpctl +++ b/kdumpctl @@ -678,11 +678,9 @@ 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."
# On x86_64 machine, lets use kexec file based syscall by default.
if use_kexec_file_load; then
echo "Using kexec file based syscall." KEXEC_ARGS="$KEXEC_ARGS -s" fi
@@ -1162,7 +1160,7 @@ stop_fadump()
stop_kdump() {
if is_secure_boot_enforced; then
if use_kexec_file_load; then $KEXEC -s -p -u else $KEXEC -p -u
-- 2.17.1
Hi Lianbo, thank a lot for your work! And the test result table is extremely helpful!
Thanks for your comment.
But one thing I'm a bit confused, is that "UEFI(signed)" vs "non UEFI(unsigned)", did you mean "boot and kexec load a signed kernel" vs "boot and kexec an unsigned kernel on non-UEFI system"? Will things
Yes. Maybe I should improve the form as follow: .-------------------------------------------------------------------------. | . | UEFI(signed) | non UEFI(signed|unsigned)| | . types |-----------------------|--------------------------| | . | | non | | | | . |secure boot|secure boot| prev | now | | options . |-----------|-----------| | | | . | prev| now | prev| now | | | |----------------------|-----|-----|-----|-----|------------|-------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|------------|-------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|------------|-------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | succ | fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|------------|-------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|------------|-------------| |KEXEC_SIG is not set | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | succ | succ | |not set | | | | | | | -------------------------------------------------------------------------
still work if you boot and kexec load a signed kernel on non-UEFI
Yes. On non UEFI machine, the signed kernel and unsigned kernel are the same test result.
system? As rpm packaged kernel image is usually always signed on bot UEFI and non-UEFI system.
And one another concern, did you test with upstream kernel or fedora
kernel? fedora kernel applies some custom patches, and this
Sure. The fedora and upstream kernel are also the same test result, but when test fails, only there are a bit differences about kernel log, after all, the fedora is not exactly the same as the upstream kernel code. Please refer to the kernel/ kexec_file.c and check the return value of arch_kexec_kernel_verify_sig().
kexec-tools package is maintained for fedora.
And will it be a good idea to use non-file load as a fallback for non-secure boot case (and print a warning etc...)? That may cover some more cases.
Sounds good, but as you known, the released kernel image(rpm package) always use the following configuration option by default:
------------------------------------------------------------------------- |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | -------------------------------------------------------------------------
So, the kexec_file_load() will always load successfully for default options. And this is simple. Unless someone wants to make the kbuild(configuration) options test just like above form.
Any thoughts?
Thanks. Lianbo
-- Best Regards, Kairui Song
Talked with Lianbo in bluejeans, we finally worked together to rewrite the log as below:
~~~~~~~~~~ UEFI Secure boot is a a signatiure verification mechanism, is 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 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 chance to be allowed to be loaded under some conditions.
commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
And in the current fedora and RHEL, CONFIG_KEXEC_SIG_FORCE is not set, only 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 Secute-boot platforms and legacy platforms.
Hence, in this patch, if on x86, lets use the kexec_file_load() only. See if anything wrong happened in this case, in Fedora firstly for the time being. ~~~~~~~~~~
For the table, change to two columns for signed and unsigned kernel image. Then in each kind of kernel, singed or unsiged, check on two kinds of platform, Secure boot or Legacy system. Here Legacy system includes the non-Secure boot and non -UEFI platforms in the old form Lianbo listed.
Any idea, feel free to add comment.
And for the fallback kairui mentioned, I think no need to support in Fedora. Just give kexec_file_load() a full firepower shoot firstly, let's see what's going to happen.
.-----------------------------------------------------------------------. | . | signed kernel | unsigned kernel | | . types |-----------------------|------------------------| | . | | | | | | . |Secure boot| Legacy |Secure boot| Legacy | | options . |-----------|-----------|-----------|------------| | . | prev| now | prev| now |prev | now |prev | now | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | |
.-----------------------------------------------------------------------. | . | UEFI(signed) | non UEFI(unsigned) | | . types |-----------------------|------------------------| | . | | non | | | | . |secure boot|secure boot| prev | now | | options . |-----------|-----------| | | | . | prev| now | prev| now | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set |succ |succ |succ |succ | succ | succ | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y |succ |succ |succ |fail | succ | fail | |BZIMAGE_VERIFY_SIG=y | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG=y | | | | | | | |SIG_FORCE=y | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail | succ | fail | |not set | | | | | | | |----------------------|-----|-----|-----|-----|-----------|------------| |KEXEC_SIG is not set | | | | | | | |SIG_FORCE is not set | | | | | | | |BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ | succ | succ | |not set | | | | | | |
Note: [1] 'prev': Without this patch [2] 'now': With this patch
So, it's time for switching to the kexec_file_load() syscall on x86_64 for kexec-tools.
Signed-off-by: Lianbo Jiang lijiang@redhat.com
dracut-early-kdump.sh | 4 ++-- kdump-lib.sh | 31 +++++++++++-------------------- kdumpctl | 10 ++++------ 3 files changed, 17 insertions(+), 28 deletions(-)
diff --git a/dracut-early-kdump.sh b/dracut-early-kdump.sh index 69a34eb996cd..bfb923d6efa1 100755 --- a/dracut-early-kdump.sh +++ b/dracut-early-kdump.sh @@ -43,8 +43,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 use_kexec_file_load; 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..5b6684992553 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -589,30 +589,21 @@ 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. +# Currently, Secure Boot is only used on x86_64 and kernel enabled the +# kexec_file_load() on x86_64 by default. +# In addition, kernel also enables the option KEXEC_SIG, which makes the +# kexec_file_load() syscall checks for a valid signature of the kernel +# image if there is a signature(It must be valid). And the images can +# still be loaded without a valid signature. So let kexec-tools change +# as well. # -# Assume efivars is mounted at /sys/firmware/efi/efivars. -is_secure_boot_enforced() +use_kexec_file_load() {
- local secure_boot_file setup_mode_file
- local secure_boot_byte setup_mode_byte
- local arch_name=`uname -m`
- 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
if [ "$arch_name" == "x86_64" ]; then
return 0
fi
return 1
diff --git a/kdumpctl b/kdumpctl index 2d21a416deb1..d1c987773cf9 100755 --- a/kdumpctl +++ b/kdumpctl @@ -678,11 +678,9 @@ 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."
- # On x86_64 machine, lets use kexec file based syscall by default.
- if use_kexec_file_load; then
KEXEC_ARGS="$KEXEC_ARGS -s" fiecho "Using kexec file based syscall."
@@ -1162,7 +1160,7 @@ stop_fadump()
stop_kdump() {
- if is_secure_boot_enforced; then
- if use_kexec_file_load; then $KEXEC -s -p -u else $KEXEC -p -u
-- 2.17.1 _______________________________________________ kexec mailing list -- kexec@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org