[opensuse-kernel] [PATCH 0/11] Backported patches to lock down functions in secure boot
Patch-mainline: Not yet, reviewing References: none Target: openSUSE 12.3 Test steps: + build; make modules_install; make install + add 'secureboot_enable=1' kernel parameter Known issues on SLE (fixed): + xorg-x11-server need d01921ec18c21f21d377b606 patch for avoid 'xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)' Backported 11 patches to lock down functions in secure boot: 0001_Secure_boot:_Add_new_capability_v2.patch 0002_PCI:_Lock_down_BAR_access_in_secure_boot_environments_v2.patch 0003_x86:_Lock_down_IO_port_access_in_secure_boot_environments_v2.patch 0004_ACPI:_Limit_access_to_custom_method_v2.patch 0005_asus-wmi:_Restrict_debugfs_interface_v2.patch 0006_Restrict__dev_mem_and__dev_kmem_in_secure_boot_setups_v2.patch 0007_Secure_boot:_Add_a_dummy_kernel_parameter_that_will_switch_on_Secure_Boot_mode_v2.patch 0008_efi:_Enable_secure_boot_lockdown_automatically_when_enabled_in_firmware_v2.patch 0009_acpi:_Ignore_acpi_rsdp_kernel_parameter_in_a_secure_boot_environment_v2.patch 0010_SELinux:_define_mapping_for_new_Secure_Boot_capability_v2.patch 0011-hibernate-Disable-in-a-Secure-Boot-environment.patch -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Matthew Garrett
From: Josh Boyer
On Tuesday 15 January 2013 13:58:49 Lee, Chun-Yi wrote:
From: Josh Boyer
There is currently no way to verify the resume image when returning from hibernate. This might compromise the secure boot trust model, so until we can work with signed hibernate images we disable it in a Secure Boot environment.
Signed-off-by: Josh Boyer
Signed-off-by: Matthew Garrett Acked-by: Lee, Chun-Yi
@@ -723,7 +727,7 @@ static int software_resume(void) /* * If the user said "noresume".. bail out early. */ - if (noresume) + if (noresume || !capable(CAP_COMPROMISE_KERNEL)) return 0;
If this new code path is run, 1. we end up with a blocked swap partition 2. we leave an outdated image which would cause file system corruption if the user ever gets it to restore Is this wise? Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 01/15/2013 09:37 AM, Oliver Neukum wrote:
On Tuesday 15 January 2013 13:58:49 Lee, Chun-Yi wrote:
From: Josh Boyer
There is currently no way to verify the resume image when returning from hibernate. This might compromise the secure boot trust model, so until we can work with signed hibernate images we disable it in a Secure Boot environment.
Signed-off-by: Josh Boyer
Signed-off-by: Matthew Garrett Acked-by: Lee, Chun-Yi @@ -723,7 +727,7 @@ static int software_resume(void) /* * If the user said "noresume".. bail out early. */ - if (noresume) + if (noresume || !capable(CAP_COMPROMISE_KERNEL)) return 0;
If this new code path is run,
1. we end up with a blocked swap partition Blocked? How?
2. we leave an outdated image which would cause file system corruption if the user ever gets it to restore
Hmm. We would only end up with an outdated image if the user switched to secure boot _while the system is hibernated_. However, I would suggest to update the suspend tools to invalidate the suspend image if secure boot is enabled. Just to be on the safe side. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tuesday 15 January 2013 10:11:29 Hannes Reinecke wrote:
On 01/15/2013 09:37 AM, Oliver Neukum wrote:
On Tuesday 15 January 2013 13:58:49 Lee, Chun-Yi wrote:
From: Josh Boyer
There is currently no way to verify the resume image when returning from hibernate. This might compromise the secure boot trust model, so until we can work with signed hibernate images we disable it in a Secure Boot environment.
Signed-off-by: Josh Boyer
Signed-off-by: Matthew Garrett Acked-by: Lee, Chun-Yi @@ -723,7 +727,7 @@ static int software_resume(void) /* * If the user said "noresume".. bail out early. */ - if (noresume) + if (noresume || !capable(CAP_COMPROMISE_KERNEL)) return 0;
If this new code path is run,
1. we end up with a blocked swap partition Blocked? How?
It lacks a valid swap signature.
2. we leave an outdated image which would cause file system corruption if the user ever gets it to restore
Hmm. We would only end up with an outdated image if the user switched to secure boot _while the system is hibernated_.
Or he transplanted a hard drive. Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 二,2013-01-15 於 09:37 +0100,Oliver Neukum 提到:
On Tuesday 15 January 2013 13:58:49 Lee, Chun-Yi wrote:
From: Josh Boyer
There is currently no way to verify the resume image when returning from hibernate. This might compromise the secure boot trust model, so until we can work with signed hibernate images we disable it in a Secure Boot environment.
Signed-off-by: Josh Boyer
Signed-off-by: Matthew Garrett Acked-by: Lee, Chun-Yi @@ -723,7 +727,7 @@ static int software_resume(void) /* * If the user said "noresume".. bail out early. */ - if (noresume) + if (noresume || !capable(CAP_COMPROMISE_KERNEL)) return 0;
If this new code path is run,
1. we end up with a blocked swap partition 2. we leave an outdated image which would cause file system corruption if the user ever gets it to restore
Is this wise?
Regards Oliver
Did you mean the above situation will happen through the following procedure? + user boot system when disabled secure boot + boot to system then trigger S4 suspend -> generate S4 image + user go to BIOS to enable secure boot then boot + software_resume() detected secure boot enabled -> skip S4 image (equals to noresume paramter) But, if user use noresume will got the same problem? tracing more... Thanks a lot! Joey Lee -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tuesday 15 January 2013 17:21:04 joeyli wrote:
於 二,2013-01-15 於 09:37 +0100,Oliver Neukum 提到:
On Tuesday 15 January 2013 13:58:49 Lee, Chun-Yi wrote:
If this new code path is run,
1. we end up with a blocked swap partition 2. we leave an outdated image which would cause file system corruption if the user ever gets it to restore
Is this wise?
Regards Oliver
Did you mean the above situation will happen through the following procedure?
+ user boot system when disabled secure boot + boot to system then trigger S4 suspend -> generate S4 image + user go to BIOS to enable secure boot then boot + software_resume() detected secure boot enabled -> skip S4 image (equals to noresume paramter)
That is a way to get there, but not necessarily the only way.
But, if user use noresume will got the same problem? tracing more...
If the user explicitly tells the kernel to not resume, it his his fault. What we do in that case is not necessarily the right thing to do when the kernel, for a reason not clear to the user, refuses to resume. Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 15.01.2013 06:58, schrieb Lee, Chun-Yi:
Patch-mainline: Not yet, reviewing References: none Target: openSUSE 12.3
We're in the process of getting an openSUSE key for the shim loader and while I don't like it, it sounds requirement for that is having the kernel lockdown. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 二,2013-01-15 於 07:24 +0100,Stephan Kulow 提到:
Am 15.01.2013 06:58, schrieb Lee, Chun-Yi:
Patch-mainline: Not yet, reviewing References: none Target: openSUSE 12.3
We're in the process of getting an openSUSE key for the shim loader and while I don't like it, it sounds requirement for that is having the kernel lockdown.
Greetings, Stephan
There have risk for attacker to cause arbitrary kernel behavior through functions. Per my understand, Microsoft can revoke our key if attacker hack to machine through openSUSE vulnerabilities. This patch set doesn't merged by upstream but they are in Fedora kernel. Thanks a lot! Joey Lee -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, Jan 15, 2013 at 07:24:39AM +0100, Stephan Kulow wrote:
Am 15.01.2013 06:58, schrieb Lee, Chun-Yi:
Patch-mainline: Not yet, reviewing References: none Target: openSUSE 12.3
We're in the process of getting an openSUSE key for the shim loader and while I don't like it, it sounds requirement for that is having the kernel lockdown.
No, it's not a requirement at all. This is merely a "we want to try to restrict somethings if secure boot is enabled" set of features that some people feel is good to have in the kernel. These patches are nothing that the UEFI spec, nor the Microsoft signing group, requires in order to get a bootloader signed. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (6)
-
Greg KH
-
Hannes Reinecke
-
joeyli
-
Lee, Chun-Yi
-
Oliver Neukum
-
Stephan Kulow