[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 <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 Secure boot adds certain policy requirements, including that root must not be able to do anything that could cause the kernel to execute arbitrary code. The simplest way to handle this would seem to be to add a new capability and gate various functionality on that. We'll then strip it from the initial capability set if required. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- include/uapi/linux/capability.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/include/uapi/linux/capability.h +++ b/include/uapi/linux/capability.h @@ -343,7 +343,11 @@ struct vfs_cap_data { #define CAP_BLOCK_SUSPEND 36 -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND +/* Allow things that trivially permit root to modify the running kernel */ + +#define CAP_COMPROMISE_KERNEL 37 + +#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 Any hardware that can potentially generate DMA has to be locked down from userspace in order to avoid it being possible for an attacker to cause arbitrary kernel behaviour. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/pci/pci-sysfs.c | 9 +++++++++ drivers/pci/proc.c | 8 +++++++- drivers/pci/syscall.c | 2 +- 3 files changed, 17 insertions(+), 2 deletions(-) --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -546,6 +546,9 @@ pci_write_config(struct file* filp, stru loff_t init_off = off; u8 *data = (u8*) buf; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (off > dev->cfg_size) return 0; if (off + count > dev->cfg_size) { @@ -852,6 +855,9 @@ pci_mmap_resource(struct kobject *kobj, resource_size_t start, end; int i; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + for (i = 0; i < PCI_ROM_RESOURCE; i++) if (res == &pdev->resource[i]) break; @@ -959,6 +965,9 @@ pci_write_resource_io(struct file *filp, struct bin_attribute *attr, char *buf, loff_t off, size_t count) { + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + return pci_resource_io(filp, kobj, attr, buf, off, count, true); } --- a/drivers/pci/proc.c +++ b/drivers/pci/proc.c @@ -139,6 +139,9 @@ proc_bus_pci_write(struct file *file, co int size = dp->size; int cnt; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (pos >= size) return 0; if (nbytes >= size) @@ -219,6 +222,9 @@ static long proc_bus_pci_ioctl(struct fi #endif /* HAVE_PCI_MMAP */ int ret = 0; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + switch (cmd) { case PCIIOC_CONTROLLER: ret = pci_domain_nr(dev->bus); @@ -259,7 +265,7 @@ static int proc_bus_pci_mmap(struct file struct pci_filp_private *fpriv = file->private_data; int i, ret; - if (!capable(CAP_SYS_RAWIO)) + if (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL)) return -EPERM; /* Make sure the caller is mapping a real resource for this device */ --- a/drivers/pci/syscall.c +++ b/drivers/pci/syscall.c @@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigne u32 dword; int err = 0; - if (!capable(CAP_SYS_ADMIN)) + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_COMPROMISE_KERNEL)) return -EPERM; dev = pci_get_bus_and_slot(bus, dfn); -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- arch/x86/kernel/ioport.c | 4 ++-- drivers/char/mem.c | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/ioport.c +++ b/arch/x86/kernel/ioport.c @@ -28,7 +28,7 @@ asmlinkage long sys_ioperm(unsigned long if ((from + num <= from) || (from + num > IO_BITMAP_BITS)) return -EINVAL; - if (turn_on && !capable(CAP_SYS_RAWIO)) + if (turn_on && (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL))) return -EPERM; /* @@ -102,7 +102,7 @@ long sys_iopl(unsigned int level, struct return -EINVAL; /* Trying to gain more privileges? */ if (level > old) { - if (!capable(CAP_SYS_RAWIO)) + if (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL)) return -EPERM; } regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12); --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -609,6 +609,9 @@ static ssize_t write_port(struct file *f unsigned long i = *ppos; const char __user * tmp = buf; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (!access_ok(VERIFY_READ, buf, count)) return -EFAULT; while (count-- > 0 && i < 65536) { -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 It must be impossible for even root to get code executed in kernel context under a secure boot environment. custom_method effectively allows arbitrary access to system memory, so it needs to have a capability check here. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/acpi/custom_method.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/acpi/custom_method.c +++ b/drivers/acpi/custom_method.c @@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *fil struct acpi_table_header table; acpi_status status; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (!(*ppos)) { /* parse the table header to get the table length */ if (count <= sizeof(struct acpi_table_header)) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 We have no way of validating what all of the Asus WMI methods do on a given machine, and there's a risk that some will allow hardware state to be manipulated in such a way that arbitrary code can be executed in the kernel. Add a capability check to prevent that. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/platform/x86/asus-wmi.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/platform/x86/asus-wmi.c +++ b/drivers/platform/x86/asus-wmi.c @@ -1521,6 +1521,9 @@ static int show_dsts(struct seq_file *m, int err; u32 retval = -1; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval); if (err < 0) @@ -1537,6 +1540,9 @@ static int show_devs(struct seq_file *m, int err; u32 retval = -1; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param, &retval); @@ -1561,6 +1567,9 @@ static int show_call(struct seq_file *m, union acpi_object *obj; acpi_status status; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, 1, asus->debug.method_id, &input, &output); -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 Allowing users to write to address space makes it possible for the kernel to be subverted. Restrict this when we need to protect the kernel. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/char/mem.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -159,6 +159,9 @@ static ssize_t write_mem(struct file *fi unsigned long copied; void *ptr; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (!valid_phys_addr_range(p, count)) return -EFAULT; @@ -542,6 +545,9 @@ static ssize_t write_kmem(struct file *f char * kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */ int err = 0; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (p < (unsigned long) high_memory) { unsigned long to_write = min_t(unsigned long, count, (unsigned long)high_memory - p); -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 From: Josh Boyer <jwboyer@redhat.com> This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset in the init_cred struct, which everything else inherits from. This works on any machine and can be used to develop even if the box doesn't have UEFI. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- kernel/cred.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/kernel/cred.c +++ b/kernel/cred.c @@ -623,6 +623,23 @@ void __init cred_init(void) 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL); } +void __init secureboot_enable() +{ + pr_info("Secure boot enabled\n"); + cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL); + cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL); +} + +/* Dummy Secure Boot enable option to fake out UEFI SB=1 */ +static int __init secureboot_enable_opt(char *str) +{ + int sb_enable = !!simple_strtol(str, NULL, 0); + if (sb_enable) + secureboot_enable(); + return 1; +} +__setup("secureboot_enable=", secureboot_enable_opt); + /** * prepare_kernel_cred - Prepare a set of credentials for a kernel service * @daemon: A userspace daemon to be used as a reference -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 The firmware has a set of flags that indicate whether secure boot is enabled and enforcing. Use them to indicate whether the kernel should lock itself down. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- Documentation/x86/zero-page.txt | 2 ++ arch/x86/boot/compressed/eboot.c | 32 ++++++++++++++++++++++++++++++++ arch/x86/include/asm/bootparam.h | 3 ++- arch/x86/kernel/setup.c | 3 +++ include/linux/cred.h | 2 ++ 5 files changed, 41 insertions(+), 1 deletion(-) --- a/Documentation/x86/zero-page.txt +++ b/Documentation/x86/zero-page.txt @@ -27,6 +27,8 @@ Offset Proto Name Meaning 1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below) 1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer (below) +1EB/001 ALL kbd_status Numlock is enabled +1EC/001 ALL secure_boot Kernel should enable secure boot lockdowns 290/040 ALL edd_mbr_sig_buffer EDD MBR signatures 2D0/A00 ALL e820_map E820 memory map table (array of struct e820entry) --- a/arch/x86/boot/compressed/eboot.c +++ b/arch/x86/boot/compressed/eboot.c @@ -732,6 +732,36 @@ fail: return status; } +static int get_secure_boot(efi_system_table_t *_table) +{ + u8 sb, setup; + unsigned long datasize = sizeof(sb); + efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID; + efi_status_t status; + + status = efi_call_phys5(sys_table->runtime->get_variable, + L"SecureBoot", &var_guid, NULL, &datasize, &sb); + + if (status != EFI_SUCCESS) + return 0; + + if (sb == 0) + return 0; + + + status = efi_call_phys5(sys_table->runtime->get_variable, + L"SetupMode", &var_guid, NULL, &datasize, + &setup); + + if (status != EFI_SUCCESS) + return 0; + + if (setup == 1) + return 0; + + return 1; +} + /* * Because the x86 boot code expects to be passed a boot_params we * need to create one ourselves (usually the bootloader would create @@ -1026,6 +1056,8 @@ struct boot_params *efi_main(void *handl if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) goto fail; + boot_params->secure_boot = get_secure_boot(sys_table); + setup_graphics(boot_params); status = efi_call_phys3(sys_table->boottime->allocate_pool, --- a/arch/x86/include/asm/bootparam.h +++ b/arch/x86/include/asm/bootparam.h @@ -114,7 +114,8 @@ struct boot_params { __u8 eddbuf_entries; /* 0x1e9 */ __u8 edd_mbr_sig_buf_entries; /* 0x1ea */ __u8 kbd_status; /* 0x1eb */ - __u8 _pad6[5]; /* 0x1ec */ + __u8 secure_boot; /* 0x1ec */ + __u8 _pad6[4]; /* 0x1ed */ struct setup_header hdr; /* setup header */ /* 0x1f1 */ __u8 _pad7[0x290-0x1f1-sizeof(struct setup_header)]; __u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */ --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -964,6 +964,9 @@ void __init setup_arch(char **cmdline_p) io_delay_init(); + if (boot_params.secure_boot) + secureboot_enable(); + /* * Parse the ACPI tables for possible boot-time SMP configuration. */ --- a/include/linux/cred.h +++ b/include/linux/cred.h @@ -170,6 +170,8 @@ extern int set_security_override_from_ct extern int set_create_files_as(struct cred *, struct inode *); extern void __init cred_init(void); +extern void secureboot_enable(void); + /* * check for validity of credentials */ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 From: Josh Boyer <jwboyer@redhat.com> This option allows userspace to pass the RSDP address to the kernel. This could potentially be used to circumvent the secure boot trust model. We ignore the setting if we don't have the CAP_COMPROMISE_KERNEL capability. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/acpi/osl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -246,7 +246,7 @@ early_param("acpi_rsdp", setup_acpi_rsdp acpi_physical_address __init acpi_os_get_root_pointer(void) { #ifdef CONFIG_KEXEC - if (acpi_rsdp) + if (acpi_rsdp && capable(CAP_COMPROMISE_KERNEL)) return acpi_rsdp; #endif -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Matthew Garrett <mjg@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 From: Josh Boyer <jwboyer@redhat.com> Add the name of the new Secure Boot capability. This allows SELinux policies to properly map CAP_COMPROMISE_KERNEL to the appropriate capability class. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- security/selinux/include/classmap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -146,8 +146,8 @@ struct security_class_mapping secclass_m { "memprotect", { "mmap_zero", NULL } }, { "peer", { "recv", NULL } }, { "capability2", - { "mac_override", "mac_admin", "syslog", "wake_alarm", "block_suspend", - NULL } }, + { "mac_override", "mac_admin", "syslog", "wake_alarm", + "block_suspend", "compromise_kernel", NULL } }, { "kernel_service", { "use_as_override", "create_files_as", NULL } }, { "tun_socket", { COMMON_SOCK_PERMS, NULL } }, -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Josh Boyer <jwboyer@redhat.com> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing References: fate#314486 Target: SLE-11 SP3 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 <jwboyer@redhat.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com --- v2: Updated to include swsup after feedback from Jiri Kosina <jkosina@suse.cz> kernel/power/hibernate.c | 14 +++++++++++++- kernel/power/main.c | 4 +++- kernel/power/user.c | 3 +++ 3 files changed, 19 insertions(+), 2 deletions(-) --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -632,6 +632,10 @@ int hibernate(void) { int error; + if (!capable(CAP_COMPROMISE_KERNEL)) { + return -EPERM; + } + lock_system_sleep(); /* The snapshot device should not be opened while we're running */ if (!atomic_add_unless(&snapshot_device_available, -1, 0)) { @@ -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; /* @@ -889,6 +893,11 @@ static ssize_t disk_show(struct kobject int i; char *start = buf; + if (!capable(CAP_COMPROMISE_KERNEL)) { + buf += sprintf(buf, "[%s]\n", "disabled"); + return buf-start; + } + for (i = HIBERNATION_FIRST; i <= HIBERNATION_MAX; i++) { if (!hibernation_modes[i]) continue; @@ -923,6 +932,9 @@ static ssize_t disk_store(struct kobject char *p; int mode = HIBERNATION_INVALID; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + p = memchr(buf, '\n', n); len = p ? p - buf : n; --- a/kernel/power/main.c +++ b/kernel/power/main.c @@ -301,7 +301,9 @@ static ssize_t state_show(struct kobject } #endif #ifdef CONFIG_HIBERNATION - s += sprintf(s, "%s\n", "disk"); + if (capable(CAP_COMPROMISE_KERNEL)) { + s += sprintf(s, "%s\n", "disk"); + } #else if (s != buf) /* convert the last space to a newline */ --- a/kernel/power/user.c +++ b/kernel/power/user.c @@ -48,6 +48,9 @@ static int snapshot_open(struct inode *i struct snapshot_data *data; int error; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + lock_system_sleep(); if (!atomic_add_unless(&snapshot_device_available, -1, 0)) { -- 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 13:58:49 Lee, Chun-Yi wrote:
From: Josh Boyer <jwboyer@redhat.com>
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 <jwboyer@redhat.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com
@@ -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 <jwboyer@redhat.com>
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 <jwboyer@redhat.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com
@@ -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 <jwboyer@redhat.com>
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 <jwboyer@redhat.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com
@@ -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 <jwboyer@redhat.com>
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 <jwboyer@redhat.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Lee, Chun-Yi <jlee@suse.com
@@ -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