Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Adding a patch to fix this by retain the secure_boot flag in original kernel.
Signed-off-by: Dave Young dyoung@redhat.com --- kernel.spec | 2 ++ ...uefi-copy-secure_boot-flag-in-boot-params.patch | 30 ++++++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
diff --git a/kernel.spec b/kernel.spec index e91ef9d..469a2a2 100644 --- a/kernel.spec +++ b/kernel.spec @@ -587,6 +587,8 @@ Patch505: 0001-dm-fix-dm_merge_bvec-regression-on-32-bit-systems.patch #rhbz 1244511 Patch507: HID-chicony-Add-support-for-Acer-Aspire-Switch-12.patch
+Patch508: kexec-uefi-copy-secure_boot-flag-in-boot-params.patch + Patch904: kdbus.patch
# END OF PATCH DEFINITIONS diff --git a/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch new file mode 100644 index 0000000..e239ea9 --- /dev/null +++ b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch @@ -0,0 +1,30 @@ +From: Dave Young dyoung@redhat.com + +[PATCH] kexec/uefi: copy secure_boot flag in boot params across kexec reboot + +Kexec reboot in case secure boot being enabled does not keep the secure boot +mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. +In this state, the system is missing the protections provided by secure boot. + +Adding a patch to fix this by retain the secure_boot flag in original kernel. + +secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. +Fixing this issue by copying secure_boot flag across kexec reboot. + +Signed-off-by: Dave Young dyoung@redhat.com +--- + arch/x86/kernel/kexec-bzimage64.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c +index 9642b9b..0539ec7 100644 +--- a/arch/x86/kernel/kexec-bzimage64.c ++++ b/arch/x86/kernel/kexec-bzimage64.c +@@ -178,6 +178,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr, + if (efi_enabled(EFI_OLD_MEMMAP)) + return 0; + ++ params->secure_boot = boot_params.secure_boot; + ei->efi_loader_signature = current_ei->efi_loader_signature; + ei->efi_systab = current_ei->efi_systab; + ei->efi_systab_hi = current_ei->efi_systab_hi;
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
I will add this patch regardless of that, but it seems like a good question to answer. Thanks!
josh
Adding a patch to fix this by retain the secure_boot flag in original kernel.
Signed-off-by: Dave Young dyoung@redhat.com
kernel.spec | 2 ++ ...uefi-copy-secure_boot-flag-in-boot-params.patch | 30 ++++++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
diff --git a/kernel.spec b/kernel.spec index e91ef9d..469a2a2 100644 --- a/kernel.spec +++ b/kernel.spec @@ -587,6 +587,8 @@ Patch505: 0001-dm-fix-dm_merge_bvec-regression-on-32-bit-systems.patch #rhbz 1244511 Patch507: HID-chicony-Add-support-for-Acer-Aspire-Switch-12.patch
+Patch508: kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
Patch904: kdbus.patch
# END OF PATCH DEFINITIONS diff --git a/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch new file mode 100644 index 0000000..e239ea9 --- /dev/null +++ b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch @@ -0,0 +1,30 @@ +From: Dave Young dyoung@redhat.com
+[PATCH] kexec/uefi: copy secure_boot flag in boot params across kexec reboot
+Kexec reboot in case secure boot being enabled does not keep the secure boot +mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. +In this state, the system is missing the protections provided by secure boot.
+Adding a patch to fix this by retain the secure_boot flag in original kernel.
+secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. +Fixing this issue by copying secure_boot flag across kexec reboot.
+Signed-off-by: Dave Young dyoung@redhat.com +---
- arch/x86/kernel/kexec-bzimage64.c | 1 +
- 1 file changed, 1 insertion(+)
+diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c +index 9642b9b..0539ec7 100644 +--- a/arch/x86/kernel/kexec-bzimage64.c ++++ b/arch/x86/kernel/kexec-bzimage64.c +@@ -178,6 +178,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))return 0;++ params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;ei->efi_systab = current_ei->efi_systab;ei->efi_systab_hi = current_ei->efi_systab_hi;-- 1.8.3.1
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
But there is a long way to go before we get there. legacy call is well tested and new call is barely used anywhere. First we need to have confidence that new call can handle most of the use cases.
Thanks Vivek
I will add this patch regardless of that, but it seems like a good question to answer. Thanks!
josh
Adding a patch to fix this by retain the secure_boot flag in original kernel.
Signed-off-by: Dave Young dyoung@redhat.com
kernel.spec | 2 ++ ...uefi-copy-secure_boot-flag-in-boot-params.patch | 30 ++++++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
diff --git a/kernel.spec b/kernel.spec index e91ef9d..469a2a2 100644 --- a/kernel.spec +++ b/kernel.spec @@ -587,6 +587,8 @@ Patch505: 0001-dm-fix-dm_merge_bvec-regression-on-32-bit-systems.patch #rhbz 1244511 Patch507: HID-chicony-Add-support-for-Acer-Aspire-Switch-12.patch
+Patch508: kexec-uefi-copy-secure_boot-flag-in-boot-params.patch
Patch904: kdbus.patch
# END OF PATCH DEFINITIONS diff --git a/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch new file mode 100644 index 0000000..e239ea9 --- /dev/null +++ b/kexec-uefi-copy-secure_boot-flag-in-boot-params.patch @@ -0,0 +1,30 @@ +From: Dave Young dyoung@redhat.com
+[PATCH] kexec/uefi: copy secure_boot flag in boot params across kexec reboot
+Kexec reboot in case secure boot being enabled does not keep the secure boot +mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. +In this state, the system is missing the protections provided by secure boot.
+Adding a patch to fix this by retain the secure_boot flag in original kernel.
+secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. +Fixing this issue by copying secure_boot flag across kexec reboot.
+Signed-off-by: Dave Young dyoung@redhat.com +---
- arch/x86/kernel/kexec-bzimage64.c | 1 +
- 1 file changed, 1 insertion(+)
+diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c +index 9642b9b..0539ec7 100644 +--- a/arch/x86/kernel/kexec-bzimage64.c ++++ b/arch/x86/kernel/kexec-bzimage64.c +@@ -178,6 +178,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))return 0;++ params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;ei->efi_systab = current_ei->efi_systab;ei->efi_systab_hi = current_ei->efi_systab_hi;-- 1.8.3.1
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Fri, Aug 07, 2015 at 09:09:43AM -0400, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
Yes, which is what I was thinking we would want. However, I suppose people might still wish to build and kexec unsigned kernels on non-SB machines so that's probably not the right choice. Bummer.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
Right, but then we'd still have to carry Dave's patch because it will run into the same issue legacy kexec has today.
But there is a long way to go before we get there. legacy call is well tested and new call is barely used anywhere. First we need to have confidence that new call can handle most of the use cases.
Out of curiosity, does kexec-tools use the new system call by default? I suppose that would be one way to get it tested in a broad manner.
josh
On Fri, Aug 07, 2015 at 10:32:57AM -0400, Josh Boyer wrote:
On Fri, Aug 07, 2015 at 09:09:43AM -0400, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
Yes, which is what I was thinking we would want. However, I suppose people might still wish to build and kexec unsigned kernels on non-SB machines so that's probably not the right choice. Bummer.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
Right, but then we'd still have to carry Dave's patch because it will run into the same issue legacy kexec has today.
Right. I think Dave's patch is required anyway.
But there is a long way to go before we get there. legacy call is well tested and new call is barely used anywhere. First we need to have confidence that new call can handle most of the use cases.
Out of curiosity, does kexec-tools use the new system call by default? I suppose that would be one way to get it tested in a broad manner.
Right now kexec-tools switch to new call only if machine is secureboot enabled. Otherwise they default to old call.
I think first somebody needs to audit kexec-tools code and see if all major features we suppor there are available in new call or not. And then one can think of switching default in kexec-tools.
Thanks Vivek
On 08/07/15 at 10:57am, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 10:32:57AM -0400, Josh Boyer wrote:
On Fri, Aug 07, 2015 at 09:09:43AM -0400, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
Yes, which is what I was thinking we would want. However, I suppose people might still wish to build and kexec unsigned kernels on non-SB machines so that's probably not the right choice. Bummer.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
Right, but then we'd still have to carry Dave's patch because it will run into the same issue legacy kexec has today.
Right. I think Dave's patch is required anyway.
But there is a long way to go before we get there. legacy call is well tested and new call is barely used anywhere. First we need to have confidence that new call can handle most of the use cases.
Out of curiosity, does kexec-tools use the new system call by default? I suppose that would be one way to get it tested in a broad manner.
Right now kexec-tools switch to new call only if machine is secureboot enabled. Otherwise they default to old call.
I think first somebody needs to audit kexec-tools code and see if all major features we suppor there are available in new call or not. And then one can think of switching default in kexec-tools.
I think we can not switch to kexec_file only because one need signature verifying for non secure boot case, we probably still need another option to disable enforcing verification. Befor we find a better solution we still need maintain both kexec and kexec_file.
Thanks Vivek _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On 08/07/15 at 09:09am, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
But there are still use case that one need enforce verifying signature even without secure boot..
But there is a long way to go before we get there. legacy call is well tested and new call is barely used anywhere. First we need to have confidence that new call can handle most of the use cases.
Thanks Vivek
Thanks Dave
On Mon, Aug 10, 2015 at 07:34:48PM +0800, Dave Young wrote:
On 08/07/15 at 09:09am, Vivek Goyal wrote:
On Fri, Aug 07, 2015 at 07:15:57AM -0400, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
The way config options are in fedora, kexec_file() enforces signature verification. So if you disable legacy kexec, then it will not be possible to kexec unsigned kernels.
I think we should be able to modify kexec_file() such that it enfornces signature only when secureboot is enabled otherwise acts like a legacy call. Then we should be able to get rid of legacy kexec call.
But there are still use case that one need enforce verifying signature even without secure boot..
That can be managed with the help of a kernel config options and those who always need to verify signature will select that option.
Thanks Vivek
On 08/07/15 at 07:15am, Josh Boyer wrote:
On Fri, Aug 7, 2015 at 3:41 AM, Dave Young dyoung@redhat.com wrote:
Kexec reboot in case secure boot enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load.
Hm. Wasn't there code being written so that one could disable legacy kexec and only have kexec_file? Perhaps that is queued for 4.3. I'm wondering if as a general security measure we want to only have kexec_file available in Fedora when that is possible.
I will add this patch regardless of that, but it seems like a good question to answer. Thanks!
The patches for splitting kexec and kexec_file kconfig is in akpm tree. kexec_file is only for x86_64, for other arches we can only use kexec. Even for x86_64 we still need old kexec for non-secureboot use case especially unsigned user compiled kernel.
Thanks Dave ---- I'm on vacation Aug 10 - Aug 14 so apoligize that I can not reply email in time.
kernel@lists.fedoraproject.org
-
Dave Young -
Josh Boyer -
Vivek Goyal