* [RFC] Second attempt at kernel secure boot support @ 2012-09-20 14:40 Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett ` (11 more replies) 0 siblings, 12 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:40 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi This is pretty much identical to the first patchset, but with the capability renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants to deploy these then they should disable kexec until support for signed kexec payloads has been merged. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH V2 01/10] Secure boot: Add new capability 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett @ 2012-09-20 14:40 ` Matthew Garrett 2012-09-28 3:10 ` Serge Hallyn 2012-10-20 0:15 ` joeyli 2012-09-20 14:40 ` [PATCH V2 02/10] PCI: Lock down BAR access in secure boot environments Matthew Garrett ` (10 subsequent siblings) 11 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:40 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- include/linux/capability.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/linux/capability.h b/include/linux/capability.h index d10b7ed..4345bc8 100644 --- a/include/linux/capability.h +++ b/include/linux/capability.h @@ -364,7 +364,11 @@ struct cpu_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) -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH V2 01/10] Secure boot: Add new capability 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett @ 2012-09-28 3:10 ` Serge Hallyn 2012-10-20 0:15 ` joeyli 1 sibling, 0 replies; 224+ messages in thread From: Serge Hallyn @ 2012-09-28 3:10 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi Quoting Matthew Garrett (mjg@redhat.com): > 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: Serge E. Hallyn <serge.hallyn@ubuntu.com> > --- > include/linux/capability.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/linux/capability.h b/include/linux/capability.h > index d10b7ed..4345bc8 100644 > --- a/include/linux/capability.h > +++ b/include/linux/capability.h > @@ -364,7 +364,11 @@ struct cpu_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) > > -- > 1.7.11.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 01/10] Secure boot: Add new capability 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett 2012-09-28 3:10 ` Serge Hallyn @ 2012-10-20 0:15 ` joeyli 2012-10-20 9:02 ` Matt Fleming 1 sibling, 1 reply; 224+ messages in thread From: joeyli @ 2012-10-20 0:15 UTC (permalink / raw) To: Matt Fleming Cc: linux-kernel, linux-security-module, linux-efi, Matthew Garrett Hi Matt, Sorry for bother you! I didn't see this Matthew's patchset merged in EFI git tree. Do you have plan to merge it? Or those patches need wait different subsystem leaders merge. Thanks a lot! Joey Lee 於 四,2012-09-20 於 10:40 -0400,Matthew Garrett 提到: > 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> > --- > include/linux/capability.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/linux/capability.h b/include/linux/capability.h > index d10b7ed..4345bc8 100644 > --- a/include/linux/capability.h > +++ b/include/linux/capability.h > @@ -364,7 +364,11 @@ struct cpu_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) > ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 01/10] Secure boot: Add new capability 2012-10-20 0:15 ` joeyli @ 2012-10-20 9:02 ` Matt Fleming 0 siblings, 0 replies; 224+ messages in thread From: Matt Fleming @ 2012-10-20 9:02 UTC (permalink / raw) To: joeyli; +Cc: linux-kernel, linux-security-module, linux-efi, Matthew Garrett On Sat, 2012-10-20 at 08:15 +0800, joeyli wrote: > Hi Matt, > > Sorry for bother you! > > I didn't see this Matthew's patchset merged in EFI git tree. Do you have > plan to merge it? Or those patches need wait different subsystem leaders > merge. I don't think it makes sense for the secure boot patch series to go through the EFI tree as it touches a lot of other subsystems. ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH V2 02/10] PCI: Lock down BAR access in secure boot environments 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett @ 2012-09-20 14:40 ` Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 03/10] x86: Lock down IO port " Matthew Garrett ` (9 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:40 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- drivers/pci/pci-sysfs.c | 9 +++++++++ drivers/pci/proc.c | 8 +++++++- drivers/pci/syscall.c | 2 +- 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 02d107b..c31b4be 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -580,6 +580,9 @@ pci_write_config(struct file* filp, struct kobject *kobj, 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) { @@ -886,6 +889,9 @@ pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr, 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; @@ -993,6 +999,9 @@ pci_write_resource_io(struct file *filp, struct kobject *kobj, 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); } diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c index 27911b5..ac8c9a5 100644 --- a/drivers/pci/proc.c +++ b/drivers/pci/proc.c @@ -135,6 +135,9 @@ proc_bus_pci_write(struct file *file, const char __user *buf, size_t nbytes, lof int size = dp->size; int cnt; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (pos >= size) return 0; if (nbytes >= size) @@ -211,6 +214,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd, #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); @@ -251,7 +257,7 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma) 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 */ diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c index e1c1ec5..97e785f 100644 --- a/drivers/pci/syscall.c +++ b/drivers/pci/syscall.c @@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned long, dfn, 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); -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 03/10] x86: Lock down IO port access in secure boot environments 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 02/10] PCI: Lock down BAR access in secure boot environments Matthew Garrett @ 2012-09-20 14:40 ` Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 04/10] ACPI: Limit access to custom_method Matthew Garrett ` (8 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:40 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- arch/x86/kernel/ioport.c | 4 ++-- drivers/char/mem.c | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c index 8c96897..a2578c4 100644 --- a/arch/x86/kernel/ioport.c +++ b/arch/x86/kernel/ioport.c @@ -28,7 +28,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on) 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 pt_regs *regs) 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); diff --git a/drivers/char/mem.c b/drivers/char/mem.c index e5eedfa2..1e0a660 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -597,6 +597,9 @@ static ssize_t write_port(struct file *file, const char __user *buf, 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) { -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 04/10] ACPI: Limit access to custom_method 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (2 preceding siblings ...) 2012-09-20 14:40 ` [PATCH V2 03/10] x86: Lock down IO port " Matthew Garrett @ 2012-09-20 14:40 ` Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 05/10] asus-wmi: Restrict debugfs interface Matthew Garrett ` (7 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:40 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- drivers/acpi/custom_method.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c index 5d42c24..247d58b 100644 --- a/drivers/acpi/custom_method.c +++ b/drivers/acpi/custom_method.c @@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *file, const char __user * user_buf, 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)) -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 05/10] asus-wmi: Restrict debugfs interface 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (3 preceding siblings ...) 2012-09-20 14:40 ` [PATCH V2 04/10] ACPI: Limit access to custom_method Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 06/10] Restrict /dev/mem and /dev/kmem in secure boot setups Matthew Garrett ` (6 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- drivers/platform/x86/asus-wmi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c index c0e9ff4..3c10167 100644 --- 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, void *data) 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, void *data) 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, void *data) 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); -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 06/10] Restrict /dev/mem and /dev/kmem in secure boot setups 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (4 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 05/10] asus-wmi: Restrict debugfs interface Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett ` (5 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- drivers/char/mem.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 1e0a660..33eb947 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -158,6 +158,9 @@ static ssize_t write_mem(struct file *file, const char __user *buf, unsigned long copied; void *ptr; + if (!capable(CAP_COMPROMISE_KERNEL)) + return -EPERM; + if (!valid_phys_addr_range(p, count)) return -EFAULT; @@ -530,6 +533,9 @@ static ssize_t write_kmem(struct file *file, const char __user *buf, 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); -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (5 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 06/10] Restrict /dev/mem and /dev/kmem in secure boot setups Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-20 16:32 ` Greg KH ` (2 more replies) 2012-09-20 14:41 ` [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett ` (4 subsequent siblings) 11 siblings, 3 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Josh Boyer 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> --- kernel/cred.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/cred.c b/kernel/cred.c index de728ac..7e6e83f 100644 --- 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 -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett @ 2012-09-20 16:32 ` Greg KH 2012-09-20 17:40 ` Josh Boyer 2012-09-25 13:08 ` [PATCH V3 " Josh Boyer 2012-09-21 8:20 ` [PATCH V2 " joeyli 2012-09-28 3:20 ` Serge Hallyn 2 siblings, 2 replies; 224+ messages in thread From: Greg KH @ 2012-09-20 16:32 UTC (permalink / raw) To: Matthew Garrett Cc: linux-kernel, linux-security-module, linux-efi, Josh Boyer On Thu, Sep 20, 2012 at 10:41:02AM -0400, Matthew Garrett wrote: > 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> > --- > kernel/cred.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/kernel/cred.c b/kernel/cred.c > index de728ac..7e6e83f 100644 > --- 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); Document this please in the bootparams file. thanks, greg k-h ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 16:32 ` Greg KH @ 2012-09-20 17:40 ` Josh Boyer 2012-09-25 13:08 ` [PATCH V3 " Josh Boyer 1 sibling, 0 replies; 224+ messages in thread From: Josh Boyer @ 2012-09-20 17:40 UTC (permalink / raw) To: Greg KH; +Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Thu, Sep 20, 2012 at 05:32:37PM +0100, Greg KH wrote: > On Thu, Sep 20, 2012 at 10:41:02AM -0400, Matthew Garrett wrote: > > 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> > > --- > > kernel/cred.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/kernel/cred.c b/kernel/cred.c > > index de728ac..7e6e83f 100644 > > --- 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); > > Document this please in the bootparams file. Oops, yes. Will do. Thanks for pointing it out. josh ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 16:32 ` Greg KH 2012-09-20 17:40 ` Josh Boyer @ 2012-09-25 13:08 ` Josh Boyer 2012-10-29 9:00 ` joeyli 1 sibling, 1 reply; 224+ messages in thread From: Josh Boyer @ 2012-09-25 13:08 UTC (permalink / raw) To: linux-kernel, linux-security-module, linux-efi; +Cc: Greg KH, Matthew Garrett 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> --- Documentation/kernel-parameters.txt | 7 +++++++ kernel/cred.c | 17 +++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9b2b8d3..93978d5 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2562,6 +2562,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Note: increases power consumption, thus should only be enabled if running jitter sensitive (HPC/RT) workloads. + secureboot_enable= + [KNL] Enables an emulated UEFI Secure Boot mode. This + locks down various aspects of the kernel guarded by the + CAP_COMPROMISE_KERNEL capability. This includes things + like /dev/mem, IO port access, and other areas. It can + be used on non-UEFI machines for testing purposes. + security= [SECURITY] Choose a security module to enable at boot. If this boot parameter is not specified, only the first security module asking for security registration will be diff --git a/kernel/cred.c b/kernel/cred.c index de728ac..7e6e83f 100644 --- 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 -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-25 13:08 ` [PATCH V3 " Josh Boyer @ 2012-10-29 9:00 ` joeyli 2012-10-30 17:48 ` Josh Boyer 0 siblings, 1 reply; 224+ messages in thread From: joeyli @ 2012-10-29 9:00 UTC (permalink / raw) To: Josh Boyer Cc: linux-kernel, linux-security-module, linux-efi, Greg KH, Matthew Garrett, tiwai Hi Josh, 於 二,2012-09-25 於 09:08 -0400,Josh Boyer 提到: > 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> > --- > Documentation/kernel-parameters.txt | 7 +++++++ > kernel/cred.c | 17 +++++++++++++++++ > 2 files changed, 24 insertions(+) > > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt > index 9b2b8d3..93978d5 100644 ... > diff --git a/kernel/cred.c b/kernel/cred.c > index de728ac..7e6e83f 100644 > --- 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() > +{ ... > + > +/* 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); > + > Tahashi has a good idea for use strtobool to allow 'secureboot_enable=yes' works. Please consider the following change. Thanks a lot! Joey Lee >From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001 From: Lee, Chun-Yi <jlee@suse.com> Date: Mon, 29 Oct 2012 16:36:57 +0800 Subject: [PATCH] efi: more user-friendly secureboot_enable parameter From: Takashi Iwai <tiwai@suse.de> Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly. Signed-off-by: Lee, Chun-Yi <jlee@suse.com> --- kernel/cred.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/cred.c b/kernel/cred.c index 3f5be65..70897a2 100644 --- a/kernel/cred.c +++ b/kernel/cred.c @@ -633,9 +633,10 @@ void __init secureboot_enable() /* 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) + bool sb_enable; + if (!strtobool(str, &sb_enable) && sb_enable) secureboot_enable(); + return 1; } __setup("secureboot_enable=", secureboot_enable_opt); -- 1.6.0.2 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-10-29 9:00 ` joeyli @ 2012-10-30 17:48 ` Josh Boyer 2012-10-30 19:27 ` joeyli 0 siblings, 1 reply; 224+ messages in thread From: Josh Boyer @ 2012-10-30 17:48 UTC (permalink / raw) To: joeyli Cc: linux-kernel, linux-security-module, linux-efi, Greg KH, Matthew Garrett, tiwai On Mon, Oct 29, 2012 at 05:00:06PM +0800, joeyli wrote: > Hi Josh, > Tahashi has a good idea for use strtobool to allow > 'secureboot_enable=yes' works. Please consider the following change. > > > Thanks a lot! > Joey Lee > > >From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001 > From: Lee, Chun-Yi <jlee@suse.com> > Date: Mon, 29 Oct 2012 16:36:57 +0800 > Subject: [PATCH] efi: more user-friendly secureboot_enable parameter > > From: Takashi Iwai <tiwai@suse.de> > > Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly. > > Signed-off-by: Lee, Chun-Yi <jlee@suse.com> > --- > kernel/cred.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/cred.c b/kernel/cred.c > index 3f5be65..70897a2 100644 > --- a/kernel/cred.c > +++ b/kernel/cred.c > @@ -633,9 +633,10 @@ void __init secureboot_enable() > /* 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) > + bool sb_enable; > + if (!strtobool(str, &sb_enable) && sb_enable) > secureboot_enable(); > + > return 1; > } > __setup("secureboot_enable=", secureboot_enable_opt); This seems like a good change to me. If you don't mind, I'll rework the existing patch to do this since it hasn't been accepted upstream yet and give Takashi-san and you appropriate credit in the commit log. josh ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-10-30 17:48 ` Josh Boyer @ 2012-10-30 19:27 ` joeyli 0 siblings, 0 replies; 224+ messages in thread From: joeyli @ 2012-10-30 19:27 UTC (permalink / raw) To: Josh Boyer Cc: linux-kernel, linux-security-module, linux-efi, Greg KH, Matthew Garrett, tiwai 於 二,2012-10-30 於 13:48 -0400,Josh Boyer 提到: > On Mon, Oct 29, 2012 at 05:00:06PM +0800, joeyli wrote: > > Hi Josh, > > Tahashi has a good idea for use strtobool to allow > > 'secureboot_enable=yes' works. Please consider the following change. > > > > > > Thanks a lot! > > Joey Lee > > > > >From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001 > > From: Lee, Chun-Yi <jlee@suse.com> > > Date: Mon, 29 Oct 2012 16:36:57 +0800 > > Subject: [PATCH] efi: more user-friendly secureboot_enable parameter > > > > From: Takashi Iwai <tiwai@suse.de> > > > > Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly. > > > > Signed-off-by: Lee, Chun-Yi <jlee@suse.com> > > --- > > kernel/cred.c | 5 +++-- > > 1 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/cred.c b/kernel/cred.c > > index 3f5be65..70897a2 100644 > > --- a/kernel/cred.c > > +++ b/kernel/cred.c > > @@ -633,9 +633,10 @@ void __init secureboot_enable() > > /* 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) > > + bool sb_enable; > > + if (!strtobool(str, &sb_enable) && sb_enable) > > secureboot_enable(); > > + > > return 1; > > } > > __setup("secureboot_enable=", secureboot_enable_opt); > > This seems like a good change to me. If you don't mind, I'll rework the > existing patch to do this since it hasn't been accepted upstream yet and > give Takashi-san and you appropriate credit in the commit log. > > josh > Thanks for your review and feel free add to your reworked patch. Joey Lee ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett 2012-09-20 16:32 ` Greg KH @ 2012-09-21 8:20 ` joeyli 2012-09-28 3:20 ` Serge Hallyn 2 siblings, 0 replies; 224+ messages in thread From: joeyli @ 2012-09-21 8:20 UTC (permalink / raw) To: Matthew Garrett Cc: linux-kernel, linux-security-module, linux-efi, Josh Boyer 於 四,2012-09-20 於 10:41 -0400,Matthew Garrett 提到: > 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> Patch works to me for test lock the IO port access. Tested-by: Lee, Chun-Yi <jlee@suse.com> Joey Lee > --- > kernel/cred.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/kernel/cred.c b/kernel/cred.c > index de728ac..7e6e83f 100644 > --- 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 ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett 2012-09-20 16:32 ` Greg KH 2012-09-21 8:20 ` [PATCH V2 " joeyli @ 2012-09-28 3:20 ` Serge Hallyn 2 siblings, 0 replies; 224+ messages in thread From: Serge Hallyn @ 2012-09-28 3:20 UTC (permalink / raw) To: Matthew Garrett Cc: linux-kernel, linux-security-module, linux-efi, Josh Boyer Quoting Matthew Garrett (mjg@redhat.com): > 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: Serge E. Hallyn <serge.hallyn@ubuntu.com> > --- > kernel/cred.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/kernel/cred.c b/kernel/cred.c > index de728ac..7e6e83f 100644 > --- 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 > -- > 1.7.11.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (6 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-28 3:21 ` Serge Hallyn 2012-10-22 13:22 ` Matt Fleming 2012-09-20 14:41 ` [PATCH V2 09/10] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment Matthew Garrett ` (3 subsequent siblings) 11 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Matthew Garrett 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> --- 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(-) diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt index cf5437d..7f9ed48 100644 --- 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) diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c index b3e0227..3789356 100644 --- a/arch/x86/boot/compressed/eboot.c +++ b/arch/x86/boot/compressed/eboot.c @@ -724,6 +724,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 @@ -1018,6 +1048,8 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table, 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, diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h index 2ad874c..c7338e0 100644 --- 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 */ diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index f4b9b80..239bf2a 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -947,6 +947,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. */ diff --git a/include/linux/cred.h b/include/linux/cred.h index ebbed2c..a24faf1 100644 --- a/include/linux/cred.h +++ b/include/linux/cred.h @@ -170,6 +170,8 @@ extern int set_security_override_from_ctx(struct cred *, const char *); 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 */ -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware 2012-09-20 14:41 ` [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett @ 2012-09-28 3:21 ` Serge Hallyn 2012-10-22 13:22 ` Matt Fleming 1 sibling, 0 replies; 224+ messages in thread From: Serge Hallyn @ 2012-09-28 3:21 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi Quoting Matthew Garrett (mjg@redhat.com): > 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> (purely for the non-firmware bits) seems good, thanks. Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.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(-) > > diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt > index cf5437d..7f9ed48 100644 > --- 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) > diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c > index b3e0227..3789356 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -724,6 +724,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 > @@ -1018,6 +1048,8 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table, > 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, > diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h > index 2ad874c..c7338e0 100644 > --- 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 */ > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > index f4b9b80..239bf2a 100644 > --- a/arch/x86/kernel/setup.c > +++ b/arch/x86/kernel/setup.c > @@ -947,6 +947,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. > */ > diff --git a/include/linux/cred.h b/include/linux/cred.h > index ebbed2c..a24faf1 100644 > --- a/include/linux/cred.h > +++ b/include/linux/cred.h > @@ -170,6 +170,8 @@ extern int set_security_override_from_ctx(struct cred *, const char *); > 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 > */ > -- > 1.7.11.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware 2012-09-20 14:41 ` [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett 2012-09-28 3:21 ` Serge Hallyn @ 2012-10-22 13:22 ` Matt Fleming 1 sibling, 0 replies; 224+ messages in thread From: Matt Fleming @ 2012-10-22 13:22 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi On Thu, 2012-09-20 at 10:41 -0400, Matthew Garrett wrote: > 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> > --- > 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(-) Probably wants an update to Documentation/x86/boot.txt too. But otherwise, Acked-by: Matt Fleming <matt.fleming@intel.com> ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH V2 09/10] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (7 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 10/10] SELinux: define mapping for new Secure Boot capability Matthew Garrett ` (2 subsequent siblings) 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Josh Boyer 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> --- drivers/acpi/osl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 9eaf708..f94341b 100644 --- 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 -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH V2 10/10] SELinux: define mapping for new Secure Boot capability 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (8 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 09/10] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment Matthew Garrett @ 2012-09-20 14:41 ` Matthew Garrett 2012-09-21 22:55 ` [RFC] Second attempt at kernel secure boot support Eric W. Biederman 2012-10-29 7:49 ` Jiri Kosina 11 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-20 14:41 UTC (permalink / raw) To: linux-kernel; +Cc: linux-security-module, linux-efi, Josh Boyer 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> --- security/selinux/include/classmap.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h index df2de54..70e2834 100644 --- a/security/selinux/include/classmap.h +++ b/security/selinux/include/classmap.h @@ -146,8 +146,8 @@ struct security_class_mapping secclass_map[] = { { "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 } }, -- 1.7.11.4 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (9 preceding siblings ...) 2012-09-20 14:41 ` [PATCH V2 10/10] SELinux: define mapping for new Secure Boot capability Matthew Garrett @ 2012-09-21 22:55 ` Eric W. Biederman 2012-09-22 15:21 ` Matthew Garrett 2012-10-29 7:49 ` Jiri Kosina 11 siblings, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-09-21 22:55 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg@redhat.com> writes: > This is pretty much identical to the first patchset, but with the capability > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants > to deploy these then they should disable kexec until support for signed > kexec payloads has been merged. A couple of thoughts. 1) I don't see anything disabling kdb or kgdb. If ever there was a way to poke into the kernel and change things... 2) You almost certainly want to disable module removal. It is all to easy to have races where that are not properly handled in the module removal path. I know I saw a bundle of those in debugfs the other day. 3) And half seriously you probably want to disable mounting of filesystems. I believe I have heard it said the kernel has not been vetted against a hostile root user mounting deliberately corrupted filesystem images. As it is designed I don't believe your patchset can successfully achieve the goal of keeping a determined root user from injecting code into the kernel without disabling so many kernel features the kernel is uninteresting for most people to run. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-09-21 22:55 ` [RFC] Second attempt at kernel secure boot support Eric W. Biederman @ 2012-09-22 15:21 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-09-22 15:21 UTC (permalink / raw) To: Eric W. Biederman; +Cc: linux-kernel, linux-security-module, linux-efi On Fri, Sep 21, 2012 at 03:55:28PM -0700, Eric W. Biederman wrote: > 1) I don't see anything disabling kdb or kgdb. If ever there > was a way to poke into the kernel and change things... Is there any way to access them without having physical console access (either the system console or a serial console)? Physically-present attacks are kind of out of scope here. > 2) You almost certainly want to disable module removal. It is all to > easy to have races where that are not properly handled in the module > removal path. I know I saw a bundle of those in debugfs the other > day. I'm pretty reluctant to work around bugs like this. Disabling features certainly reduces the attack surface, but the aim is to only disable features that *by design* permit the modification of the kernel. Where it's possible to do so by exploiting bugs, we should be fixing the bugs. > 3) And half seriously you probably want to disable mounting of > filesystems. I believe I have heard it said the kernel has not been > vetted against a hostile root user mounting deliberately corrupted > filesystem images. See (2). Not that you need to be root to trigger filesystem mounts, so this is also a user->kernel exploit. Those should be fixed. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett ` (10 preceding siblings ...) 2012-09-21 22:55 ` [RFC] Second attempt at kernel secure boot support Eric W. Biederman @ 2012-10-29 7:49 ` Jiri Kosina 2012-10-29 17:41 ` Matthew Garrett 11 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-10-29 7:49 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi On Thu, 20 Sep 2012, Matthew Garrett wrote: > This is pretty much identical to the first patchset, but with the capability > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants > to deploy these then they should disable kexec until support for signed > kexec payloads has been merged. Apparently your patchset currently doesn't handle device firmware loading, nor do you seem to mention in in the comments. I believe signed firmware loading should be put on plate as well, right? Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-29 7:49 ` Jiri Kosina @ 2012-10-29 17:41 ` Matthew Garrett 2012-10-31 14:50 ` Jiri Kosina 2012-10-31 17:28 ` Takashi Iwai 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-29 17:41 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-kernel, linux-security-module, linux-efi On Mon, Oct 29, 2012 at 08:49:41AM +0100, Jiri Kosina wrote: > On Thu, 20 Sep 2012, Matthew Garrett wrote: > > > This is pretty much identical to the first patchset, but with the capability > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants > > to deploy these then they should disable kexec until support for signed > > kexec payloads has been merged. > > Apparently your patchset currently doesn't handle device firmware loading, > nor do you seem to mention in in the comments. Correct. > I believe signed firmware loading should be put on plate as well, right? I think that's definitely something that should be covered. I hadn't worried about it immediately as any attack would be limited to machines with a specific piece of hardware, and the attacker would need to expend a significant amount of reverse engineering work on the firmware - and we'd probably benefit from them doing that in the long run... Having said that, yes, we should worry about this. Firmware distribution licenses often forbid any distribution of modified versions, so signatures would probably need to be detached. udev could easily glue together a signature and firmware when loading, but if we're moving towards an in-kernel firmware loader for the common case then it'll need to be implemented there as well. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-29 17:41 ` Matthew Garrett @ 2012-10-31 14:50 ` Jiri Kosina 2012-10-31 14:54 ` Josh Boyer 2012-10-31 15:02 ` Matthew Garrett 2012-10-31 17:28 ` Takashi Iwai 1 sibling, 2 replies; 224+ messages in thread From: Jiri Kosina @ 2012-10-31 14:50 UTC (permalink / raw) To: Matthew Garrett; +Cc: linux-kernel, linux-security-module, linux-efi On Mon, 29 Oct 2012, Matthew Garrett wrote: > > > This is pretty much identical to the first patchset, but with the capability > > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants > > > to deploy these then they should disable kexec until support for signed > > > kexec payloads has been merged. > > > > Apparently your patchset currently doesn't handle device firmware loading, > > nor do you seem to mention in in the comments. > > Correct. > > > I believe signed firmware loading should be put on plate as well, right? > > I think that's definitely something that should be covered. I hadn't > worried about it immediately as any attack would be limited to machines > with a specific piece of hardware, and the attacker would need to expend > a significant amount of reverse engineering work on the firmware - and > we'd probably benefit from them doing that in the long run... Now -- how about resuming from S4? Reading stored memory image (potentially tampered before reboot) from disk is basically DMA-ing arbitrary data over the whole RAM. I am currently not able to imagine a scenario how this could be made "secure" (without storing private keys to sign the hibernation image on the machine itself which, well, doesn't sound secure either). -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 14:50 ` Jiri Kosina @ 2012-10-31 14:54 ` Josh Boyer 2012-10-31 14:59 ` Shea Levy ` (2 more replies) 2012-10-31 15:02 ` Matthew Garrett 1 sibling, 3 replies; 224+ messages in thread From: Josh Boyer @ 2012-10-31 14:54 UTC (permalink / raw) To: Jiri Kosina Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 10:50 AM, Jiri Kosina <jkosina@suse.cz> wrote: > On Mon, 29 Oct 2012, Matthew Garrett wrote: > >> > > This is pretty much identical to the first patchset, but with the capability >> > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants >> > > to deploy these then they should disable kexec until support for signed >> > > kexec payloads has been merged. >> > >> > Apparently your patchset currently doesn't handle device firmware loading, >> > nor do you seem to mention in in the comments. >> >> Correct. >> >> > I believe signed firmware loading should be put on plate as well, right? >> >> I think that's definitely something that should be covered. I hadn't >> worried about it immediately as any attack would be limited to machines >> with a specific piece of hardware, and the attacker would need to expend >> a significant amount of reverse engineering work on the firmware - and >> we'd probably benefit from them doing that in the long run... > > Now -- how about resuming from S4? > > Reading stored memory image (potentially tampered before reboot) from disk > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > able to imagine a scenario how this could be made "secure" (without > storing private keys to sign the hibernation image on the machine itself > which, well, doesn't sound secure either). I have a patch that disables that. I imagine it will be included in the next submission of the patchset. You can find it here in the meantime: http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch josh ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 14:54 ` Josh Boyer @ 2012-10-31 14:59 ` Shea Levy 2012-10-31 15:55 ` Alan Cox 2012-10-31 16:04 ` Jiri Kosina 2 siblings, 0 replies; 224+ messages in thread From: Shea Levy @ 2012-10-31 14:59 UTC (permalink / raw) To: Josh Boyer Cc: Jiri Kosina, Matthew Garrett, linux-kernel, linux-security-module, linux-efi On 10/31/2012 10:54 AM, Josh Boyer wrote: > On Wed, Oct 31, 2012 at 10:50 AM, Jiri Kosina <jkosina@suse.cz> wrote: >> On Mon, 29 Oct 2012, Matthew Garrett wrote: >> >>>>> This is pretty much identical to the first patchset, but with the capability >>>>> renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants >>>>> to deploy these then they should disable kexec until support for signed >>>>> kexec payloads has been merged. >>>> Apparently your patchset currently doesn't handle device firmware loading, >>>> nor do you seem to mention in in the comments. >>> Correct. >>> >>>> I believe signed firmware loading should be put on plate as well, right? >>> I think that's definitely something that should be covered. I hadn't >>> worried about it immediately as any attack would be limited to machines >>> with a specific piece of hardware, and the attacker would need to expend >>> a significant amount of reverse engineering work on the firmware - and >>> we'd probably benefit from them doing that in the long run... >> Now -- how about resuming from S4? >> >> Reading stored memory image (potentially tampered before reboot) from disk >> is basically DMA-ing arbitrary data over the whole RAM. I am currently not >> able to imagine a scenario how this could be made "secure" (without >> storing private keys to sign the hibernation image on the machine itself >> which, well, doesn't sound secure either). > I have a patch that disables that. I imagine it will be included in the > next submission of the patchset. > > You can find it here in the meantime: > > http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch > > josh > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Perhaps this is overkill and too efi-specific, but on systems (like efi) where there is firmware-manged storage that is protected from unsigned access (e.g. efi vars), couldn't the kernel store a hash of the hibernation image in that storage? ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 14:54 ` Josh Boyer 2012-10-31 14:59 ` Shea Levy @ 2012-10-31 15:55 ` Alan Cox 2012-10-31 15:55 ` Jiri Kosina 2012-10-31 15:56 ` Matthew Garrett 2012-10-31 16:04 ` Jiri Kosina 2 siblings, 2 replies; 224+ messages in thread From: Alan Cox @ 2012-10-31 15:55 UTC (permalink / raw) To: Josh Boyer Cc: Jiri Kosina, Matthew Garrett, linux-kernel, linux-security-module, linux-efi > > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > > able to imagine a scenario how this could be made "secure" (without > > storing private keys to sign the hibernation image on the machine itself > > which, well, doesn't sound secure either). That's what the TPM is for (in fact all of this stuff can be done properly with a TPM while the 'secure' boot stuff can do little if any of it. > > I have a patch that disables that. I imagine it will be included in the > next submission of the patchset. > > You can find it here in the meantime: > > http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch All this depends on your threat model. If I have physical access to suspend/resume your machine then you already lost. If I don't have physical access then I can't boot my unsigned OS to patch your S4 image so it doesn't matter. In fact the more I think about this the more it seems disabling hibernate is basically farting in the wind. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:55 ` Alan Cox @ 2012-10-31 15:55 ` Jiri Kosina 2012-10-31 17:03 ` Alan Cox 2012-10-31 15:56 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-10-31 15:55 UTC (permalink / raw) To: Alan Cox Cc: Josh Boyer, Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012, Alan Cox wrote: > All this depends on your threat model. If I have physical access to > suspend/resume your machine then you already lost. If I don't have > physical access then I can't boot my unsigned OS to patch your S4 image > so it doesn't matter. Prepare (as a root) a hand-crafted image, reboot, let the kernel resume from that artificial image. It can be viewed as a very obscure way of rewriting the kernel through /dev/mem (which is obviously not possible when in 'secure boot' environment). -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:55 ` Jiri Kosina @ 2012-10-31 17:03 ` Alan Cox 2012-10-31 17:01 ` Shea Levy 2012-10-31 17:10 ` Matthew Garrett 0 siblings, 2 replies; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:03 UTC (permalink / raw) To: Jiri Kosina Cc: Josh Boyer, Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012 16:55:04 +0100 (CET) Jiri Kosina <jkosina@suse.cz> wrote: > On Wed, 31 Oct 2012, Alan Cox wrote: > > > All this depends on your threat model. If I have physical access to > > suspend/resume your machine then you already lost. If I don't have > > physical access then I can't boot my unsigned OS to patch your S4 image > > so it doesn't matter. > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume > from that artificial image. It's not signed. It won't reboot from that image. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:03 ` Alan Cox @ 2012-10-31 17:01 ` Shea Levy 2012-10-31 17:17 ` Alan Cox 2012-10-31 17:10 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Shea Levy @ 2012-10-31 17:01 UTC (permalink / raw) To: Alan Cox Cc: Jiri Kosina, Josh Boyer, Matthew Garrett, linux-kernel, linux-security-module, linux-efi On 10/31/2012 01:03 PM, Alan Cox wrote: > On Wed, 31 Oct 2012 16:55:04 +0100 (CET) > Jiri Kosina <jkosina@suse.cz> wrote: > >> On Wed, 31 Oct 2012, Alan Cox wrote: >> >>> All this depends on your threat model. If I have physical access to >>> suspend/resume your machine then you already lost. If I don't have >>> physical access then I can't boot my unsigned OS to patch your S4 image >>> so it doesn't matter. >> Prepare (as a root) a hand-crafted image, reboot, let the kernel resume >> from that artificial image. > It's not signed. It won't reboot from that image. So then to hibernate the kernel must have a signing key? > Alan > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:01 ` Shea Levy @ 2012-10-31 17:17 ` Alan Cox 0 siblings, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:17 UTC (permalink / raw) To: Shea Levy Cc: Jiri Kosina, Josh Boyer, Matthew Garrett, linux-kernel, linux-security-module, linux-efi > >> Prepare (as a root) a hand-crafted image, reboot, let the kernel resume > >> from that artificial image. > > It's not signed. It won't reboot from that image. > > So then to hibernate the kernel must have a signing key? No. If you break the kernel so you can patch swap we already lost. If you add a new bootable image and reboot your image won't boot anyway If you've got physical access you've already won So you can't break the swap image before hibernation. You can't boot something else to tamper with it and you've not got physical access. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:03 ` Alan Cox 2012-10-31 17:01 ` Shea Levy @ 2012-10-31 17:10 ` Matthew Garrett 2012-10-31 17:21 ` Alan Cox 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:10 UTC (permalink / raw) To: Alan Cox Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 05:03:34PM +0000, Alan Cox wrote: > On Wed, 31 Oct 2012 16:55:04 +0100 (CET) > Jiri Kosina <jkosina@suse.cz> wrote: > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume > > from that artificial image. > > It's not signed. It won't reboot from that image. The kernel is signed. The kernel doesn't check the signature on the suspend image. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:10 ` Matthew Garrett @ 2012-10-31 17:21 ` Alan Cox 2012-10-31 17:17 ` Matthew Garrett 2012-10-31 17:21 ` Jiri Kosina 0 siblings, 2 replies; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:21 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012 17:10:48 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Wed, Oct 31, 2012 at 05:03:34PM +0000, Alan Cox wrote: > > On Wed, 31 Oct 2012 16:55:04 +0100 (CET) > > Jiri Kosina <jkosina@suse.cz> wrote: > > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume > > > from that artificial image. > > > > It's not signed. It won't reboot from that image. > > The kernel is signed. The kernel doesn't check the signature on the > suspend image. Which doesn't matter. How are you going to create the tampered image in the first place ? ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:21 ` Alan Cox @ 2012-10-31 17:17 ` Matthew Garrett 2012-10-31 17:39 ` Alan Cox 2012-10-31 17:21 ` Jiri Kosina 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:17 UTC (permalink / raw) To: Alan Cox Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 05:21:21PM +0000, Alan Cox wrote: > On Wed, 31 Oct 2012 17:10:48 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > The kernel is signed. The kernel doesn't check the signature on the > > suspend image. > > Which doesn't matter. How are you going to create the tampered image in > the first place ? By booting a signed kernel, not turning on swap and writing directly to the swap partition. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:17 ` Matthew Garrett @ 2012-10-31 17:39 ` Alan Cox 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 20:14 ` Oliver Neukum 0 siblings, 2 replies; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:39 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012 17:17:43 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Wed, Oct 31, 2012 at 05:21:21PM +0000, Alan Cox wrote: > > On Wed, 31 Oct 2012 17:10:48 +0000 > > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > The kernel is signed. The kernel doesn't check the signature on the > > > suspend image. > > > > Which doesn't matter. How are you going to create the tampered image in > > the first place ? > > By booting a signed kernel, not turning on swap and writing directly to > the swap partition. Ok so the actual problem is that you are signing kernels that allow the user to skip the S4 resume check ? ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:39 ` Alan Cox @ 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 17:49 ` Alan Cox 2012-10-31 20:14 ` Oliver Neukum 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:37 UTC (permalink / raw) To: Alan Cox Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 05:39:19PM +0000, Alan Cox wrote: > On Wed, 31 Oct 2012 17:17:43 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > By booting a signed kernel, not turning on swap and writing directly to > > the swap partition. > > Ok so the actual problem is that you are signing kernels that allow the > user to skip the S4 resume check ? What S4 resume check? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:37 ` Matthew Garrett @ 2012-10-31 17:49 ` Alan Cox 2012-10-31 17:45 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:49 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012 17:37:50 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Wed, Oct 31, 2012 at 05:39:19PM +0000, Alan Cox wrote: > > On Wed, 31 Oct 2012 17:17:43 +0000 > > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > By booting a signed kernel, not turning on swap and writing directly to > > > the swap partition. > > > > Ok so the actual problem is that you are signing kernels that allow the > > user to skip the S4 resume check ? > > What S4 resume check? One you would add .. but no I'm wrong there - its a problem at the suspend point so you do need a signature for it. Oh well yet another reason it's nto useful. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:49 ` Alan Cox @ 2012-10-31 17:45 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:45 UTC (permalink / raw) To: Alan Cox Cc: Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 05:49:19PM +0000, Alan Cox wrote: > On Wed, 31 Oct 2012 17:37:50 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > What S4 resume check? > > One you would add .. but no I'm wrong there - its a problem at the > suspend point so you do need a signature for it. Oh well yet another > reason it's nto useful. Right. Hence the idea of a protected keystore at boot time. We can do this securely, but it does involve writing code. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:39 ` Alan Cox 2012-10-31 17:37 ` Matthew Garrett @ 2012-10-31 20:14 ` Oliver Neukum 2012-10-31 21:58 ` Chris Friesen 1 sibling, 1 reply; 224+ messages in thread From: Oliver Neukum @ 2012-10-31 20:14 UTC (permalink / raw) To: Alan Cox Cc: Matthew Garrett, Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wednesday 31 October 2012 17:39:19 Alan Cox wrote: > On Wed, 31 Oct 2012 17:17:43 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > On Wed, Oct 31, 2012 at 05:21:21PM +0000, Alan Cox wrote: > > > On Wed, 31 Oct 2012 17:10:48 +0000 > > > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > > The kernel is signed. The kernel doesn't check the signature on the > > > > suspend image. > > > > > > Which doesn't matter. How are you going to create the tampered image in > > > the first place ? > > > > By booting a signed kernel, not turning on swap and writing directly to > > the swap partition. > > Ok so the actual problem is that you are signing kernels that allow the > user to skip the S4 resume check ? No. The problem is principal in nature. swapoff /dev/sdb6 ; dd if=/tmp/malicious_image of=/dev/sdb6 ; sync ; reboot That would do it on my system. Maybe in theory you could solve this by the kernel invalidating images it hasn't written itself and forbidding to change the resume partition from the kernel command line, but that would break user space hibernation. Regards Oliver ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 20:14 ` Oliver Neukum @ 2012-10-31 21:58 ` Chris Friesen 2012-10-31 22:00 ` Jiri Kosina 2012-10-31 22:19 ` Oliver Neukum 0 siblings, 2 replies; 224+ messages in thread From: Chris Friesen @ 2012-10-31 21:58 UTC (permalink / raw) To: Oliver Neukum Cc: Alan Cox, Matthew Garrett, Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 10/31/2012 02:14 PM, Oliver Neukum wrote: > On Wednesday 31 October 2012 17:39:19 Alan Cox wrote: >> On Wed, 31 Oct 2012 17:17:43 +0000 >> Matthew Garrett<mjg59@srcf.ucam.org> wrote: >> >>> On Wed, Oct 31, 2012 at 05:21:21PM +0000, Alan Cox wrote: >>>> On Wed, 31 Oct 2012 17:10:48 +0000 >>>> Matthew Garrett<mjg59@srcf.ucam.org> wrote: >>>>> The kernel is signed. The kernel doesn't check the signature on the >>>>> suspend image. >>>> >>>> Which doesn't matter. How are you going to create the tampered image in >>>> the first place ? >>> >>> By booting a signed kernel, not turning on swap and writing directly to >>> the swap partition. >> >> Ok so the actual problem is that you are signing kernels that allow the >> user to skip the S4 resume check ? > > No. The problem is principal in nature. > > swapoff /dev/sdb6 ; dd if=/tmp/malicious_image of=/dev/sdb6 ; sync ; reboot > > That would do it on my system. > Maybe in theory you could solve this by the kernel invalidating images > it hasn't written itself and forbidding to change the resume partition from the > kernel command line, but that would break user space hibernation. If the resuming kernel refuses to resume from images it didn't create itself, why do you need to forbid changing the resume partition from the kernel command line? Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 21:58 ` Chris Friesen @ 2012-10-31 22:00 ` Jiri Kosina 2012-10-31 22:19 ` Oliver Neukum 1 sibling, 0 replies; 224+ messages in thread From: Jiri Kosina @ 2012-10-31 22:00 UTC (permalink / raw) To: Chris Friesen Cc: Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012, Chris Friesen wrote: > > That would do it on my system. > > Maybe in theory you could solve this by the kernel invalidating images > > it hasn't written itself and forbidding to change the resume partition from > > the > > kernel command line, but that would break user space hibernation. > > If the resuming kernel refuses to resume from images it didn't create itself, > why do you need to forbid changing the resume partition from the kernel > command line? Yeah, it can definitely be solved by pushing keys around from shim to kernel (and kernel discarding the private keys at right moments). It just needs to be implemented. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 21:58 ` Chris Friesen 2012-10-31 22:00 ` Jiri Kosina @ 2012-10-31 22:19 ` Oliver Neukum 2012-11-01 9:08 ` James Bottomley 1 sibling, 1 reply; 224+ messages in thread From: Oliver Neukum @ 2012-10-31 22:19 UTC (permalink / raw) To: Chris Friesen Cc: Alan Cox, Matthew Garrett, Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote: > On 10/31/2012 02:14 PM, Oliver Neukum wrote: > > That would do it on my system. > > Maybe in theory you could solve this by the kernel invalidating images > > it hasn't written itself and forbidding to change the resume partition from the > > kernel command line, but that would break user space hibernation. > > If the resuming kernel refuses to resume from images it didn't create > itself, why do you need to forbid changing the resume partition from the > kernel command line? You don't. Signed images solve the problem. I was responding to Alan's assertation that the problem could be solved without signing the images. It turns out tht any such scheme would have unacceptable limitations. The key problem is actually safely storing the public key needed to verify the signature. This problem is also solvable. It just needs help from the UEFI infrastructure. Regards Oliver ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 22:19 ` Oliver Neukum @ 2012-11-01 9:08 ` James Bottomley 2012-11-01 9:20 ` Jiri Kosina 2012-11-01 10:12 ` Oliver Neukum 0 siblings, 2 replies; 224+ messages in thread From: James Bottomley @ 2012-11-01 9:08 UTC (permalink / raw) To: Oliver Neukum Cc: Chris Friesen, Alan Cox, Matthew Garrett, Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 2012-10-31 at 23:19 +0100, Oliver Neukum wrote: > On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote: > > On 10/31/2012 02:14 PM, Oliver Neukum wrote: > > > > That would do it on my system. > > > Maybe in theory you could solve this by the kernel invalidating images > > > it hasn't written itself and forbidding to change the resume partition from the > > > kernel command line, but that would break user space hibernation. > > > > If the resuming kernel refuses to resume from images it didn't create > > itself, why do you need to forbid changing the resume partition from the > > kernel command line? > > You don't. Signed images solve the problem. I really don't think they do. The proposed attack vector is to try to prevent a local root exploit from running arbitrary in-kernel code, because that would compromise the secure boot part of the kernel. I really think that's mythical: a local privilege elevation attack usually exploits some bug (classically a buffer overflow) which executes arbitrary code in kernel context. In that case, the same attack vector can be used to compromise any in-kernel protection mechanism including turning off the secure boot capability and reading the in-kernel private signing key. There have been one or two privilege elevation attacks that didn't involve in-kernel code (usually by compromising a suid binary or other cross domain scripting attack) that would only compromise local root and thus be confined to the secure boot prison but they are, historically, a minority. The point I'm making is that given that the majority of exploits will already be able to execute arbitrary code in-kernel, there's not much point trying to consider features like this as attacker prevention. We should really be focusing on discussing why we'd want to prevent a legitimate local root from writing to the suspend partition in a secure boot environment. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:08 ` James Bottomley @ 2012-11-01 9:20 ` Jiri Kosina 2012-11-01 9:38 ` James Bottomley 2012-11-01 10:12 ` Oliver Neukum 1 sibling, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-01 9:20 UTC (permalink / raw) To: James Bottomley Cc: Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012, James Bottomley wrote: > The point I'm making is that given that the majority of exploits will > already be able to execute arbitrary code in-kernel, there's not much > point trying to consider features like this as attacker prevention. We > should really be focusing on discussing why we'd want to prevent a > legitimate local root from writing to the suspend partition in a secure > boot environment. Well, this is being repeated over and over again when talking about secure boot, right? My understanding is that we are not trying to protect against root exploiting the kernel. We are trying to protect against root tampering with the kernel code and data through legitimate use of kernel-provided facilitiies (/dev/mem, ioperm, reprogramming devices to DMA to arbitrary memory locations, resuming from hibernation image that has been tampered with, etc). Or perhaps I just misunderstood the point you were trying to make? Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:20 ` Jiri Kosina @ 2012-11-01 9:38 ` James Bottomley 2012-11-01 9:45 ` Jiri Kosina 0 siblings, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-01 9:38 UTC (permalink / raw) To: Jiri Kosina Cc: Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 10:20 +0100, Jiri Kosina wrote: > On Thu, 1 Nov 2012, James Bottomley wrote: > > > The point I'm making is that given that the majority of exploits will > > already be able to execute arbitrary code in-kernel, there's not much > > point trying to consider features like this as attacker prevention. We > > should really be focusing on discussing why we'd want to prevent a > > legitimate local root from writing to the suspend partition in a secure > > boot environment. > > Well, this is being repeated over and over again when talking about secure > boot, right? > > My understanding is that we are not trying to protect against root > exploiting the kernel. We are trying to protect against root tampering > with the kernel code and data through legitimate use of kernel-provided > facilitiies (/dev/mem, ioperm, reprogramming devices to DMA to arbitrary > memory locations, resuming from hibernation image that has been tampered > with, etc). > > Or perhaps I just misunderstood the point you were trying to make? I'm actually just struggling to understand the use case for these more esoteric protections. So the assumption is malice on the part of a legitimate local root? I just don't see what such a user would gain by compromising resume in this way (given that their scope for damage in the rest of the system and data is huge) and I don't really see why a non-malicious local root would be interested. A legitimate local root entails quite a measure of trust, so what I don't really see is the use case for investing all that trust in someone but not trusting them with the boot system. In a proper capability separated limited trust environment, you simply don't allow less trusted users raw access to all or some devices and that solves the problem far more simply. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:38 ` James Bottomley @ 2012-11-01 9:45 ` Jiri Kosina 2012-11-01 9:59 ` James Bottomley 0 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-01 9:45 UTC (permalink / raw) To: James Bottomley Cc: Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012, James Bottomley wrote: > I'm actually just struggling to understand the use case for these more > esoteric protections. I believe the real point is drawing a clear line between trusted and untrusted (with root being userspace, hence implicitly untrusted), and disallowing "legitimate crossing" of this line. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:45 ` Jiri Kosina @ 2012-11-01 9:59 ` James Bottomley 2012-11-01 10:06 ` Jiri Kosina 2012-11-01 14:29 ` Eric Paris 0 siblings, 2 replies; 224+ messages in thread From: James Bottomley @ 2012-11-01 9:59 UTC (permalink / raw) To: Jiri Kosina Cc: Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 10:45 +0100, Jiri Kosina wrote: > On Thu, 1 Nov 2012, James Bottomley wrote: > > > I'm actually just struggling to understand the use case for these more > > esoteric protections. > > I believe the real point is drawing a clear line between trusted and > untrusted (with root being userspace, hence implicitly untrusted), and > disallowing "legitimate crossing" of this line. But that doesn't really help me: untrusted root is an oxymoron. I get capability separated systems, where you invest trust in layers and you make each layer small and verifiable, so you have a granular trust policy you build up. I really don't understand the use case for trying to remove a small portion of trust from the huge trust domain of root and then doing a massive amount of fixup around the edges because there's leaks all over the place from the trust that root still has. It all seems to be a bit backwards. If you just begin with the capability separated granular system, I don't see why it doesn't all just work with what we have today. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:59 ` James Bottomley @ 2012-11-01 10:06 ` Jiri Kosina 2012-11-01 14:29 ` Eric Paris 1 sibling, 0 replies; 224+ messages in thread From: Jiri Kosina @ 2012-11-01 10:06 UTC (permalink / raw) To: James Bottomley Cc: Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012, James Bottomley wrote: > > > I'm actually just struggling to understand the use case for these more > > > esoteric protections. > > > > I believe the real point is drawing a clear line between trusted and > > untrusted (with root being userspace, hence implicitly untrusted), and > > disallowing "legitimate crossing" of this line. > > But that doesn't really help me: untrusted root is an oxymoron. I get > capability separated systems, where you invest trust in layers and you > make each layer small and verifiable, so you have a granular trust > policy you build up. I really don't understand the use case for trying > to remove a small portion of trust from the huge trust domain of root > and then doing a massive amount of fixup around the edges because > there's leaks all over the place from the trust that root still has. It > all seems to be a bit backwards. If you just begin with the capability > separated granular system, I don't see why it doesn't all just work with > what we have today. Please don't get me wrong -- I personally don't believe in the secure boot stuff at all. But if you take the secure/trusted boot as a basic paradigma, then you really need the separation. In such model, the root is untrusted, exactly because the code running under those privileges hasn't been signed, period. If you allow such code to modify the trusted/signed code, you just basically violate the complete model, rendering it completely moot. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:59 ` James Bottomley 2012-11-01 10:06 ` Jiri Kosina @ 2012-11-01 14:29 ` Eric Paris 2012-11-01 14:42 ` James Bottomley ` (3 more replies) 1 sibling, 4 replies; 224+ messages in thread From: Eric Paris @ 2012-11-01 14:29 UTC (permalink / raw) To: James Bottomley Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > But that doesn't really help me: untrusted root is an oxymoron. Imagine you run windows and you've never heard of Linux. You like that only windows kernels can boot on your box and not those mean nasty hacked up malware kernels. Now some attacker manages to take over your box because you clicked on that executable for young models in skimpy bathing suits. That executable rewrote your bootloader to launch a very small carefully crafted Linux environment. This environment does nothing but launch a perfectly valid signed Linux kernel, which gets a Windows environment all ready to launch after resume and goes to sleep. Now you have to hit the power button twice every time you turn on your computer, weird, but Windows comes up, and secureboot is still on, so you must be safe! In this case we have a completely 'untrusted' root inside Linux. From the user PoV root and Linux are both malware. Notice the EXACT same attack would work launching rootkit'd Linux from Linux. So don't pretend not to care about Windows. It's just that launching malware Linux seems like a reason to get your key revoked. We don't want signed code which can be used as an attack vector on ourselves or on others. That make sense? -Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:29 ` Eric Paris @ 2012-11-01 14:42 ` James Bottomley 2012-11-01 14:49 ` Matthew Garrett 2012-11-01 14:59 ` Eric Paris 2012-11-01 14:46 ` Alan Cox ` (2 subsequent siblings) 3 siblings, 2 replies; 224+ messages in thread From: James Bottomley @ 2012-11-01 14:42 UTC (permalink / raw) To: Eric Paris Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote: > On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > But that doesn't really help me: untrusted root is an oxymoron. > > Imagine you run windows and you've never heard of Linux. You like > that only windows kernels can boot on your box and not those mean > nasty hacked up malware kernels. Now some attacker manages to take > over your box because you clicked on that executable for young models > in skimpy bathing suits. That executable rewrote your bootloader to > launch a very small carefully crafted Linux environment. This > environment does nothing but launch a perfectly valid signed Linux > kernel, which gets a Windows environment all ready to launch after > resume and goes to sleep. Now you have to hit the power button twice > every time you turn on your computer, weird, but Windows comes up, and > secureboot is still on, so you must be safe! So you're going back to the root exploit problem? I thought that was debunked a few emails ago in the thread? Your attack vector isn't plausible because for the suspend attack to work, the box actually has to be running Linux by default ... I think the admin of that box might notice if it suddenly started running windows ... > In this case we have a completely 'untrusted' root inside Linux. From > the user PoV root and Linux are both malware. Notice the EXACT same > attack would work launching rootkit'd Linux from Linux. So don't > pretend not to care about Windows. It's just that launching malware > Linux seems like a reason to get your key revoked. We don't want > signed code which can be used as an attack vector on ourselves or on > others. > > That make sense? Not really, no. A windows attack vector is a pointless abstraction because we're talking about securing Linux and your vector requires a Linux attack for the windows compromise ... let's try to keep on point to how we're using this feature to secure Linux. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:42 ` James Bottomley @ 2012-11-01 14:49 ` Matthew Garrett 2012-11-01 15:06 ` James Bottomley 2012-11-01 15:06 ` Alan Cox 2012-11-01 14:59 ` Eric Paris 1 sibling, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 14:49 UTC (permalink / raw) To: James Bottomley Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 02:42:15PM +0000, James Bottomley wrote: > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote: > > Imagine you run windows and you've never heard of Linux. You like > > that only windows kernels can boot on your box and not those mean > > nasty hacked up malware kernels. Now some attacker manages to take > > over your box because you clicked on that executable for young models > > in skimpy bathing suits. That executable rewrote your bootloader to > > launch a very small carefully crafted Linux environment. This > > environment does nothing but launch a perfectly valid signed Linux > > kernel, which gets a Windows environment all ready to launch after > > resume and goes to sleep. Now you have to hit the power button twice > > every time you turn on your computer, weird, but Windows comes up, and > > secureboot is still on, so you must be safe! > > So you're going back to the root exploit problem? I thought that was > debunked a few emails ago in the thread? The entire point of this feature is that it's no longer possible to turn a privileged user exploit into a full system exploit. Gaining admin access on Windows 8 doesn't permit you to install a persistent backdoor, unless there's some way to circumvent that. Which there is, if you can drop a small Linux distribution onto the ESP and use a signed, trusted bootloader to boot a signed, trusted kernel that then resumes from an unsigned, untrusted hibernate image. So we have to ensure that that's impossible. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:49 ` Matthew Garrett @ 2012-11-01 15:06 ` James Bottomley 2012-11-01 15:17 ` Eric Paris 2012-11-01 16:26 ` Matthew Garrett 2012-11-01 15:06 ` Alan Cox 1 sibling, 2 replies; 224+ messages in thread From: James Bottomley @ 2012-11-01 15:06 UTC (permalink / raw) To: Matthew Garrett Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 14:49 +0000, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 02:42:15PM +0000, James Bottomley wrote: > > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote: > > > Imagine you run windows and you've never heard of Linux. You like > > > that only windows kernels can boot on your box and not those mean > > > nasty hacked up malware kernels. Now some attacker manages to take > > > over your box because you clicked on that executable for young models > > > in skimpy bathing suits. That executable rewrote your bootloader to > > > launch a very small carefully crafted Linux environment. This > > > environment does nothing but launch a perfectly valid signed Linux > > > kernel, which gets a Windows environment all ready to launch after > > > resume and goes to sleep. Now you have to hit the power button twice > > > every time you turn on your computer, weird, but Windows comes up, and > > > secureboot is still on, so you must be safe! > > > > So you're going back to the root exploit problem? I thought that was > > debunked a few emails ago in the thread? > > The entire point of this feature is that it's no longer possible to turn > a privileged user exploit into a full system exploit. Gaining admin > access on Windows 8 doesn't permit you to install a persistent backdoor, > unless there's some way to circumvent that. Which there is, if you can > drop a small Linux distribution onto the ESP and use a signed, trusted > bootloader to boot a signed, trusted kernel that then resumes from an > unsigned, untrusted hibernate image. So we have to ensure that that's > impossible. But surely that's fanciful ... you've already compromised windows to get access to the ESP. If you've done it once, you can do it again until the exploit is patched. There are likely many easier ways of ensuring persistence than trying to install a full linux kernel with a compromised resume system. If this could be used to attack a windows system in the first place, then Microsoft might be annoyed, but you have to compromise windows *first* in this scenario. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 15:06 ` James Bottomley @ 2012-11-01 15:17 ` Eric Paris 2012-11-01 16:26 ` Matthew Garrett 1 sibling, 0 replies; 224+ messages in thread From: Eric Paris @ 2012-11-01 15:17 UTC (permalink / raw) To: James Bottomley Cc: Matthew Garrett, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 1, 2012 at 11:06 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > But surely that's fanciful ... you've already compromised windows to get > access to the ESP. If you've done it once, you can do it again until > the exploit is patched. You work under the assumption that any bad operation was done by means of a compromised kernel. Admins install things all the time, sometimes, things which they shouldn't. (This statement is OS agnostic) > There are likely many easier ways of ensuring > persistence than trying to install a full linux kernel with a > compromised resume system. I'm sure lots of us would love to hear the ideas. And the attack is on the suspend side, nothing about resume has to be malicious (not really relevant I guess)... ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 15:06 ` James Bottomley 2012-11-01 15:17 ` Eric Paris @ 2012-11-01 16:26 ` Matthew Garrett 1 sibling, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 16:26 UTC (permalink / raw) To: James Bottomley Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 03:06:30PM +0000, James Bottomley wrote: > But surely that's fanciful ... you've already compromised windows to get > access to the ESP. If you've done it once, you can do it again until > the exploit is patched. There are likely many easier ways of ensuring > persistence than trying to install a full linux kernel with a > compromised resume system. There's a pretty strong distinction between "Machine is exploited until exploit is patched" and "Machine is exploited until drive is replaced". -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:49 ` Matthew Garrett 2012-11-01 15:06 ` James Bottomley @ 2012-11-01 15:06 ` Alan Cox 2012-11-01 16:29 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 15:06 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi > The entire point of this feature is that it's no longer possible to turn > a privileged user exploit into a full system exploit. Gaining admin > access on Windows 8 doesn't permit you to install a persistent backdoor, Really, that would be a first. Do you have a detailed knowledge of windows 8 actual security ? > unless there's some way to circumvent that. Which there is, if you can > drop a small Linux distribution onto the ESP and use a signed, trusted > bootloader to boot a signed, trusted kernel that then resumes from an > unsigned, untrusted hibernate image. So we have to ensure that that's > impossible. Well if you want to make Linux entirely robust Red Hat could start helping with some of the 6000 odd coverity matches some of which will most certainly turn out to be real flaws. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 15:06 ` Alan Cox @ 2012-11-01 16:29 ` Matthew Garrett 2012-11-01 16:40 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 16:29 UTC (permalink / raw) To: Alan Cox Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 03:06:54PM +0000, Alan Cox wrote: > > The entire point of this feature is that it's no longer possible to turn > > a privileged user exploit into a full system exploit. Gaining admin > > access on Windows 8 doesn't permit you to install a persistent backdoor, > > Really, that would be a first. Do you have a detailed knowledge of > windows 8 actual security ? http://msdn.microsoft.com/en-us/library/windows/desktop/hh848061%28v=vs.85%29.aspx > > unless there's some way to circumvent that. Which there is, if you can > > drop a small Linux distribution onto the ESP and use a signed, trusted > > bootloader to boot a signed, trusted kernel that then resumes from an > > unsigned, untrusted hibernate image. So we have to ensure that that's > > impossible. > > Well if you want to make Linux entirely robust Red Hat could start > helping with some of the 6000 odd coverity matches some of which will > most certainly turn out to be real flaws. Sure, bugs should be fixed. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 16:29 ` Matthew Garrett @ 2012-11-01 16:40 ` Alan Cox 0 siblings, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-01 16:40 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012 16:29:01 +0000 Matthew Garrett <mjg@redhat.com> wrote: > On Thu, Nov 01, 2012 at 03:06:54PM +0000, Alan Cox wrote: > > > The entire point of this feature is that it's no longer possible to turn > > > a privileged user exploit into a full system exploit. Gaining admin > > > access on Windows 8 doesn't permit you to install a persistent backdoor, > > > > Really, that would be a first. Do you have a detailed knowledge of > > windows 8 actual security ? > > http://msdn.microsoft.com/en-us/library/windows/desktop/hh848061%28v=vs.85%29.aspx No I said knowledge of not web pages. The Red Hat pages say Linux is very secure, the Apple ones say MacOS is. The point being you don't want to evaluate apparent security by press release of one system versus deep internal knowledge of the other. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:42 ` James Bottomley 2012-11-01 14:49 ` Matthew Garrett @ 2012-11-01 14:59 ` Eric Paris 2012-11-01 15:11 ` Alan Cox 2012-11-01 15:18 ` James Bottomley 1 sibling, 2 replies; 224+ messages in thread From: Eric Paris @ 2012-11-01 14:59 UTC (permalink / raw) To: James Bottomley Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote: >> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley >> <James.Bottomley@hansenpartnership.com> wrote: >> >> > But that doesn't really help me: untrusted root is an oxymoron. >> >> Imagine you run windows and you've never heard of Linux. You like >> that only windows kernels can boot on your box and not those mean >> nasty hacked up malware kernels. Now some attacker manages to take >> over your box because you clicked on that executable for young models >> in skimpy bathing suits. That executable rewrote your bootloader to >> launch a very small carefully crafted Linux environment. This >> environment does nothing but launch a perfectly valid signed Linux >> kernel, which gets a Windows environment all ready to launch after >> resume and goes to sleep. Now you have to hit the power button twice >> every time you turn on your computer, weird, but Windows comes up, and >> secureboot is still on, so you must be safe! > > So you're going back to the root exploit problem? I thought that was > debunked a few emails ago in the thread? > > Your attack vector isn't plausible because for the suspend attack to > work, the box actually has to be running Linux by default ... I think > the admin of that box might notice if it suddenly started running > windows ... Maybe you misread. The owner of the box would never know a shim Linux was loaded. In any case, as I said, windows really is irrelevant. It's just using Linux as an attack vectore against Windows is what would get keys revoked. If your key is revoke Linux can't boot on a large amount of new hardware without BIOS twiddling.u >> In this case we have a completely 'untrusted' root inside Linux. From >> the user PoV root and Linux are both malware. Notice the EXACT same >> attack would work launching rootkit'd Linux from Linux. So don't >> pretend not to care about Windows. It's just that launching malware >> Linux seems like a reason to get your key revoked. We don't want >> signed code which can be used as an attack vector on ourselves or on >> others. >> >> That make sense? > > Not really, no. A windows attack vector is a pointless abstraction > because we're talking about securing Linux and your vector requires a > Linux attack for the windows compromise ... let's try to keep on point > to how we're using this feature to secure Linux. I pointed out that the exact same attack exists with Linux on Linux. To launch a malware linux kernel all you have to do is launch a shim signed acceptable linux environment, have it set up the malware kernel to launch after resume, and go to sleep. Agreed, it'd be very weird that the first time you hit the power button your machine comes on and then quickly goes right back to sleep, but certainly we can envision that being ignored by many desktop users... Do you see how 'root' in the first environment is untrusted? Now you can pretend not to care because the 'original' root was trusted. But people install bad crap all the time. There are hundreds of ways to install bad software as root. Go to any site distributing rpms or debs to get that new version of mod_perl and it could install the malware kernel and shim environment. The point of secureboot is even if the admin did something which allowed his kernel to be compromised, it won't persist. Sure, secureboot moves the attack up the stack to userspace, but at least we can do something about the kernel. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:59 ` Eric Paris @ 2012-11-01 15:11 ` Alan Cox 2012-11-01 15:18 ` James Bottomley 1 sibling, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-01 15:11 UTC (permalink / raw) To: Eric Paris Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi > would get keys revoked. If your key is revoke Linux can't boot on a > large amount of new hardware without BIOS twiddling. See "live free or die". If you want to live in a world where you can't even fart before checking if the man from Microsoft will revoke your key you might as well go home now. > The point of secureboot is even if the admin did something which > allowed his kernel to be compromised, it won't persist. Sure, > secureboot moves the attack up the stack to userspace, but at least we > can do something about the kernel. Nice theory. At the end of the day I don't care if you want to produce this stuff and sell it to people. Fine, the interface proposed is clean enough that it doesn't pee on other work, but don't expect the rest of the world to follow mindlessly into your slave pit driven by your fear. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:59 ` Eric Paris 2012-11-01 15:11 ` Alan Cox @ 2012-11-01 15:18 ` James Bottomley 2012-11-01 17:50 ` Eric Paris 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-01 15:18 UTC (permalink / raw) To: Eric Paris Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 10:59 -0400, Eric Paris wrote: > On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote: > >> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley > >> <James.Bottomley@hansenpartnership.com> wrote: > >> > >> > But that doesn't really help me: untrusted root is an oxymoron. > >> > >> Imagine you run windows and you've never heard of Linux. You like > >> that only windows kernels can boot on your box and not those mean > >> nasty hacked up malware kernels. Now some attacker manages to take > >> over your box because you clicked on that executable for young models > >> in skimpy bathing suits. That executable rewrote your bootloader to > >> launch a very small carefully crafted Linux environment. This > >> environment does nothing but launch a perfectly valid signed Linux > >> kernel, which gets a Windows environment all ready to launch after > >> resume and goes to sleep. Now you have to hit the power button twice > >> every time you turn on your computer, weird, but Windows comes up, and > >> secureboot is still on, so you must be safe! > > > > So you're going back to the root exploit problem? I thought that was > > debunked a few emails ago in the thread? > > > > Your attack vector isn't plausible because for the suspend attack to > > work, the box actually has to be running Linux by default ... I think > > the admin of that box might notice if it suddenly started running > > windows ... > > Maybe you misread. The owner of the box would never know a shim Linux > was loaded. In any case, as I said, windows really is irrelevant. > It's just using Linux as an attack vectore against Windows is what > would get keys revoked. If your key is revoke Linux can't boot on a > large amount of new hardware without BIOS twiddling.u > > >> In this case we have a completely 'untrusted' root inside Linux. From > >> the user PoV root and Linux are both malware. Notice the EXACT same > >> attack would work launching rootkit'd Linux from Linux. So don't > >> pretend not to care about Windows. It's just that launching malware > >> Linux seems like a reason to get your key revoked. We don't want > >> signed code which can be used as an attack vector on ourselves or on > >> others. > >> > >> That make sense? > > > > Not really, no. A windows attack vector is a pointless abstraction > > because we're talking about securing Linux and your vector requires a > > Linux attack for the windows compromise ... let's try to keep on point > > to how we're using this feature to secure Linux. > > I pointed out that the exact same attack exists with Linux on Linux. > To launch a malware linux kernel all you have to do is launch a shim > signed acceptable linux environment, have it set up the malware kernel > to launch after resume, and go to sleep. Agreed, it'd be very weird > that the first time you hit the power button your machine comes on and > then quickly goes right back to sleep, but certainly we can envision > that being ignored by many desktop users... > > Do you see how 'root' in the first environment is untrusted? Now you > can pretend not to care because the 'original' root was trusted. But > people install bad crap all the time. There are hundreds of ways to > install bad software as root. Go to any site distributing rpms or > debs to get that new version of mod_perl and it could install the > malware kernel and shim environment. You're completely confusing two separate goals: 1. Is it possible to use secure boot to implement a security policy on Linux 2. What do we have to do anything to prevent Linux being used to attack windows which may lead to a revocation of the distro signing key. "untrusted root" is a silly answer to 1 because it's incredibly difficult to remove sufficient trust from root and still have it be trusted enough to be effective as root. The trust bound up in root is incredibly intertwined. It would be far better to start by eliminating the root user altogether and building up on the capabilities in a granular fashion for this type of lockdown. "untrusted root", if it can even be achieved, might be a sufficient condition for 2 but it's way overkill for a necessary one. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 15:18 ` James Bottomley @ 2012-11-01 17:50 ` Eric Paris 2012-11-01 21:03 ` James Bottomley 2012-11-02 17:19 ` Vivek Goyal 0 siblings, 2 replies; 224+ messages in thread From: Eric Paris @ 2012-11-01 17:50 UTC (permalink / raw) To: James Bottomley Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > You're completely confusing two separate goals: > > 1. Is it possible to use secure boot to implement a security policy > on Linux > 2. What do we have to do anything to prevent Linux being used to > attack windows which may lead to a revocation of the distro > signing key. > > "untrusted root" is a silly answer to 1 because it's incredibly > difficult to remove sufficient trust from root and still have it be > trusted enough to be effective as root. The trust bound up in root is > incredibly intertwined. It would be far better to start by eliminating > the root user altogether and building up on the capabilities in a > granular fashion for this type of lockdown. granular lockdown!? sounds like SELinux. But that certainly can't solve the problems here... I think your premise has a couple of problems. First is how you chose to word #2. Lets reword it as: What do we have to do to prevent Linux being used to attack Linux which may lead to secure boot being useless. If we accept that as #2, then we think, "What makes secure boot useless" or "What is the security goal as envisioned by secure boot." The goal of secure boot is to implement an operating system which prevents uid==0 to ring 0 escalation. That is the security policy secure boot needs to not be completely useless. And as it turns out, that security policy is useful in other situations. > "untrusted root", if it can even be achieved, might be a sufficient > condition for 2 but it's way overkill for a necessary one. But it is a condition, as specifically stated, that others have wanted long before secure boot even came to rise. I've talked with and worked with a public cloud operator who wants to prevent even a malicious root user from being able to run code in ring 0 inside their VM. The hope in that case was that in doing so they can indirectly shrink the attack surface between virtual machine and hypervisor. They hoped to limit the ways the guest could interact to only those methods the linux kernel implemented. They want to launch a vm running a kernel they chose and make sure root inside the vm could not run some other kernel or run arbitrary code in kernel space. It's wasn't something they solved completely. If it was, all of this secure boot work would be finished. Which is why we are having these discussions to understand all of the way that you an Alan seem to have to get around the secure boot restrictions. And look for solutions to retain functionality which meeting the security goal of 'prevent uid=0 to ring 0 privilege escalation. -Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 17:50 ` Eric Paris @ 2012-11-01 21:03 ` James Bottomley 2012-11-01 21:06 ` Matthew Garrett 2012-11-02 17:19 ` Vivek Goyal 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-01 21:03 UTC (permalink / raw) To: Eric Paris Cc: Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote: > On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > You're completely confusing two separate goals: > > > > 1. Is it possible to use secure boot to implement a security policy > > on Linux > > 2. What do we have to do anything to prevent Linux being used to > > attack windows which may lead to a revocation of the distro > > signing key. > > > > "untrusted root" is a silly answer to 1 because it's incredibly > > difficult to remove sufficient trust from root and still have it be > > trusted enough to be effective as root. The trust bound up in root is > > incredibly intertwined. It would be far better to start by eliminating > > the root user altogether and building up on the capabilities in a > > granular fashion for this type of lockdown. > > granular lockdown!? sounds like SELinux. But that certainly can't > solve the problems here... > > I think your premise has a couple of problems. First is how you chose > to word #2. Lets reword it as: > > What do we have to do to prevent Linux being used to attack Linux > which may lead to secure boot being useless. That's not really remotely related, is it? Microsoft doesn't really care about Linux on Linux attacks, so preventing or allowing them isn't going to get a distro key revoked. > If we accept that as #2, then we think, "What makes secure boot > useless" or "What is the security goal as envisioned by secure boot." > The goal of secure boot is to implement an operating system which > prevents uid==0 to ring 0 escalation. That is the security policy > secure boot needs to not be completely useless. And as it turns out, > that security policy is useful in other situations. Um, so all that is a rewording of what I said in 1 ... how do you take advantage of secure boot, so you're re-conflating the issues. Snip the rest because it doesn't really make sense in terms of getting the key revoked. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:03 ` James Bottomley @ 2012-11-01 21:06 ` Matthew Garrett 2012-11-01 21:14 ` James Bottomley 2012-11-01 21:31 ` Alan Cox 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 21:06 UTC (permalink / raw) To: James Bottomley Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 09:03:20PM +0000, James Bottomley wrote: > On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote: > > What do we have to do to prevent Linux being used to attack Linux > > which may lead to secure boot being useless. > > That's not really remotely related, is it? Microsoft doesn't really > care about Linux on Linux attacks, so preventing or allowing them isn't > going to get a distro key revoked. Linux vendors may care about Linux on Linux attacks. It's all fun and games until Oracle get Microsoft to revoke Red Hat's signature. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:06 ` Matthew Garrett @ 2012-11-01 21:14 ` James Bottomley 2012-11-01 21:18 ` Matthew Garrett 2012-11-01 21:31 ` Alan Cox 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-01 21:14 UTC (permalink / raw) To: Matthew Garrett Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 2012-11-01 at 21:06 +0000, Matthew Garrett wrote: > On Thu, Nov 01, 2012 at 09:03:20PM +0000, James Bottomley wrote: > > On Thu, 2012-11-01 at 13:50 -0400, Eric Paris wrote: > > > What do we have to do to prevent Linux being used to attack Linux > > > which may lead to secure boot being useless. > > > > That's not really remotely related, is it? Microsoft doesn't really > > care about Linux on Linux attacks, so preventing or allowing them isn't > > going to get a distro key revoked. > > Linux vendors may care about Linux on Linux attacks. It's all fun and > games until Oracle get Microsoft to revoke Red Hat's signature. I agree that's a possibility. However, I think the court of public opinion would pillory the first Commercial Linux Distribution that went to Microsoft for the express purpose of revoking their competition's right to boot. It would be commercial suicide. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:14 ` James Bottomley @ 2012-11-01 21:18 ` Matthew Garrett 2012-11-01 21:35 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 21:18 UTC (permalink / raw) To: James Bottomley Cc: Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 09:14:00PM +0000, James Bottomley wrote: > I agree that's a possibility. However, I think the court of public > opinion would pillory the first Commercial Linux Distribution that went > to Microsoft for the express purpose of revoking their competition's > right to boot. It would be commercial suicide. Oracle are something of a vexatious litigant as far as the court of public opinion is concerned, but even without that it could be a customer who complains. If you're personally comfortable with a specific level of security here, that's fine - but it's completely reasonable for others to feel that there are valid technical and commercial concerns to do this properly. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:18 ` Matthew Garrett @ 2012-11-01 21:35 ` Alan Cox 0 siblings, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-01 21:35 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012 21:18:59 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Nov 01, 2012 at 09:14:00PM +0000, James Bottomley wrote: > > > I agree that's a possibility. However, I think the court of public > > opinion would pillory the first Commercial Linux Distribution that went > > to Microsoft for the express purpose of revoking their competition's > > right to boot. It would be commercial suicide. > > Oracle are something of a vexatious litigant as far as the court of > public opinion is concerned, but even without that it could be a > customer who complains. If you're personally comfortable with a specific > level of security here, that's fine - but it's completely reasonable for > others to feel that there are valid technical and commercial concerns to > do this properly. The main people who really really care about this the MS key stuff is mostly irrelevant for as they won't use the Microsoft keys anyway. Microsoft will have to provide signing to all sorts of other law enforcement bodies as a responsible provider. If the FBI have a key no other government security installation will have that key in their systems. If the Chinese state has it I doubt the US government will be too keen either. All those official government trojans end up creating a big problem in the trust department. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:06 ` Matthew Garrett 2012-11-01 21:14 ` James Bottomley @ 2012-11-01 21:31 ` Alan Cox 2012-11-01 21:28 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 21:31 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi > Linux vendors may care about Linux on Linux attacks. It's all fun and > games until Oracle get Microsoft to revoke Red Hat's signature. Fear uncertainty and doubt (and if you think Oracle are going to do that I suspect your lawyers should deal with it) Alan. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:31 ` Alan Cox @ 2012-11-01 21:28 ` Matthew Garrett 2012-11-01 21:37 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 21:28 UTC (permalink / raw) To: Alan Cox Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 09:31:27PM +0000, Alan Cox wrote: > > Linux vendors may care about Linux on Linux attacks. It's all fun and > > games until Oracle get Microsoft to revoke Red Hat's signature. > > Fear uncertainty and doubt (and if you think Oracle are going to do that > I suspect your lawyers should deal with it) Lawyers won't remove blacklist entries. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:28 ` Matthew Garrett @ 2012-11-01 21:37 ` Alan Cox 2012-11-01 21:34 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 21:37 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012 21:28:43 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Nov 01, 2012 at 09:31:27PM +0000, Alan Cox wrote: > > > Linux vendors may care about Linux on Linux attacks. It's all fun and > > > games until Oracle get Microsoft to revoke Red Hat's signature. > > > > Fear uncertainty and doubt (and if you think Oracle are going to do that > > I suspect your lawyers should deal with it) > > Lawyers won't remove blacklist entries. Fear Uncertainty and Doubt Courts do, injunctions do, the possibilty of getting caught with theirs hands in the till does. But I suspect your lawyers should also deal with public comments about Oracle such as the one you've made before you make them in public 8) ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:37 ` Alan Cox @ 2012-11-01 21:34 ` Matthew Garrett 2012-11-01 21:58 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 21:34 UTC (permalink / raw) To: Alan Cox Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 09:37:51PM +0000, Alan Cox wrote: > On Thu, 1 Nov 2012 21:28:43 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > Lawyers won't remove blacklist entries. > > Fear Uncertainty and Doubt > > Courts do, injunctions do, the possibilty of getting caught with theirs > hands in the till does. I think you've misunderstood. Blacklist updates are append only. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:34 ` Matthew Garrett @ 2012-11-01 21:58 ` Alan Cox 2012-11-01 21:57 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 21:58 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, 1 Nov 2012 21:34:52 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Nov 01, 2012 at 09:37:51PM +0000, Alan Cox wrote: > > On Thu, 1 Nov 2012 21:28:43 +0000 > > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > > Lawyers won't remove blacklist entries. > > > > Fear Uncertainty and Doubt > > > > Courts do, injunctions do, the possibilty of getting caught with theirs > > hands in the till does. > > I think you've misunderstood. Blacklist updates are append only. I think you've misunderstood - thats a technical detail that merely alters the cost to the people who did something improper. If Red Hat want to ship a kernel that is very very locked down - fine. It's a business choice and maybe it'll sell to someone. The implementation is non-offensive in its mechanism for everyone else so technically I don't care, but the 'quiver before our new masters and lick their boots' stuff isn't a technical (or sane business) approach so can we cut the trying to FUD other people into doing what you believe your new master requires. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:58 ` Alan Cox @ 2012-11-01 21:57 ` Matthew Garrett 2012-11-02 8:49 ` Eric W. Biederman 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-01 21:57 UTC (permalink / raw) To: Alan Cox Cc: James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 09:58:17PM +0000, Alan Cox wrote: > On Thu, 1 Nov 2012 21:34:52 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > I think you've misunderstood. Blacklist updates are append only. > > I think you've misunderstood - thats a technical detail that merely > alters the cost to the people who did something improper. Winning a case is cold comfort if your software has been uninstallable for the years it took to get through the courts. If others want to take that risk, fine. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:57 ` Matthew Garrett @ 2012-11-02 8:49 ` Eric W. Biederman 2012-11-02 14:00 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-02 8:49 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Thu, Nov 01, 2012 at 09:58:17PM +0000, Alan Cox wrote: >> On Thu, 1 Nov 2012 21:34:52 +0000 >> Matthew Garrett <mjg59@srcf.ucam.org> wrote: >> > I think you've misunderstood. Blacklist updates are append only. >> >> I think you've misunderstood - thats a technical detail that merely >> alters the cost to the people who did something improper. > > Winning a case is cold comfort if your software has been uninstallable > for the years it took to get through the courts. If others want to take > that risk, fine. When the goal is to secure Linux I don't see how any of this helps. Windows 8 compromises are already available so if we turn most of these arguments around I am certain clever attackers can go through windows to run compromised kernel on a linux system, at least as easily as the reverse. Short of instructing UEFI to stop trusting the Microsoft signing key I don't see any of the secureboot dance gaining any security of computers running linux or security from keys being revoked for non-sense reasons. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 8:49 ` Eric W. Biederman @ 2012-11-02 14:00 ` Matthew Garrett 2012-11-02 22:03 ` Eric W. Biederman 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-02 14:00 UTC (permalink / raw) To: Eric W. Biederman Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote: > When the goal is to secure Linux I don't see how any of this helps. > Windows 8 compromises are already available so if we turn most of these > arguments around I am certain clever attackers can go through windows to > run compromised kernel on a linux system, at least as easily as the > reverse. And if any of them are used to attack Linux, we'd expect those versions of Windows to be blacklisted. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 14:00 ` Matthew Garrett @ 2012-11-02 22:03 ` Eric W. Biederman 2012-11-02 22:19 ` Chris Friesen 2012-11-03 0:20 ` Matthew Garrett 0 siblings, 2 replies; 224+ messages in thread From: Eric W. Biederman @ 2012-11-02 22:03 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote: > >> When the goal is to secure Linux I don't see how any of this helps. >> Windows 8 compromises are already available so if we turn most of these >> arguments around I am certain clever attackers can go through windows to >> run compromised kernel on a linux system, at least as easily as the >> reverse. > > And if any of them are used to attack Linux, we'd expect those versions > of Windows to be blacklisted. I fail to see the logic here. It is ok to trust Microsofts signing key because after I have been p0wned they will blacklist the version of windows that has was used to compromise my system? A key revokation will help me when my system is p0wned how? I don't want my system p0wned in the first place and I don't want to run windows. Why should I trust Microsoft's signing key? Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 22:03 ` Eric W. Biederman @ 2012-11-02 22:19 ` Chris Friesen 2012-11-02 23:46 ` Alan Cox 2012-11-03 0:20 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Chris Friesen @ 2012-11-02 22:19 UTC (permalink / raw) To: Eric W. Biederman Cc: Matthew Garrett, Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/02/2012 04:03 PM, Eric W. Biederman wrote: > Matthew Garrett<mjg59@srcf.ucam.org> writes: > >> On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote: >> >>> When the goal is to secure Linux I don't see how any of this helps. >>> Windows 8 compromises are already available so if we turn most of these >>> arguments around I am certain clever attackers can go through windows to >>> run compromised kernel on a linux system, at least as easily as the >>> reverse. >> >> And if any of them are used to attack Linux, we'd expect those versions >> of Windows to be blacklisted. > > I fail to see the logic here. It is ok to trust Microsofts signing key > because after I have been p0wned they will blacklist the version of > windows that has was used to compromise my system? > > A key revokation will help me when my system is p0wned how? It won't help you, it will help everyone else that _hasn't_ been p0wned already because the affected software will no longer be able to run on their system. And it will help you because if someone _else_ gets p0wned then your system won't be able to run the blacklisted insecure software. > I don't want my system p0wned in the first place and I don't want to run > windows. Why should I trust Microsoft's signing key? In any case, you don't need to trust Microsoft's signing key...at least on x86 hardware you can install your own. But if you want consumer hardware to be able to boot linux out-of-the-box without messing with BIOS settings then we need a bootloader that has been signed by Microsoft. Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 22:19 ` Chris Friesen @ 2012-11-02 23:46 ` Alan Cox 2012-11-03 0:23 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-02 23:46 UTC (permalink / raw) To: Chris Friesen Cc: Eric W. Biederman, Matthew Garrett, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, 02 Nov 2012 16:19:39 -0600 Chris Friesen <chris.friesen@genband.com> wrote: > On 11/02/2012 04:03 PM, Eric W. Biederman wrote: > > Matthew Garrett<mjg59@srcf.ucam.org> writes: > > > >> On Fri, Nov 02, 2012 at 01:49:25AM -0700, Eric W. Biederman wrote: > >> > >>> When the goal is to secure Linux I don't see how any of this helps. > >>> Windows 8 compromises are already available so if we turn most of these > >>> arguments around I am certain clever attackers can go through windows to > >>> run compromised kernel on a linux system, at least as easily as the > >>> reverse. > >> > >> And if any of them are used to attack Linux, we'd expect those versions > >> of Windows to be blacklisted. This is the first laugh. So they revoke the key. For that to be useful they must propogate that into all the boxes in warehouses and all the new boxes. If they do that then all the existing store stock of Windows 8 DVD and CD media needs replacing. > > I don't want my system p0wned in the first place and I don't want to run > > windows. Why should I trust Microsoft's signing key? > > In any case, you don't need to trust Microsoft's signing key...at least > on x86 hardware you can install your own. But if you want consumer > hardware to be able to boot linux out-of-the-box without messing with > BIOS settings then we need a bootloader that has been signed by Microsoft. Or a machine that has other keys in it, isn't sold locked down or doesn't have lunatic boot firmware. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 23:46 ` Alan Cox @ 2012-11-03 0:23 ` Matthew Garrett 2012-11-03 0:55 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 0:23 UTC (permalink / raw) To: Alan Cox Cc: Chris Friesen, Eric W. Biederman, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 11:46:07PM +0000, Alan Cox wrote: > On Fri, 02 Nov 2012 16:19:39 -0600 > Chris Friesen <chris.friesen@genband.com> wrote: > > On 11/02/2012 04:03 PM, Eric W. Biederman wrote: > > > Matthew Garrett<mjg59@srcf.ucam.org> writes: > > >> And if any of them are used to attack Linux, we'd expect those versions > > >> of Windows to be blacklisted. > > This is the first laugh. So they revoke the key. For that to be useful > they must propogate that into all the boxes in warehouses and all the new > boxes. If they do that then all the existing store stock of Windows 8 DVD > and CD media needs replacing. Revocation is done via Windows Update. If they refuse to do that, well, lawyers, right? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 0:23 ` Matthew Garrett @ 2012-11-03 0:55 ` Alan Cox 0 siblings, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-03 0:55 UTC (permalink / raw) To: Matthew Garrett Cc: Chris Friesen, Eric W. Biederman, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, 3 Nov 2012 00:23:39 +0000 Matthew Garrett <mjg@redhat.com> wrote: > On Fri, Nov 02, 2012 at 11:46:07PM +0000, Alan Cox wrote: > > On Fri, 02 Nov 2012 16:19:39 -0600 > > Chris Friesen <chris.friesen@genband.com> wrote: > > > On 11/02/2012 04:03 PM, Eric W. Biederman wrote: > > > > Matthew Garrett<mjg59@srcf.ucam.org> writes: > > > >> And if any of them are used to attack Linux, we'd expect those versions > > > >> of Windows to be blacklisted. > > > > This is the first laugh. So they revoke the key. For that to be useful > > they must propogate that into all the boxes in warehouses and all the new > > boxes. If they do that then all the existing store stock of Windows 8 DVD > > and CD media needs replacing. > > Revocation is done via Windows Update. If they refuse to do that, well, > lawyers, right? Doesn't work. Microsoft themselves have been bouncing up and down in the press about malware installed in the supply chain. They have to revoke the key in new systems as supplied. That means they can't install the Windows 8 DVD which means they can't access windows update which means all the media has to be updated. It also means all customers with rescue media and restore media would lose the ability to restore that media so those would need reissuing or a mechanism to replace them. Can't really see it happening. As any crypto systems and economics people will tell you key revocation is hard and the digital bits of it while hard are usually the tip of the iceberg. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 22:03 ` Eric W. Biederman 2012-11-02 22:19 ` Chris Friesen @ 2012-11-03 0:20 ` Matthew Garrett 2012-11-03 0:47 ` Eric W. Biederman 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 0:20 UTC (permalink / raw) To: Eric W. Biederman Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 03:03:02PM -0700, Eric W. Biederman wrote: > I don't want my system p0wned in the first place and I don't want to run > windows. Why should I trust Microsoft's signing key? There's no reason to. Systems that don't trust Microsoft's signing key have no reason to be concerned about Microsoft revocation. Unfortunately, that's not the only set of people we have to worry about. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 0:20 ` Matthew Garrett @ 2012-11-03 0:47 ` Eric W. Biederman 2012-11-03 1:03 ` Alan Cox 2012-11-03 1:43 ` Matthew Garrett 0 siblings, 2 replies; 224+ messages in thread From: Eric W. Biederman @ 2012-11-03 0:47 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Fri, Nov 02, 2012 at 03:03:02PM -0700, Eric W. Biederman wrote: > >> I don't want my system p0wned in the first place and I don't want to run >> windows. Why should I trust Microsoft's signing key? > > There's no reason to. Systems that don't trust Microsoft's signing key > have no reason to be concerned about Microsoft revocation. > Unfortunately, that's not the only set of people we have to worry > about. No reason to? How can I configure an off the shelf system originally sold with windows 8 installed to boot in UEFI secure boot mode using shim without trusting Microsoft's key? Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 0:47 ` Eric W. Biederman @ 2012-11-03 1:03 ` Alan Cox 2012-11-03 1:43 ` Matthew Garrett 1 sibling, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-03 1:03 UTC (permalink / raw) To: Eric W. Biederman Cc: Matthew Garrett, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi > No reason to? How can I configure an off the shelf system originally > sold with windows 8 installed to boot in UEFI secure boot mode using > shim without trusting Microsoft's key? Assuming its an x86 and a PC class platform and thus should allow you to disable secure boot mode then you disable secure boot mode and boot in sane PC mode. You then jump through a collection of hoops to sign all your OS stuff, your ROMs and a few other things with a new key, remove the MS key and then "secure" boot it. That will also stop random people demonstrating how secure your "secure" boot is by walking up to your box and installing Windows 8 over your distribution by reformatting your hard drive and probably block a wide range of interesting law enforcement and other tools some of which will inevitably fall into the wrong hands. A lot of the work there is the mechanising of all of the hoop jumping and key management, but there isn't an intrinsic reason you can't turn this into a nice clean click and point self-sign my PC UI. There are some interesting uses for self signed keys or having your own corporate key included in your builds as a big company. One thing it solves if you do it with Linux and an own key is being able to remote install securely over a network which right now for all OS's and PC class devices is a problem as you have no way to verify the image. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 0:47 ` Eric W. Biederman 2012-11-03 1:03 ` Alan Cox @ 2012-11-03 1:43 ` Matthew Garrett 2012-11-03 16:31 ` Alan Cox 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 1:43 UTC (permalink / raw) To: Eric W. Biederman Cc: Alan Cox, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 05:47:02PM -0700, Eric W. Biederman wrote: > No reason to? How can I configure an off the shelf system originally > sold with windows 8 installed to boot in UEFI secure boot mode using > shim without trusting Microsoft's key? Delete the installed keys, install your choice of keys, make sure your bootloader is signed with a key you trust. You're guaranteed to be able to do this on any Windows 8 certified hardware. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 1:43 ` Matthew Garrett @ 2012-11-03 16:31 ` Alan Cox 2012-11-03 16:37 ` Matthew Garrett 2012-11-03 16:37 ` Eric Paris 0 siblings, 2 replies; 224+ messages in thread From: Alan Cox @ 2012-11-03 16:31 UTC (permalink / raw) To: Matthew Garrett Cc: Eric W. Biederman, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi > You're guaranteed to be able > to do this on any Windows 8 certified hardware. Thats not my understanding of the situation. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 16:31 ` Alan Cox @ 2012-11-03 16:37 ` Matthew Garrett 2012-11-03 16:37 ` Eric Paris 1 sibling, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 16:37 UTC (permalink / raw) To: Alan Cox Cc: Eric W. Biederman, James Bottomley, Eric Paris, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, Nov 03, 2012 at 04:31:52PM +0000, Alan Cox wrote: > > You're guaranteed to be able > > to do this on any Windows 8 certified hardware. > > Thats not my understanding of the situation. "17. Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: a. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode." -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 16:31 ` Alan Cox 2012-11-03 16:37 ` Matthew Garrett @ 2012-11-03 16:37 ` Eric Paris 2012-11-03 16:42 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Eric Paris @ 2012-11-03 16:37 UTC (permalink / raw) To: Alan Cox Cc: Matthew Garrett, Eric W. Biederman, James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, Linux Kernel Mailing List, LSM List, linux-efi On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> You're guaranteed to be able >> to do this on any Windows 8 certified hardware. > > Thats not my understanding of the situation. Windows 8 certification has this as a requirement for x86 hardware. I belied the opposite is a requirement for arm hardware. However it's possible that it just doesn't specifiy at all for arm. So yes, you're guaranteed to be able to do this on any Windows 8 certified x86 hardware. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 16:37 ` Eric Paris @ 2012-11-03 16:42 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 16:42 UTC (permalink / raw) To: Eric Paris Cc: Alan Cox, Eric W. Biederman, James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Josh Boyer, Linux Kernel Mailing List, LSM List, linux-efi On Sat, Nov 03, 2012 at 12:37:44PM -0400, Eric Paris wrote: > On Sat, Nov 3, 2012 at 12:31 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > >> You're guaranteed to be able > >> to do this on any Windows 8 certified hardware. > > > > Thats not my understanding of the situation. > > Windows 8 certification has this as a requirement for x86 hardware. I > belied the opposite is a requirement for arm hardware. However it's > possible that it just doesn't specifiy at all for arm. Arm devices are Windows RT, not Windows 8. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 17:50 ` Eric Paris 2012-11-01 21:03 ` James Bottomley @ 2012-11-02 17:19 ` Vivek Goyal 1 sibling, 0 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 17:19 UTC (permalink / raw) To: Eric Paris Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 01:50:08PM -0400, Eric Paris wrote: [..] > I've talked with and > worked with a public cloud operator who wants to prevent even a > malicious root user from being able to run code in ring 0 inside their > VM. The hope in that case was that in doing so they can indirectly > shrink the attack surface between virtual machine and hypervisor. > They hoped to limit the ways the guest could interact to only those > methods the linux kernel implemented. > > They want to launch a vm running a kernel they chose and make sure > root inside the vm could not run some other kernel or run arbitrary > code in kernel space. It's wasn't something they solved completely. > If it was, all of this secure boot work would be finished. Which is > why we are having these discussions to understand all of the way that > you an Alan seem to have to get around the secure boot restrictions. > And look for solutions to retain functionality which meeting the > security goal of 'prevent uid=0 to ring 0 privilege escalation. So will secure boot help with above use case you mentioned? I think until and unless you lock down user space too on host, it will not be possible. On the flip side, one might be able to launch windows in qemu (compromised noe) and might fool user into thinking it is booted natively and steal login credentials and other stuff. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:29 ` Eric Paris 2012-11-01 14:42 ` James Bottomley @ 2012-11-01 14:46 ` Alan Cox 2012-11-01 15:04 ` Eric Paris 2012-11-01 20:27 ` Pavel Machek 2012-11-02 14:55 ` Vivek Goyal 3 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 14:46 UTC (permalink / raw) To: Eric Paris Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi > Imagine you run windows and you've never heard of Linux. To those people I think you mean "never heard of Ubuntu" ;-) > In this case we have a completely 'untrusted' root inside Linux. From > the user PoV root and Linux are both malware. Notice the EXACT same > attack would work launching rootkit'd Linux from Linux. So don't > pretend not to care about Windows. It's just that launching malware > Linux seems like a reason to get your key revoked. We don't want > signed code which can be used as an attack vector on ourselves or on > others. > > That make sense? Not really but it keeps some of the Red Hat security people happy and out of harms way. With all the current posted RH patches I can still take over the box as root trivially enough and you seem to have so far abolished suspend to disk, kexec and a pile of other useful stuff. To actually lock it down you'll have to do a ton more of this. I suspect folks who know windows innards well are probably thinking the same about Windows 8 8) Almost anyone attacking a secure boot box will do it via windows or more likely via EFI. EFI because its large, new and doesn't a great history, windows because its the larger target. Actually from what I've seen on the security front there seems to a distinct view that secure boot is irrelevant because Windows 8 is so suspend/resume focussed that you might as well just trojan the box until the next reboot as its likely to be a couple of weeks a way. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:46 ` Alan Cox @ 2012-11-01 15:04 ` Eric Paris 0 siblings, 0 replies; 224+ messages in thread From: Eric Paris @ 2012-11-01 15:04 UTC (permalink / raw) To: Alan Cox Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 1, 2012 at 10:46 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> Imagine you run windows and you've never heard of Linux. > > To those people I think you mean "never heard of Ubuntu" ;-) :-) > With all the current posted RH patches I can still take over > the box as root trivially enough and you seem to have so far abolished > suspend to disk, kexec and a pile of other useful stuff. To actually lock > it down you'll have to do a ton more of this. I'm guessing those writing the patches would like to hear about these. Suspend to disk and kexec can probably both be fixed up to work... > Actually from what I've seen on > the security front there seems to a distinct view that secure boot is > irrelevant because Windows 8 is so suspend/resume focussed that you might > as well just trojan the box until the next reboot as its likely to be a > couple of weeks a way. Bit of a straw man isn't it? Hey, don't fix A, I can do B! I'm not saying you're wrong, nor that maybe online attacks which don't persist across reboot wouldn't be more likely, but they aren't attacking the same problem. (I haven't heard any progress on what you point out, but at least we have some progress on some small class of boot time persistent attacks) ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:29 ` Eric Paris 2012-11-01 14:42 ` James Bottomley 2012-11-01 14:46 ` Alan Cox @ 2012-11-01 20:27 ` Pavel Machek 2012-11-01 21:02 ` Chris Friesen 2012-11-02 14:55 ` Vivek Goyal 3 siblings, 1 reply; 224+ messages in thread From: Pavel Machek @ 2012-11-01 20:27 UTC (permalink / raw) To: Eric Paris Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi Hi! > > But that doesn't really help me: untrusted root is an oxymoron. > > Imagine you run windows and you've never heard of Linux. You like > that only windows kernels can boot on your box and not those mean > nasty hacked up malware kernels. Now some attacker manages to take > over your box because you clicked on that executable for young models > in skimpy bathing suits. That executable rewrote your bootloader to > launch a very small carefully crafted Linux environment. This > environment does nothing but launch a perfectly valid signed Linux > kernel, which gets a Windows environment all ready to launch after > resume and goes to sleep. Now you have to hit the power button twice > every time you turn on your computer, weird, but Windows comes up, and > secureboot is still on, so you must be safe! Ok, so you cripple kexec / suspend to disallow this, and then... ...attacker launches carefuly crafter Linux environment, that just launches X and fullscreen wine. Sure, timing may be slightly different, but Windows came up and secureboot is still on.. so user happily enters his bank account details. Could someone write down exact requirements for Linux kernel to be signed by Microsoft? Because thats apparently what you want, and I don't think crippling kexec/suspend is enough. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 20:27 ` Pavel Machek @ 2012-11-01 21:02 ` Chris Friesen 2012-11-02 15:48 ` Vivek Goyal 2012-11-02 16:33 ` Pavel Machek 0 siblings, 2 replies; 224+ messages in thread From: Chris Friesen @ 2012-11-01 21:02 UTC (permalink / raw) To: Pavel Machek Cc: Eric Paris, James Bottomley, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/01/2012 02:27 PM, Pavel Machek wrote: > Could someone write down exact requirements for Linux kernel to be signed by Microsoft? > Because thats apparently what you want, and I don't think crippling kexec/suspend is > enough. As I understand it, the kernel won't be signed by Microsoft. Rather, the bootloader will be signed by Microsoft and the vendors will be the ones that refuse to sign a kernel unless it is reasonably assured that it won't be used as an attack vector. If you want fully-open behaviour it's still possible, you just need to turn off secure boot. With secure boot enabled, then the kernel should refuse to let an unsigned kexec load new images, and kexec itself should refuse to load unsigned images. Also the kernel would need to sign its "suspend-to-disk" images and refuse to resume unsigned images. Presumably the signing key for the "suspend-to-disk" images would need to be stored somewhere that is not accessable even by root. It's not clear to me how we would do this, but maybe it's possible with hardware support. Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:02 ` Chris Friesen @ 2012-11-02 15:48 ` Vivek Goyal 2012-11-02 16:54 ` Chris Friesen 2012-11-03 23:09 ` Jiri Kosina 2012-11-02 16:33 ` Pavel Machek 1 sibling, 2 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 15:48 UTC (permalink / raw) To: Chris Friesen Cc: Pavel Machek, Eric Paris, James Bottomley, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi, Eric W. Biederman On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: > On 11/01/2012 02:27 PM, Pavel Machek wrote: > > >Could someone write down exact requirements for Linux kernel to be signed by Microsoft? > >Because thats apparently what you want, and I don't think crippling kexec/suspend is > >enough. > > As I understand it, the kernel won't be signed by Microsoft. > > Rather, the bootloader will be signed by Microsoft and the vendors > will be the ones that refuse to sign a kernel unless it is > reasonably assured that it won't be used as an attack vector. > > If you want fully-open behaviour it's still possible, you just need > to turn off secure boot. > > With secure boot enabled, then the kernel should refuse to let an > unsigned kexec load new images, and kexec itself should refuse to > load unsigned images. Yep, good in theory. Now that basically means reimplementing kexec-tools in kernel. That also means creating a new system call. It also also means cutting down on future flexibility (assuming new system call interface will be able to support existing features provided by kernel). And it is lot of code in user space which needs to be reimplemented in kernel and bloat kernel. Keeping most of the logic in kexec-tools provided flexibility and keeps kernel small. So now re-architect kexec and reverse a good design completely for secureboot. It is a huge pain. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:48 ` Vivek Goyal @ 2012-11-02 16:54 ` Chris Friesen 2012-11-02 17:03 ` Vivek Goyal 2012-11-03 23:09 ` Jiri Kosina 1 sibling, 1 reply; 224+ messages in thread From: Chris Friesen @ 2012-11-02 16:54 UTC (permalink / raw) To: Vivek Goyal Cc: Pavel Machek, Eric Paris, James Bottomley, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi, Eric W. Biederman On 11/02/2012 09:48 AM, Vivek Goyal wrote: > On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: >> With secure boot enabled, then the kernel should refuse to let an >> unsigned kexec load new images, and kexec itself should refuse to >> load unsigned images. > > Yep, good in theory. Now that basically means reimplementing kexec-tools > in kernel. Maybe I'm missing something, but couldn't the vendors provide a signed kexec? Why does extra stuff need to be pushed into the kernel? Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 16:54 ` Chris Friesen @ 2012-11-02 17:03 ` Vivek Goyal 0 siblings, 0 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 17:03 UTC (permalink / raw) To: Chris Friesen Cc: Pavel Machek, Eric Paris, James Bottomley, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi, Eric W. Biederman On Fri, Nov 02, 2012 at 10:54:50AM -0600, Chris Friesen wrote: > On 11/02/2012 09:48 AM, Vivek Goyal wrote: > >On Thu, Nov 01, 2012 at 03:02:25PM -0600, Chris Friesen wrote: > > >>With secure boot enabled, then the kernel should refuse to let an > >>unsigned kexec load new images, and kexec itself should refuse to > >>load unsigned images. > > > >Yep, good in theory. Now that basically means reimplementing kexec-tools > >in kernel. > > Maybe I'm missing something, but couldn't the vendors provide a > signed kexec? Why does extra stuff need to be pushed into the > kernel? Bingo. Join us in following mail thread for all the gory details and extra work required to make signing of user space processes work. https://lkml.org/lkml/2012/10/24/451 In a nut-shell, there is no infrastructure currently for signing user space processes and verifying it (like module signing). Then if you just sign select user processes and not whole of the user space, then it brings extra complications with linking shared objects and being able to modify the code of process etc. So yes, being able to sign /sbin/kexec will be great. Looks like that itself will require lot of work and is not that straight forward. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:48 ` Vivek Goyal 2012-11-02 16:54 ` Chris Friesen @ 2012-11-03 23:09 ` Jiri Kosina 2012-11-05 6:38 ` Eric W. Biederman 1 sibling, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-03 23:09 UTC (permalink / raw) To: Vivek Goyal Cc: Chris Friesen, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi, Eric W. Biederman On Fri, 2 Nov 2012, Vivek Goyal wrote: > > With secure boot enabled, then the kernel should refuse to let an > > unsigned kexec load new images, and kexec itself should refuse to > > load unsigned images. > > Yep, good in theory. Now that basically means reimplementing kexec-tools > in kernel. Why is "when kernel has been securely booted, the in-kernel kexec mechanism has to verify the signature of the supplied image before kexecing it" not enough? (basically the same thing we are doing for signed modules already). -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 23:09 ` Jiri Kosina @ 2012-11-05 6:38 ` Eric W. Biederman 2012-11-05 14:40 ` Jiri Kosina 0 siblings, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-05 6:38 UTC (permalink / raw) To: Jiri Kosina Cc: Vivek Goyal, Chris Friesen, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi Jiri Kosina <jkosina@suse.cz> writes: > On Fri, 2 Nov 2012, Vivek Goyal wrote: > >> > With secure boot enabled, then the kernel should refuse to let an >> > unsigned kexec load new images, and kexec itself should refuse to >> > load unsigned images. >> >> Yep, good in theory. Now that basically means reimplementing kexec-tools >> in kernel. > > Why is "when kernel has been securely booted, the in-kernel kexec > mechanism has to verify the signature of the supplied image before > kexecing it" not enough? (basically the same thing we are doing for signed > modules already). For modules the only untrusted part of their environment are the command line parameters, and several of those have already been noted for needing to be ignored in a non-trusted root scenario. For kexec there is a bunch of glue code and data that takes care of transitioning from the environment provided by kexec and the environment that the linux kernel or memtest86 or whatever we are booting is expecting. Figuring out what glue code and data we need and supplying that glue code and data is what kexec-tools does. The situation is a bit like dealing with the modules before most of the work of insmod was moved into the kernel. For kexec-tools it is desirable to have glue layers outside of the kernel because every boot system in existence has a different set of parameter passing rules. So signing in the kernel gets us into how do we sign the glue code and how dow we verify the glue code will jump to our signed and verified kernel image. I will be happy to review patches for that don't through the baby out with the bath water. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 6:38 ` Eric W. Biederman @ 2012-11-05 14:40 ` Jiri Kosina 2012-11-05 15:31 ` Jiri Kosina 0 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-05 14:40 UTC (permalink / raw) To: Eric W. Biederman Cc: Vivek Goyal, Chris Friesen, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun, 4 Nov 2012, Eric W. Biederman wrote: > > Why is "when kernel has been securely booted, the in-kernel kexec > > mechanism has to verify the signature of the supplied image before > > kexecing it" not enough? (basically the same thing we are doing for signed > > modules already). > > For modules the only untrusted part of their environment are the command > line parameters, and several of those have already been noted for > needing to be ignored in a non-trusted root scenario. > > For kexec there is a bunch of glue code and data that takes care of > transitioning from the environment provided by kexec and the environment > that the linux kernel or memtest86 or whatever we are booting is > expecting. > > Figuring out what glue code and data we need and supplying that glue > code and data is what kexec-tools does. The situation is a bit like > dealing with the modules before most of the work of insmod was moved > into the kernel. > > For kexec-tools it is desirable to have glue layers outside of the > kernel because every boot system in existence has a different set of > parameter passing rules. > > So signing in the kernel gets us into how do we sign the glue code and > how dow we verify the glue code will jump to our signed and verified > kernel image. Do I understand you correctly that by the 'glue' stuff you actually mean the division of the kexec image into segments? Of course, when we are dividing the image into segments and then passing those individually (even more so if some transformations are performed on those segments, which I don't know whether that's the case or not), then we can't do any signature verification of the image any more. But I still don't fully understand what is so magical about taking the kernel image as is, and passing the whole lot to the running kernel as-is, allowing for signature verification. Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that would be problem in principle. If you can point me to the code where all the magic that prevents this easy handling is happening, I'd appreciate it. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 14:40 ` Jiri Kosina @ 2012-11-05 15:31 ` Jiri Kosina 2012-11-05 15:37 ` Chris Friesen 0 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-05 15:31 UTC (permalink / raw) To: Eric W. Biederman Cc: Vivek Goyal, Chris Friesen, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, 5 Nov 2012, Jiri Kosina wrote: > Do I understand you correctly that by the 'glue' stuff you actually mean > the division of the kexec image into segments? > > Of course, when we are dividing the image into segments and then passing > those individually (even more so if some transformations are performed on > those segments, which I don't know whether that's the case or not), then > we can't do any signature verification of the image any more. > > But I still don't fully understand what is so magical about taking the > kernel image as is, and passing the whole lot to the running kernel as-is, > allowing for signature verification. > > Yes, it couldn't be sys_kexec_load(), as that would be ABI breakage, so > it'd mean sys_kexec_raw_load(), or whatever ... but I fail to see why that > would be problem in principle. > > If you can point me to the code where all the magic that prevents this > easy handling is happening, I'd appreciate it. OK, so after wandering through kexec-tools sources for a while, I am starting to get your point. I wasn't actually aware of the fact that it supports such a wide variety of binary formats etc. (multiboot, nbi, etc). I had a naive idea of just putting in-kernel verification of a complete ELF binary passed to kernel by userspace, and if the signature matches, jumping to it. Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other functionality currently being provided by kexec-tools. Bah. This is a real pandora's box. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 15:31 ` Jiri Kosina @ 2012-11-05 15:37 ` Chris Friesen 2012-11-05 18:22 ` Vivek Goyal 0 siblings, 1 reply; 224+ messages in thread From: Chris Friesen @ 2012-11-05 15:37 UTC (permalink / raw) To: Jiri Kosina Cc: Eric W. Biederman, Vivek Goyal, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/05/2012 09:31 AM, Jiri Kosina wrote: > I had a naive idea of just putting in-kernel verification of a complete > ELF binary passed to kernel by userspace, and if the signature matches, > jumping to it. > Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other > functionality currently being provided by kexec-tools. > > Bah. This is a real pandora's box. Would it be so bad to statically link kexec? Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 15:37 ` Chris Friesen @ 2012-11-05 18:22 ` Vivek Goyal 0 siblings, 0 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-05 18:22 UTC (permalink / raw) To: Chris Friesen Cc: Jiri Kosina, Eric W. Biederman, Pavel Machek, Eric Paris, James Bottomley, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 09:37:18AM -0600, Chris Friesen wrote: > On 11/05/2012 09:31 AM, Jiri Kosina wrote: > > >I had a naive idea of just putting in-kernel verification of a complete > >ELF binary passed to kernel by userspace, and if the signature matches, > >jumping to it. > >Would work for elf-x86_64 nicely I guess, but we'd lose a lot of other > >functionality currently being provided by kexec-tools. > > > >Bah. This is a real pandora's box. > > Would it be so bad to statically link kexec? statically linking and signing /sbin/kexec is sounding most reasonable so far, to me. Even if we do that, there are few more issues queries though. - Do we still need a new system call? - Who does the kernel signature verification. Is it /sbin/kexec or kernel should do that. - If kernel is supposed to do kernel signature verification, how the signed bzImage is passed to kernel with existing system call. Are certificates passed in separate segments. How does kernel differentiate between segmets etc. - Does signed /sbin/kexec means that it can load any other segments like elf header, boot_params and no signature verifiation is needed. If we move all the kernel signatuer verification part into /sbin/kexec, then we should possibly be able to use existing system call. But I don't know what kind of crypto support we shall have to build into kexec-tools statically and how much help we can get from static libraries and how much work it is. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 21:02 ` Chris Friesen 2012-11-02 15:48 ` Vivek Goyal @ 2012-11-02 16:33 ` Pavel Machek 2012-11-02 16:52 ` James Bottomley 1 sibling, 1 reply; 224+ messages in thread From: Pavel Machek @ 2012-11-02 16:33 UTC (permalink / raw) To: Chris Friesen Cc: Eric Paris, James Bottomley, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu 2012-11-01 15:02:25, Chris Friesen wrote: > On 11/01/2012 02:27 PM, Pavel Machek wrote: > > >Could someone write down exact requirements for Linux kernel to be signed by Microsoft? > >Because thats apparently what you want, and I don't think crippling kexec/suspend is > >enough. > > As I understand it, the kernel won't be signed by Microsoft. > Rather, the bootloader will be signed by Microsoft and the vendors > will be the ones that refuse to sign a kernel unless it is > reasonably assured that it won't be used as an attack vector. Yes. So can someone write down what "used as an attack vector" means? Because, AFAICT, Linux kernel is _designed_ to work as an attact vector. We intentionally support wine, and want to keep that support. > With secure boot enabled, then the kernel should refuse to let an > unsigned kexec load new images, and kexec itself should refuse to > load unsigned images. Also the kernel would need to sign its > "suspend-to-disk" images and refuse to resume unsigned images. I believe that attacking Windows using wine is easier than using suspend-to-disk. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 16:33 ` Pavel Machek @ 2012-11-02 16:52 ` James Bottomley 2012-11-02 16:54 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-02 16:52 UTC (permalink / raw) To: Pavel Machek Cc: Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, 2012-11-02 at 17:33 +0100, Pavel Machek wrote: > On Thu 2012-11-01 15:02:25, Chris Friesen wrote: > > On 11/01/2012 02:27 PM, Pavel Machek wrote: > > > > >Could someone write down exact requirements for Linux kernel to be signed by Microsoft? > > >Because thats apparently what you want, and I don't think crippling kexec/suspend is > > >enough. > > > > As I understand it, the kernel won't be signed by Microsoft. > > > Rather, the bootloader will be signed by Microsoft and the vendors > > will be the ones that refuse to sign a kernel unless it is > > reasonably assured that it won't be used as an attack vector. > > Yes. So can someone write down what "used as an attack vector" means? > > Because, AFAICT, Linux kernel is _designed_ to work as an attact > vector. We intentionally support wine, and want to keep that support. I think there's a variety of opinions on this one. My definition is that you can construct a signed boot system from the components delivered with a Linux distribution that will fairly invisibly chain load a hacked version of windows. Thus allowing the windows user to think they have a chain of trust to the UEFI firmware when, in fact, they haven't. The first question is how many compromises do you need. Without co-operation from windows, you don't get to install something in the boot system, so if you're looking for a single compromise vector, the only realistic attack is to trick the user into booting a hacked linux system from USB or DVD. There's also a lot of debate around "fairly invisibly". If your hack involves shim->grub->linux->windows, that's a fairly long boot process with time for the user to notice something. Obviously, a boot loader that breaks the trust chain is ideal as a windows attack vector, which is why most pre bootloaders on virgin systems do a present user test (tell the user what they're doing and ask permission to continue). I really think that if the shim+MOK system always paused and asked to continue if the MOK Boot Services variables aren't present (i.e. it's a first boot virgin system), we've solved the windows attack vector problem, and we can move on from this rather sterile debate to think of how we can use secure boot to enhance Linux security for the machine owner. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 16:52 ` James Bottomley @ 2012-11-02 16:54 ` Matthew Garrett 2012-11-02 17:48 ` James Bottomley 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-02 16:54 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote: > The first question is how many compromises do you need. Without > co-operation from windows, you don't get to install something in the > boot system, so if you're looking for a single compromise vector, the > only realistic attack is to trick the user into booting a hacked linux > system from USB or DVD. You run a binary. It pops up a box saying "Windows needs your permission to continue", just like almost every other Windows binary that's any use. Done. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 16:54 ` Matthew Garrett @ 2012-11-02 17:48 ` James Bottomley 2012-11-02 17:54 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-02 17:48 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, 2012-11-02 at 16:54 +0000, Matthew Garrett wrote: > On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote: > > > The first question is how many compromises do you need. Without > > co-operation from windows, you don't get to install something in the > > boot system, so if you're looking for a single compromise vector, the > > only realistic attack is to trick the user into booting a hacked linux > > system from USB or DVD. > > You run a binary. It pops up a box saying "Windows needs your permission > to continue", just like almost every other Windows binary that's any > use. Done. And if all the loaders do some type of present user test on a virgin system, how do you propose to get that message up there? James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 17:48 ` James Bottomley @ 2012-11-02 17:54 ` Matthew Garrett 2012-11-02 17:57 ` James Bottomley 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-02 17:54 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 05:48:31PM +0000, James Bottomley wrote: > On Fri, 2012-11-02 at 16:54 +0000, Matthew Garrett wrote: > > On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote: > > > > > The first question is how many compromises do you need. Without > > > co-operation from windows, you don't get to install something in the > > > boot system, so if you're looking for a single compromise vector, the > > > only realistic attack is to trick the user into booting a hacked linux > > > system from USB or DVD. > > > > You run a binary. It pops up a box saying "Windows needs your permission > > to continue", just like almost every other Windows binary that's any > > use. Done. > > And if all the loaders do some type of present user test on a virgin > system, how do you propose to get that message up there? ? That's the message generated by the Windows access control mechanism when you run a binary that requests elevated privileges. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 17:54 ` Matthew Garrett @ 2012-11-02 17:57 ` James Bottomley 2012-11-02 18:04 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-02 17:57 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, 2012-11-02 at 17:54 +0000, Matthew Garrett wrote: > On Fri, Nov 02, 2012 at 05:48:31PM +0000, James Bottomley wrote: > > On Fri, 2012-11-02 at 16:54 +0000, Matthew Garrett wrote: > > > On Fri, Nov 02, 2012 at 04:52:44PM +0000, James Bottomley wrote: > > > > > > > The first question is how many compromises do you need. Without > > > > co-operation from windows, you don't get to install something in the > > > > boot system, so if you're looking for a single compromise vector, the > > > > only realistic attack is to trick the user into booting a hacked linux > > > > system from USB or DVD. > > > > > > You run a binary. It pops up a box saying "Windows needs your permission > > > to continue", just like almost every other Windows binary that's any > > > use. Done. > > > > And if all the loaders do some type of present user test on a virgin > > system, how do you propose to get that message up there? > > ? That's the message generated by the Windows access control mechanism > when you run a binary that requests elevated privileges. So that's a windows attack vector using a windows binary? I can't really see how it's relevant to the secure boot discussion then. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 17:57 ` James Bottomley @ 2012-11-02 18:04 ` Matthew Garrett 2012-11-02 19:18 ` Eric Paris 2012-11-02 23:38 ` James Bottomley 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-02 18:04 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 05:57:38PM +0000, James Bottomley wrote: > On Fri, 2012-11-02 at 17:54 +0000, Matthew Garrett wrote: > > ? That's the message generated by the Windows access control mechanism > > when you run a binary that requests elevated privileges. > > So that's a windows attack vector using a windows binary? I can't really > see how it's relevant to the secure boot discussion then. A user runs a binary that elevates itself to admin. Absent any flaws in Windows (cough), that should be all it can do in a Secure Boot world. But if you can drop a small trusted Linux system in there and use that to boot a compromised Windows kernel, it can make itself persistent. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 18:04 ` Matthew Garrett @ 2012-11-02 19:18 ` Eric Paris 2012-11-02 23:38 ` James Bottomley 1 sibling, 0 replies; 224+ messages in thread From: Eric Paris @ 2012-11-02 19:18 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Pavel Machek, Chris Friesen, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, Linux Kernel Mailing List, LSM List, linux-efi I know I started it, but Windows really isn't necessary to see value, even if it is what pushed the timing. A user installs a package as root. Absent any flaws in the Linux kernel (cough) that should be all it can do in a Secure Boot world. But if you can drop a small trusted Linux system in there and use that to boot a compromised Linux kernel, it can make itself persistent. And like I said, I know there are cloud providers out there who want EXACTLY this type of system. One in which root in the guest is untrusted and they want to keep them out of ring 0. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 18:04 ` Matthew Garrett 2012-11-02 19:18 ` Eric Paris @ 2012-11-02 23:38 ` James Bottomley 2012-11-03 0:22 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-02 23:38 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, 2012-11-02 at 18:04 +0000, Matthew Garrett wrote: > On Fri, Nov 02, 2012 at 05:57:38PM +0000, James Bottomley wrote: > > On Fri, 2012-11-02 at 17:54 +0000, Matthew Garrett wrote: > > > ? That's the message generated by the Windows access control mechanism > > > when you run a binary that requests elevated privileges. > > > > So that's a windows attack vector using a windows binary? I can't really > > see how it's relevant to the secure boot discussion then. > > A user runs a binary that elevates itself to admin. Absent any flaws in > Windows (cough), that should be all it can do in a Secure Boot world. > But if you can drop a small trusted Linux system in there and use that > to boot a compromised Windows kernel, it can make itself persistent. We seem to be talking past each other. Assume you managed to install a Linux boot system on the windows machine. If the linux boot requires present user on first boot (either because the key of the bootloader isn't in db or because the MOK database isn't initialised), you still don't have a compromise because the loader won't start automatically. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 23:38 ` James Bottomley @ 2012-11-03 0:22 ` Matthew Garrett 2012-11-03 12:03 ` James Bottomley 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 0:22 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 11:38:23PM +0000, James Bottomley wrote: > On Fri, 2012-11-02 at 18:04 +0000, Matthew Garrett wrote: > > A user runs a binary that elevates itself to admin. Absent any flaws in > > Windows (cough), that should be all it can do in a Secure Boot world. > > But if you can drop a small trusted Linux system in there and use that > > to boot a compromised Windows kernel, it can make itself persistent. > > We seem to be talking past each other. Assume you managed to install a > Linux boot system on the windows machine. If the linux boot requires > present user on first boot (either because the key of the bootloader > isn't in db or because the MOK database isn't initialised), you still > don't have a compromise because the loader won't start automatically. Why would an attacker use one of those Linux systems? There's going to be plenty available that don't have that restriction. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 0:22 ` Matthew Garrett @ 2012-11-03 12:03 ` James Bottomley 2012-11-03 13:46 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-03 12:03 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, 2012-11-03 at 00:22 +0000, Matthew Garrett wrote: > On Fri, Nov 02, 2012 at 11:38:23PM +0000, James Bottomley wrote: > > On Fri, 2012-11-02 at 18:04 +0000, Matthew Garrett wrote: > > > A user runs a binary that elevates itself to admin. Absent any flaws in > > > Windows (cough), that should be all it can do in a Secure Boot world. > > > But if you can drop a small trusted Linux system in there and use that > > > to boot a compromised Windows kernel, it can make itself persistent. > > > > We seem to be talking past each other. Assume you managed to install a > > Linux boot system on the windows machine. If the linux boot requires > > present user on first boot (either because the key of the bootloader > > isn't in db or because the MOK database isn't initialised), you still > > don't have a compromise because the loader won't start automatically. > > Why would an attacker use one of those Linux systems? There's going to > be plenty available that don't have that restriction. It's called best practices. If someone else releases something that doesn't conform to them, then it's their signing key in jeopardy, not yours. You surely must see that the goal of securing "everything" against "anything" isn't achievable because if someone releases a bootloader not conforming to the best practices, why would they have bothered to include your secure boot lockdowns in their kernel. In other words, you lost ab initio, so it's pointless to cite this type of thing as a rationale for a kernel lockdown patch. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 12:03 ` James Bottomley @ 2012-11-03 13:46 ` Matthew Garrett 2012-11-03 22:56 ` James Bottomley 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-03 13:46 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, Nov 03, 2012 at 12:03:56PM +0000, James Bottomley wrote: > On Sat, 2012-11-03 at 00:22 +0000, Matthew Garrett wrote: > > Why would an attacker use one of those Linux systems? There's going to > > be plenty available that don't have that restriction. > > It's called best practices. If someone else releases something that > doesn't conform to them, then it's their signing key in jeopardy, not > yours. You surely must see that the goal of securing "everything" > against "anything" isn't achievable because if someone releases a > bootloader not conforming to the best practices, why would they have > bothered to include your secure boot lockdowns in their kernel. In > other words, you lost ab initio, so it's pointless to cite this type of > thing as a rationale for a kernel lockdown patch. I... what? Our signed bootloader will boot our signed kernel without any physically present end-user involvement. We therefore need to make it as difficult as practically possible for an attacker to use our signed bootloader and our signed kernel as an attack vector against other operating systems, which includes worrying about hibernate and kexec. If people want to support this use case then patches to deal with that need to be present in the upstream kernel. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 13:46 ` Matthew Garrett @ 2012-11-03 22:56 ` James Bottomley 2012-11-04 4:28 ` Matthew Garrett 2012-11-05 21:25 ` Florian Weimer 0 siblings, 2 replies; 224+ messages in thread From: James Bottomley @ 2012-11-03 22:56 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, 2012-11-03 at 13:46 +0000, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 12:03:56PM +0000, James Bottomley wrote: > > On Sat, 2012-11-03 at 00:22 +0000, Matthew Garrett wrote: > > > Why would an attacker use one of those Linux systems? There's going to > > > be plenty available that don't have that restriction. > > > > It's called best practices. If someone else releases something that > > doesn't conform to them, then it's their signing key in jeopardy, not > > yours. You surely must see that the goal of securing "everything" > > against "anything" isn't achievable because if someone releases a > > bootloader not conforming to the best practices, why would they have > > bothered to include your secure boot lockdowns in their kernel. In > > other words, you lost ab initio, so it's pointless to cite this type of > > thing as a rationale for a kernel lockdown patch. > > I... what? Our signed bootloader will boot our signed kernel without any > physically present end-user involvement. We therefore need to make it > as difficult as practically possible for an attacker to use our signed > bootloader and our signed kernel as an attack vector against other > operating systems, which includes worrying about hibernate and kexec. If > people want to support this use case then patches to deal with that need > to be present in the upstream kernel. Right, but what I'm telling you is that by deciding to allow automatic first boot, you're causing the windows attack vector problem. You could easily do a present user test only on first boot which would eliminate it. Instead, we get all of this. By analogy, it's like an architect trying to design a house to be secure without a front door lock. If you just secure the front door, you don't necessarily need all the internal security. There is certainly a market for houses with good internal security, but not everyone wants the hassle, so trying to make every house that way is counterproductive. It's also not so useful to the people who want specialist internal security because they're willing to use much more specialised systems than you have to deploy generally. In short, if you'd just separate the problem into 1. What do we have to do to prevent Linux being used to attack windows and thus getting our key revoked from, 2. What specialised systems can we put in place to enhance linux security with secure boot for those who want it It becomes a lot simpler than trying to do a one size fits all solution. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 22:56 ` James Bottomley @ 2012-11-04 4:28 ` Matthew Garrett 2012-11-04 9:14 ` James Bottomley 2012-11-04 11:53 ` Pavel Machek 2012-11-05 21:25 ` Florian Weimer 1 sibling, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-04 4:28 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sat, Nov 03, 2012 at 10:56:40PM +0000, James Bottomley wrote: > On Sat, 2012-11-03 at 13:46 +0000, Matthew Garrett wrote: > > I... what? Our signed bootloader will boot our signed kernel without any > > physically present end-user involvement. We therefore need to make it > > as difficult as practically possible for an attacker to use our signed > > bootloader and our signed kernel as an attack vector against other > > operating systems, which includes worrying about hibernate and kexec. If > > people want to support this use case then patches to deal with that need > > to be present in the upstream kernel. > > Right, but what I'm telling you is that by deciding to allow automatic > first boot, you're causing the windows attack vector problem. You could > easily do a present user test only on first boot which would eliminate > it. Instead, we get all of this. Your definition of "Best practices" is "Automated installs are impossible"? Have you ever actually spoken to a user? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-04 4:28 ` Matthew Garrett @ 2012-11-04 9:14 ` James Bottomley 2012-11-04 13:52 ` Matthew Garrett 2012-11-04 11:53 ` Pavel Machek 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-04 9:14 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun, 2012-11-04 at 04:28 +0000, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 10:56:40PM +0000, James Bottomley wrote: > > On Sat, 2012-11-03 at 13:46 +0000, Matthew Garrett wrote: > > > I... what? Our signed bootloader will boot our signed kernel without any > > > physically present end-user involvement. We therefore need to make it > > > as difficult as practically possible for an attacker to use our signed > > > bootloader and our signed kernel as an attack vector against other > > > operating systems, which includes worrying about hibernate and kexec. If > > > people want to support this use case then patches to deal with that need > > > to be present in the upstream kernel. > > > > Right, but what I'm telling you is that by deciding to allow automatic > > first boot, you're causing the windows attack vector problem. You could > > easily do a present user test only on first boot which would eliminate > > it. Instead, we get all of this. > > Your definition of "Best practices" is "Automated installs are > impossible"? Have you ever actually spoken to a user? Are you sure you've spoken to the right users if you think they use a distro boot system to do automated installs? I've actually had more than enough experience with automated installs over my career: they're either done by paying someone or using a provisioning system. In either case, they provision a static image and boot environment description, including EFI boot services variables, so you can provision a default MOK database if you want the ignition image not to pause on firstboot. There is obviously the question of making the provisioning systems secure, but it's a separate one from making boot secure. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-04 9:14 ` James Bottomley @ 2012-11-04 13:52 ` Matthew Garrett 2012-11-05 6:14 ` Eric W. Biederman 2012-11-05 8:20 ` James Bottomley 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-04 13:52 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun, Nov 04, 2012 at 09:14:47AM +0000, James Bottomley wrote: > I've actually had more than enough experience with automated installs > over my career: they're either done by paying someone or using a > provisioning system. In either case, they provision a static image and > boot environment description, including EFI boot services variables, so > you can provision a default MOK database if you want the ignition image > not to pause on firstboot. And now you've moved the attack vector to a copy of your provisioning system instead. > There is obviously the question of making the provisioning systems > secure, but it's a separate one from making boot secure. You don't get to punt on making the kernel secure by simply asserting that some other system can be secure instead. The chain of trust needs to go all the way back - if your security model is based on all installs needing a physically present end user, all installs need a physically present end user. That's not acceptable, so we need a different security model. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-04 13:52 ` Matthew Garrett @ 2012-11-05 6:14 ` Eric W. Biederman 2012-11-05 7:12 ` H. Peter Anvin 2012-11-05 8:20 ` James Bottomley 1 sibling, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-05 6:14 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Sun, Nov 04, 2012 at 09:14:47AM +0000, James Bottomley wrote: > >> I've actually had more than enough experience with automated installs >> over my career: they're either done by paying someone or using a >> provisioning system. In either case, they provision a static image and >> boot environment description, including EFI boot services variables, so >> you can provision a default MOK database if you want the ignition image >> not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. > >> There is obviously the question of making the provisioning systems >> secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. Bzzzt. Theory and reality disagreeing. I have done a lot of automatic installs. At the very least someone has to be present to apply power to the hardware. So someone being present is not a requirement you can remove. Furthermore in most cases an automatic install requires kicking the system into network boot mode or into inserting an install cd. Both are actions that require a user to be present. The goal is to reduce what a user must do to a minimum to remove the possibility of human error, not to reduce what must happen into absurdity. The other side is that a general purpose configuration of firmware almost never is suitable for a general install. So either some small amount of time must be spent fixing the BIOS settings or have an appropriate set of BIOS settings come from your supplier. In practice what I would expect of a UEFI system that ships ready for automatic installs is a system that initiall boots up in "setup mode" where it is possible to install your own platform signing key. What I would expect to happen in that situation is that during the first boot software would come over the network or from an install cd and install my platform signing key. Then a bootloader signed with my key would be installed, and then everything would chain from there. In most cases where I would be setting up an automatic install I would not install Microsoft's key, and I would definitely not sign my bootloader with Microsoft's key. At most I would sign my own "key install" with Microsoft's key. Then in cases of automatic reinstallation my key would be in the firmware and I could change my bootloader and my kernels at will with no risk that some third party could do anything to the machine unless they manged to get physical access. If I was a distroy my key would that I would install by default would be the distro's signing key. Although honestly I would still prefer a solution where I could lock things down a little farther. In any case the notion that unattended install with no user interaction on any uefi machine in any state is complete and total rubbish. It can't be done. You need power and you need boot media. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 6:14 ` Eric W. Biederman @ 2012-11-05 7:12 ` H. Peter Anvin 2012-11-05 7:24 ` Eric W. Biederman 0 siblings, 1 reply; 224+ messages in thread From: H. Peter Anvin @ 2012-11-05 7:12 UTC (permalink / raw) To: Eric W. Biederman Cc: Matthew Garrett, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/05/2012 07:14 AM, Eric W. Biederman wrote: > > In any case the notion that unattended install with no user interaction > on any uefi machine in any state is complete and total rubbish. It > can't be done. You need power and you need boot media. > That is a hugely different thing from needing a console. -hpa ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 7:12 ` H. Peter Anvin @ 2012-11-05 7:24 ` Eric W. Biederman 2012-11-05 7:40 ` H. Peter Anvin 2012-11-05 12:38 ` Matthew Garrett 0 siblings, 2 replies; 224+ messages in thread From: Eric W. Biederman @ 2012-11-05 7:24 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi "H. Peter Anvin" <hpa@zytor.com> writes: > On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >> >> In any case the notion that unattended install with no user interaction >> on any uefi machine in any state is complete and total rubbish. It >> can't be done. You need power and you need boot media. >> > > That is a hugely different thing from needing a console. Not at all. In the general case user intereaction is required to tell the system to boot off of your choosen boot media instead of the local hard drive. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 7:24 ` Eric W. Biederman @ 2012-11-05 7:40 ` H. Peter Anvin 2012-11-05 8:50 ` Eric W. Biederman 2012-11-05 12:38 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: H. Peter Anvin @ 2012-11-05 7:40 UTC (permalink / raw) To: ebiederm Cc: Matthew Garrett, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi This is not a good thing to assume. A vendor could have an external button, gor example. ebiederm@xmission.com wrote: >"H. Peter Anvin" <hpa@zytor.com> writes: > >> On 11/05/2012 07:14 AM, Eric W. Biederman wrote: >>> >>> In any case the notion that unattended install with no user >interaction >>> on any uefi machine in any state is complete and total rubbish. It >>> can't be done. You need power and you need boot media. >>> >> >> That is a hugely different thing from needing a console. > >Not at all. > >In the general case user intereaction is required to tell the system to >boot off of your choosen boot media instead of the local hard drive. > >Eric -- Sent from my mobile phone. Please excuse brevity and lack of formatting. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 7:40 ` H. Peter Anvin @ 2012-11-05 8:50 ` Eric W. Biederman 2012-11-05 8:53 ` H. Peter Anvin 0 siblings, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-05 8:50 UTC (permalink / raw) To: H. Peter Anvin Cc: Matthew Garrett, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi "H. Peter Anvin" <hpa@zytor.com> writes: > This is not a good thing to assume. A vendor could have an external > button, for example. Facts are always a good thing to assume. The fact is the general case does not admit an install without user interaction. It makes a lot of sense to revisit the working assumptions when for lack of 3 o4 4 lines in the bootloader people are advocating turning gold into lead at the cost of a national banking bailout. Non-interactive installs are very interesting but they only make sense in a very narrow range of cases not on every in every BIOS state on every machine. If the UEFI firmware will let me install a platform key and set ever other firmware setting in my installer, then it is a good starting state. The rest of the time there will be some unpredictable inconsistent mess of firmware settings that someone is going to have to go in and fix. Or the install cd will have blown away my existing partitions deleting data I forgot to back up that day. The notion that a non-interactive install is possible in the general case is complete and total hogwash. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 8:50 ` Eric W. Biederman @ 2012-11-05 8:53 ` H. Peter Anvin 0 siblings, 0 replies; 224+ messages in thread From: H. Peter Anvin @ 2012-11-05 8:53 UTC (permalink / raw) To: Eric W. Biederman Cc: Matthew Garrett, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/05/2012 09:50 AM, Eric W. Biederman wrote: > > Facts are always a good thing to assume. > > The fact is the general case does not admit an install without user > interaction. > In the general case, no. However, that is not a good reason to rule out the cases where it *can* be done; especially as vendors are starting to wake up to actual needs of users and of Linux in particular. -hpa ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 7:24 ` Eric W. Biederman 2012-11-05 7:40 ` H. Peter Anvin @ 2012-11-05 12:38 ` Matthew Garrett 2012-11-05 13:44 ` Alan Cox 2012-11-05 19:16 ` Eric W. Biederman 1 sibling, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-05 12:38 UTC (permalink / raw) To: Eric W. Biederman Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: > "H. Peter Anvin" <hpa@zytor.com> writes: > > > > That is a hugely different thing from needing a console. > > Not at all. > > In the general case user intereaction is required to tell the system to > boot off of your choosen boot media instead of the local hard drive. No, in the general case the system will do that once it fails to find a bootable OS on the drive. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 12:38 ` Matthew Garrett @ 2012-11-05 13:44 ` Alan Cox 2012-11-05 13:46 ` Matthew Garrett 2012-11-05 19:16 ` Eric W. Biederman 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-05 13:44 UTC (permalink / raw) To: Matthew Garrett Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, 5 Nov 2012 12:38:58 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: > > "H. Peter Anvin" <hpa@zytor.com> writes: > > > > > > That is a hugely different thing from needing a console. > > > > Not at all. > > > > In the general case user intereaction is required to tell the system to > > boot off of your choosen boot media instead of the local hard drive. > > No, in the general case the system will do that once it fails to find a > bootable OS on the drive. So your "secure" system can be wiped by a random Windows 8 install media. Ooh thats good stuff 8) ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 13:44 ` Alan Cox @ 2012-11-05 13:46 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-05 13:46 UTC (permalink / raw) To: Alan Cox Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 01:44:36PM +0000, Alan Cox wrote: > On Mon, 5 Nov 2012 12:38:58 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > No, in the general case the system will do that once it fails to find a > > bootable OS on the drive. > > So your "secure" system can be wiped by a random Windows 8 install media. > Ooh thats good stuff 8) Once you've booted trusted code you can change the boot order. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 12:38 ` Matthew Garrett 2012-11-05 13:44 ` Alan Cox @ 2012-11-05 19:16 ` Eric W. Biederman 2012-11-05 20:25 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-05 19:16 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Sun, Nov 04, 2012 at 11:24:17PM -0800, Eric W. Biederman wrote: >> "H. Peter Anvin" <hpa@zytor.com> writes: >> > >> > That is a hugely different thing from needing a console. >> >> Not at all. >> >> In the general case user intereaction is required to tell the system to >> boot off of your choosen boot media instead of the local hard drive. > > No, in the general case the system will do that once it fails to find a > bootable OS on the drive. In the general case there will be a bootable OS on the drive. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 19:16 ` Eric W. Biederman @ 2012-11-05 20:25 ` Matthew Garrett 2012-11-06 2:46 ` Eric W. Biederman 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-05 20:25 UTC (permalink / raw) To: Eric W. Biederman Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: > Matthew Garrett <mjg59@srcf.ucam.org> writes: > > No, in the general case the system will do that once it fails to find a > > bootable OS on the drive. > > In the general case there will be a bootable OS on the drive. That's in no way a given. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 20:25 ` Matthew Garrett @ 2012-11-06 2:46 ` Eric W. Biederman 2012-11-06 3:12 ` Matthew Garrett 0 siblings, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-06 2:46 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> Matthew Garrett <mjg59@srcf.ucam.org> writes: >> > No, in the general case the system will do that once it fails to find a >> > bootable OS on the drive. >> >> In the general case there will be a bootable OS on the drive. > > That's in no way a given. You have it backwards. The conclusion here is that having a case where a non-interactive install is possible is not a given. Therefore inflicting the entire rest of the ecosystem with requirements that only exist in the union of the requirements for non-interactive installs and installs on a machine with an existing machine does not make sense. In situations where a non-interactive install is interesting. Aka an empty boot disk it is not interesting to guard against. In situations where interaction happens is where windows may already exists and so spoofing windows is a design consideration and and a user presence test does not break the design. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 2:46 ` Eric W. Biederman @ 2012-11-06 3:12 ` Matthew Garrett 2012-11-06 3:36 ` Eric W. Biederman 2012-11-06 8:13 ` Valdis.Kletnieks 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 3:12 UTC (permalink / raw) To: Eric W. Biederman Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > Matthew Garrett <mjg59@srcf.ucam.org> writes: > > > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: > >> Matthew Garrett <mjg59@srcf.ucam.org> writes: > >> > No, in the general case the system will do that once it fails to find a > >> > bootable OS on the drive. > >> > >> In the general case there will be a bootable OS on the drive. > > > > That's in no way a given. > > You have it backwards. The conclusion here is that having a case where > a non-interactive install is possible is not a given. I deal with customers who perform non-interactive installs. The fact that you don't care about that use case is entirely irrelevant to me, because you're not the person that I am obliged to satisfy. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 3:12 ` Matthew Garrett @ 2012-11-06 3:36 ` Eric W. Biederman 2012-11-06 3:53 ` Matthew Garrett 2012-11-06 8:13 ` Valdis.Kletnieks 1 sibling, 1 reply; 224+ messages in thread From: Eric W. Biederman @ 2012-11-06 3:36 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: >> Matthew Garrett <mjg59@srcf.ucam.org> writes: >> >> > On Mon, Nov 05, 2012 at 11:16:12AM -0800, Eric W. Biederman wrote: >> >> Matthew Garrett <mjg59@srcf.ucam.org> writes: >> >> > No, in the general case the system will do that once it fails to find a >> >> > bootable OS on the drive. >> >> >> >> In the general case there will be a bootable OS on the drive. >> > >> > That's in no way a given. >> >> You have it backwards. The conclusion here is that having a case where >> a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. I have spent what feels like half my life doing automatic installs. I care a lot and I understand the requirements. I also see through misstatements about reality used to justify stupid design decisions. For automated installs you don't have to satisfy me. Feel free to deliver a lousy solution to your users. Just don't use your arbitrary design decisions to justify your kernel patches. Non-interactive installs do not justify removing all trust from the root user of a system, disabling suspend to disk and completely rewriting kexec for the simple expedient removing a couple of lines of code from your bootloader. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 3:36 ` Eric W. Biederman @ 2012-11-06 3:53 ` Matthew Garrett 2012-11-06 5:19 ` Eric W. Biederman 2012-11-06 9:12 ` Alan Cox 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 3:53 UTC (permalink / raw) To: Eric W. Biederman Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > For automated installs you don't have to satisfy me. Feel free to > deliver a lousy solution to your users. Just don't use your arbitrary > design decisions to justify your kernel patches. My kernel patches are justified by genuine user requirements. If you don't feel that there's any requirement for the kernel to satisfy the people who use it, you're free to ignore those patches. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 3:53 ` Matthew Garrett @ 2012-11-06 5:19 ` Eric W. Biederman 2012-11-06 5:34 ` Matthew Garrett 2012-11-06 7:56 ` Florian Weimer 2012-11-06 9:12 ` Alan Cox 1 sibling, 2 replies; 224+ messages in thread From: Eric W. Biederman @ 2012-11-06 5:19 UTC (permalink / raw) To: Matthew Garrett Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi Matthew Garrett <mjg59@srcf.ucam.org> writes: > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > >> For automated installs you don't have to satisfy me. Feel free to >> deliver a lousy solution to your users. Just don't use your arbitrary >> design decisions to justify your kernel patches. > > My kernel patches are justified by genuine user requirements. Hogwash. If windows is not present on a system linux can not be used to boot a compromised version of windows without user knowledge because windows is not present. If windows is present on a system then to install linux a user must be present and push buttons to get the system to boot off of install media. If a user is present a user presence test may be used to prevent a bootloader signed with Microsoft's key from booting linux without the users consent, and thus prevent Linux from attacking windows users. Therefore preventing the revokation of a signature with Microsoft's signature from your bootloader does not justify elaborate kernel modifications to prevent the booting a compromised version of windows. Furthermore no matter how hard we try with current techniques there will eventually be kernel bugs that allow attackers to inject code into the kernel. So attempting to fully close that attack vector is questionable. > If you > don't feel that there's any requirement for the kernel to satisfy the > people who use it, you're free to ignore those patches. I feel allowing the kernel to be hacked to bits and decend into an unmaintainable mess does not serve the users who use the kernel, and to prevent that technically poor patches should be rejected. This helps prevent non-technical considerations from justifying technically poor decisions. Eric ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 5:19 ` Eric W. Biederman @ 2012-11-06 5:34 ` Matthew Garrett 2012-11-06 7:56 ` Florian Weimer 1 sibling, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 5:34 UTC (permalink / raw) To: Eric W. Biederman Cc: H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 09:19:46PM -0800, Eric W. Biederman wrote: > Matthew Garrett <mjg59@srcf.ucam.org> writes: > > > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > >> For automated installs you don't have to satisfy me. Feel free to > >> deliver a lousy solution to your users. Just don't use your arbitrary > >> design decisions to justify your kernel patches. > > > > My kernel patches are justified by genuine user requirements. > > Hogwash. You keep using that word, which is unfortunate. > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Correct. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. Incorrect. UEFI boot priorities can be set without physical user interaction. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. Correct, but precludes the kind of automated installs that I know real people do. The keys a machine carries don't vary depending on whether it shipped with Windows or not, so it's not possible to differentiate between the "shipped with Windows" and "shipped without Windows" cases when determining security models. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. That's a stretch. Bored now. You're adding nothing new to anyone's understanding of the problem, and I'm just saying the same thing I've been saying for months, so I don't see any purpose in discussing this with you further. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 5:19 ` Eric W. Biederman 2012-11-06 5:34 ` Matthew Garrett @ 2012-11-06 7:56 ` Florian Weimer 2012-11-06 15:14 ` Chris Friesen 1 sibling, 1 reply; 224+ messages in thread From: Florian Weimer @ 2012-11-06 7:56 UTC (permalink / raw) To: Eric W. Biederman Cc: Matthew Garrett, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi * Eric W. Biederman: > If windows is not present on a system linux can not be used to boot a > compromised version of windows without user knowledge because windows is > not present. Interesting idea. Unfortunately, it is very hard to detect reliably that Windows is not present from the bootloader, so it's not possible to use this approach to simplify matters. > If windows is present on a system then to install linux a user must be > present and push buttons to get the system to boot off of install media. That's not necessarily true. > If a user is present a user presence test may be used to prevent a > bootloader signed with Microsoft's key from booting linux without the > users consent, and thus prevent Linux from attacking windows users. As already explained, I don't think that user presence accomplishes anything. You need informed consent, and it's impossible to cram that on a 80x25 screen. You also need to make sure that you aren't unnecessarily alarmist. We don't want a "Linux may harm your computer" warning. > Therefore preventing the revokation of a signature with Microsoft's > signature from your bootloader does not justify elaborate kernel > modifications to prevent the booting a compromised version of windows. I don't like this approach, either. > Furthermore no matter how hard we try with current techniques there will > eventually be kernel bugs that allow attackers to inject code into the > kernel. So attempting to fully close that attack vector is > questionable. I suspect we'd need to revoke old binaries after a grace period. I guess the Microsoft approach is to revoke only what's actually used for attacks, but that leads to a lot of unpredictability for our users. It's also annoying if we figure out after release that we have to disable additional kernel functionality because it can be used to compromise the boot path. Users will not like that, especially if they do not use Windows at all. Personally, I think the only way out of this mess is to teach users how to disable Secure Boot. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 7:56 ` Florian Weimer @ 2012-11-06 15:14 ` Chris Friesen 2012-11-06 15:19 ` Jiri Kosina 2012-11-06 21:51 ` Florian Weimer 0 siblings, 2 replies; 224+ messages in thread From: Chris Friesen @ 2012-11-06 15:14 UTC (permalink / raw) To: Florian Weimer Cc: Eric W. Biederman, Matthew Garrett, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On 11/06/2012 01:56 AM, Florian Weimer wrote: > Personally, I think the only way out of this mess is to teach users > how to disable Secure Boot. If you're going to go that far, why not just get them to install a RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Secure boot does arguably solve a class of problems, so it seems a bit odd to recommend just throwing it out entirely. Chris ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 15:14 ` Chris Friesen @ 2012-11-06 15:19 ` Jiri Kosina 2012-11-06 21:51 ` Florian Weimer 1 sibling, 0 replies; 224+ messages in thread From: Jiri Kosina @ 2012-11-06 15:19 UTC (permalink / raw) To: Chris Friesen Cc: Florian Weimer, Eric W. Biederman, Matthew Garrett, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Tue, 6 Nov 2012, Chris Friesen wrote: > > Personally, I think the only way out of this mess is to teach users > > how to disable Secure Boot. > > If you're going to go that far, why not just get them to install a RedHat (or > SuSE, or Ubuntu, or whoever) key and use that instead? You always need to keep in mind the possibility of the key being revoked. > Secure boot does arguably solve a class of problems, so it seems a bit odd to > recommend just throwing it out entirely. Not really. It doesn't solve the the most usual attack vector used (i.e. exploiting the bug in the kernel ... and that's independent of the OS we are talking about). Just because it contains "secure" in its name, doesn't really make it a proper security solution. It should rather be called "vendor lock-in boot", or something like that. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 15:14 ` Chris Friesen 2012-11-06 15:19 ` Jiri Kosina @ 2012-11-06 21:51 ` Florian Weimer 2012-11-06 21:55 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Florian Weimer @ 2012-11-06 21:51 UTC (permalink / raw) To: Chris Friesen Cc: Eric W. Biederman, Matthew Garrett, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi * Chris Friesen: > On 11/06/2012 01:56 AM, Florian Weimer wrote: > >> Personally, I think the only way out of this mess is to teach users >> how to disable Secure Boot. > > If you're going to go that far, why not just get them to install a > RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead? Behind that key, considerable infrastructure is needed, and the challenges are not purely technical. I don't expect many such keys as a result. > Secure boot does arguably solve a class of problems, so it seems a bit > odd to recommend just throwing it out entirely. I have never seen a Linux system with a compromised boot path. Surely they exist out there, but they are rare. It's also relatively simple to detect such a compromise on disk, from the outside. Secure Boot doesn't even allow you to safely boot from PXE because Fedora's shim will automatically load an initrd which wipes all your disks. (Safe booting from network would be a compelling feature, but it's not in the focus of Secure Boot; that's client-only technology at the moment.) Some side effects, such as the end of proprietary kernel modules, may be desirable. But others are not, like missing hibernate support (or perhaps even X). ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 21:51 ` Florian Weimer @ 2012-11-06 21:55 ` Matthew Garrett 2012-11-06 22:06 ` Florian Weimer 2012-11-06 22:49 ` Alan Cox 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 21:55 UTC (permalink / raw) To: Florian Weimer, Chris Friesen Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader, just like when you book off CD. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 21:55 ` Matthew Garrett @ 2012-11-06 22:06 ` Florian Weimer 2012-11-06 22:31 ` Matthew Garrett 2012-11-06 22:49 ` Alan Cox 1 sibling, 1 reply; 224+ messages in thread From: Florian Weimer @ 2012-11-06 22:06 UTC (permalink / raw) To: Matthew Garrett Cc: Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi * Matthew Garrett: > I'm not sure why you think that Fedora PXE installs will > automatically wipe disks - they'll do whatever Kickstart tells them > to do. Or what the referenced initrd contains (which is not signed, for obvious reasons). The point is that "the bootloader is signed by Fedora" does not translate to "I can run this without worries". I'm not sure if anybody has made promises in this direction. But lack of a "do no harm" rule (which would have to prevent certain forms of unattended installation for sure) means that we do not get that many benefits out of Secure Boot. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 22:06 ` Florian Weimer @ 2012-11-06 22:31 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 22:31 UTC (permalink / raw) To: Florian Weimer Cc: Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi It protects against certain classes of compromise. It doesn't prevent rogue software damaging your system - anyone who gets root (and so could reconfigure your boot order) could just rm -rf / anyway. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 21:55 ` Matthew Garrett 2012-11-06 22:06 ` Florian Weimer @ 2012-11-06 22:49 ` Alan Cox 2012-11-06 22:47 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-06 22:49 UTC (permalink / raw) To: Matthew Garrett Cc: Florian Weimer, Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Tue, 06 Nov 2012 16:55:25 -0500 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > I'm not sure why you think that Fedora PXE installs will automatically wipe disks - they'll do whatever Kickstart tells them to do. The only thing relevant to secure boot here is that you need a signed bootloader, just like when you book off CD. They'll do whatever the kickstart file says - which means for any untrusted distribution path like PXE your kickstart file had better be signed too ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 22:49 ` Alan Cox @ 2012-11-06 22:47 ` Matthew Garrett [not found] ` <CAMFK0gt7oAr4ArD8FmD8QE+i4g4rSTmQjbbLcjs02xwQeXGx-A@mail.gmail.com> 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 22:47 UTC (permalink / raw) To: Alan Cox Cc: Florian Weimer, Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi Sure, and scripts run as root can wipe your files too. That's really not what this is all about. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
[parent not found: <CAMFK0gt7oAr4ArD8FmD8QE+i4g4rSTmQjbbLcjs02xwQeXGx-A@mail.gmail.com>]
* Re: [RFC] Second attempt at kernel secure boot support [not found] ` <CAMFK0gt7oAr4ArD8FmD8QE+i4g4rSTmQjbbLcjs02xwQeXGx-A@mail.gmail.com> @ 2012-11-07 14:55 ` Matthew Garrett 2012-11-08 10:18 ` James Courtier-Dutton [not found] ` <CAAMvbhFF=kb8TJ4oE+40Zrx7HD1OkD0NOYj7QEZegZKGtqDm_A@mail.gmail.com> 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-07 14:55 UTC (permalink / raw) To: Olivier Galibert Cc: Alan Cox, Florian Weimer, Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: > On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett <mjg59@srcf.ucam.org>wrote: > > > Sure, and scripts run as root can wipe your files too. That's really not > > what this is all about. > > What it is about then? What is secure boot supposed to do for the owner of > the computer in a linux context? I've not been able to understand it > through this discussion. It provides a chain of trust that allows you to ensure that a platform boots a trusted kernel. That's a pre-requisite for implementing any kind of fully trusted platform, but it's not sufficient in itself. One of those additional requirements is ensuring that the kernel *stays* trusted - in the past an attacker could just replace the kernel on disk and so there was little incentive to engage in more subtle attacks, but now that's impossible we need to care about them. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-07 14:55 ` Matthew Garrett @ 2012-11-08 10:18 ` James Courtier-Dutton [not found] ` <CAAMvbhFF=kb8TJ4oE+40Zrx7HD1OkD0NOYj7QEZegZKGtqDm_A@mail.gmail.com> 1 sibling, 0 replies; 224+ messages in thread From: James Courtier-Dutton @ 2012-11-08 10:18 UTC (permalink / raw) To: Matthew Garrett Cc: Olivier Galibert, Alan Cox, Florian Weimer, Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, LKML Mailing List, linux-security-module, linux-efi Hi, The basis for any secure boot is a way to detect that the system has been tampered with or not. "Tamper Evidence". There are two main vectors for a system to be tampered with. Someone local to the machine and remote users who can access the machine across a network interface. (this includes the local user installing a program from a remote source) You have a fair chance of protecting via physical means (Locked rooms, Background checks on users etc.) of preventing a user with malicious intent to access the local machine. The first thing a computer does when switched on is run its first code instructions. Commonly referred to as the BIOS. It would therefore be a requirement to ensure that the BIOS cannot be tampered with via any other method apart from physically located at the machine. Once you have a base computer code that cannot be tampered with, you can trust it. >From that point on, you can use digital signatures to build the chain of trust. Normally digital signatures would examine the binary, ensure the signature matches, and then run the code contained in it. It is vital that the private key used to sign binaries cannot be found on the local machine, otherwise an malicious user could use it to sign malicious code, and therefore break the trust. The binary files therefore must be signed on a separate computer, that is trusted and protected from malicious users. There is one known use case where the normal digital signature checks will not work and this is the Hibernate file. The files were digitally checked when loaded into a previously running machine. The state of the machine was then saved to a file. The problem is how to check the hibernate file has not been tampered with in the interim. As explained above, we cannot store a private key on the local machine, so some other method for checking that the hibernate file has not been tampered with is required. I would suggest the fix for this problem is working out a way to check the signature of binary files, while in RAM, or even on a running machine. This is the format that the hibernate file is, it is basically a RAM image. When starting a hibernate image, the file would have to be scanned and digital signature checked that all the executable code in the hibernate image was sourced from correctly digitally signed binaries. In fact, this last point, if done correctly, could replace virus scanners. We would then have a system that rather than scan for viruses, it instead scans for "tampering". Remaining problems: 1) deciding who you trust, and from that, which digital signatures/certificates you trust. 2) Handling compromised or expired signatures/certificates. For 2, if the signatures are attached in each binary file, in order to distribute a new set of signatures, you would have to re-distribute all the binary files. Not a good idea due to download size. I would therefore suggest that the signatures are distributed separately from the binary files, so that you can change the signatures without having to redistribute all the binary files. Summary: 1) The BIOS code and the certificate it uses to check subsequently loaded binaries should only be changeable by a user local to the machine or not changeable at all without changing hardware. For example, on some ARM based mobile phones, the BIOS and certificate it uses are in a ROM, so not changeable at all. It then uses a multi stage boot loader, with each stage providing for a different certificate to be used to the next stage. This then permits the certificates that are used to sign the Linux kernel to be changed without having to change the certificate in the ROM. For Secure boot for Linux, the BIOS and certificate should probably be controlled by the user who controls the physical access to his machine. Then multi stage boot loaders can be used to introduce a chain to trust to trust other certificates, such as the debian or redhat or Microsoft ones, if the user chooses to trust them. With the user using their own BIOS certificate, it is very unlikely for the remote malicious user to obtain the private key and thus compromise the security of the system. 2) When "tamper" is detected, the system should revert to a stable safe state. This probably means, prevent the system booting, and present the local user with the evidence of tampering. Letting the user choose the next step. On 7 November 2012 14:55, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Wed, Nov 07, 2012 at 09:19:35AM +0100, Olivier Galibert wrote: >> On Tue, Nov 6, 2012 at 11:47 PM, Matthew Garrett <mjg59@srcf.ucam.org>wrote: >> >> > Sure, and scripts run as root can wipe your files too. That's really not >> > what this is all about. >> >> What it is about then? What is secure boot supposed to do for the owner of >> the computer in a linux context? I've not been able to understand it >> through this discussion. > > It provides a chain of trust that allows you to ensure that a platform > boots a trusted kernel. That's a pre-requisite for implementing any kind > of fully trusted platform, but it's not sufficient in itself. One of > those additional requirements is ensuring that the kernel *stays* > trusted - in the past an attacker could just replace the kernel on disk > and so there was little incentive to engage in more subtle attacks, but > now that's impossible we need to care about them. > > -- > Matthew Garrett | mjg59@srcf.ucam.org > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 224+ messages in thread
[parent not found: <CAAMvbhFF=kb8TJ4oE+40Zrx7HD1OkD0NOYj7QEZegZKGtqDm_A@mail.gmail.com>]
* Re: [RFC] Second attempt at kernel secure boot support [not found] ` <CAAMvbhFF=kb8TJ4oE+40Zrx7HD1OkD0NOYj7QEZegZKGtqDm_A@mail.gmail.com> @ 2012-11-08 11:19 ` Alan Cox 0 siblings, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-08 11:19 UTC (permalink / raw) To: James Courtier-Dutton Cc: Matthew Garrett, Olivier Galibert, Florian Weimer, Chris Friesen, Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, LKML Mailing List, linux-security-module, linux-efi > You have a fair chance of protecting via physical means (Locked rooms, > Background checks on users etc.) of preventing a user with malicious intent > to access the local machine. So called "secure boot" doesn't deal with any kind of physical access, which also means its useless if a device is lost and returned and you don't know if it was in the hands of a third party. > The first thing a computer does when switched on is run its first code > instructions. Commonly referred to as the BIOS. A good deal more complicated than that. However the signing in hardware and early boot up on a lot of devices already goes as far as the BIOS if the system has BIOS or EFI if it doesn't. You also have all the devices to deal with. > Normally digital signatures would examine the binary, ensure the signature > matches, and then run the code contained in it. No - it's a good deal more complicated than that too. ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 3:53 ` Matthew Garrett 2012-11-06 5:19 ` Eric W. Biederman @ 2012-11-06 9:12 ` Alan Cox 2012-11-06 13:17 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-06 9:12 UTC (permalink / raw) To: Matthew Garrett Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Tue, 6 Nov 2012 03:53:52 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Mon, Nov 05, 2012 at 07:36:32PM -0800, Eric W. Biederman wrote: > > > For automated installs you don't have to satisfy me. Feel free to > > deliver a lousy solution to your users. Just don't use your arbitrary > > design decisions to justify your kernel patches. > > My kernel patches are justified by genuine user requirements. So are lots of patches tht don't go in because they are too ugly or too invasive or two special case for mainstream. There are two discussions here - is it worth Red Hat doing - that's up to Red Hat's business managers - is it worth merging into the kernel - that's not The capability bit is small and clean the rest of it is beginning to look far too ugly for upstream right now. Not to say it might not end up small and clean in the end. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 9:12 ` Alan Cox @ 2012-11-06 13:17 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 13:17 UTC (permalink / raw) To: Alan Cox Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Tue, Nov 06, 2012 at 09:12:17AM +0000, Alan Cox wrote: > - is it worth Red Hat doing - that's up to Red Hat's business managers > > - is it worth merging into the kernel - that's not > > The capability bit is small and clean the rest of it is beginning to look > far too ugly for upstream right now. Not to say it might not end up small > and clean in the end. I absolutely agree - the code has to be good enough to be accepted upstream and I've no objection to being told that better implementations must be produced. I do object to being told that there's no point in trying to find an acceptable implementation. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 3:12 ` Matthew Garrett 2012-11-06 3:36 ` Eric W. Biederman @ 2012-11-06 8:13 ` Valdis.Kletnieks 1 sibling, 0 replies; 224+ messages in thread From: Valdis.Kletnieks @ 2012-11-06 8:13 UTC (permalink / raw) To: Matthew Garrett Cc: Eric W. Biederman, H. Peter Anvin, James Bottomley, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi [-- Attachment #1: Type: text/plain, Size: 928 bytes --] On Tue, 06 Nov 2012 03:12:19 +0000, Matthew Garrett said: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > > You have it backwards. The conclusion here is that having a case where > > a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. You *do* realize that the fact you have some set of customers who perform non-interactive installs does *not* imply that being able to do so is a given, right? The fact it is available and doable for your customers does *not* mean it's available and doable in general. There's a big difference between "the design has to deal with the fact that some customers can do this on some subsets of hardware" and "the design is free to assume that this is doable". [-- Attachment #2: Type: application/pgp-signature, Size: 865 bytes --] ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-04 13:52 ` Matthew Garrett 2012-11-05 6:14 ` Eric W. Biederman @ 2012-11-05 8:20 ` James Bottomley 2012-11-05 12:36 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: James Bottomley @ 2012-11-05 8:20 UTC (permalink / raw) To: Matthew Garrett Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun, 2012-11-04 at 13:52 +0000, Matthew Garrett wrote: > On Sun, Nov 04, 2012 at 09:14:47AM +0000, James Bottomley wrote: > > > I've actually had more than enough experience with automated installs > > over my career: they're either done by paying someone or using a > > provisioning system. In either case, they provision a static image and > > boot environment description, including EFI boot services variables, so > > you can provision a default MOK database if you want the ignition image > > not to pause on firstboot. > > And now you've moved the attack vector to a copy of your provisioning > system instead. Well, no, it always exists: a lot of provisioning systems install efi (or previously dos) based agents not linux kernels. However it's a different vector since the efi agents tend to want to PXE boot and contact the image server. > > There is obviously the question of making the provisioning systems > > secure, but it's a separate one from making boot secure. > > You don't get to punt on making the kernel secure by simply asserting > that some other system can be secure instead. The chain of trust needs > to go all the way back - if your security model is based on all installs > needing a physically present end user, all installs need a physically > present end user. That's not acceptable, so we need a different security > model. I didn't. I advocated a simple security model which you asserted wouldn't allow unattended installs, so I explained how they could be done. James ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-05 8:20 ` James Bottomley @ 2012-11-05 12:36 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-05 12:36 UTC (permalink / raw) To: James Bottomley Cc: Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Mon, Nov 05, 2012 at 09:20:17AM +0100, James Bottomley wrote: > On Sun, 2012-11-04 at 13:52 +0000, Matthew Garrett wrote: > > You don't get to punt on making the kernel secure by simply asserting > > that some other system can be secure instead. The chain of trust needs > > to go all the way back - if your security model is based on all installs > > needing a physically present end user, all installs need a physically > > present end user. That's not acceptable, so we need a different security > > model. > > I didn't. I advocated a simple security model which you asserted > wouldn't allow unattended installs, so I explained how they could be > done. You've explained that a hypothetical piece of software could handle key provisioning without providing any explanation for how it would be able to do so in a secure manner. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-04 4:28 ` Matthew Garrett 2012-11-04 9:14 ` James Bottomley @ 2012-11-04 11:53 ` Pavel Machek 1 sibling, 0 replies; 224+ messages in thread From: Pavel Machek @ 2012-11-04 11:53 UTC (permalink / raw) To: Matthew Garrett Cc: James Bottomley, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Sun 2012-11-04 04:28:02, Matthew Garrett wrote: > On Sat, Nov 03, 2012 at 10:56:40PM +0000, James Bottomley wrote: > > On Sat, 2012-11-03 at 13:46 +0000, Matthew Garrett wrote: > > > I... what? Our signed bootloader will boot our signed kernel without any > > > physically present end-user involvement. We therefore need to make it > > > as difficult as practically possible for an attacker to use our signed > > > bootloader and our signed kernel as an attack vector against other > > > operating systems, which includes worrying about hibernate and kexec. If > > > people want to support this use case then patches to deal with that need > > > to be present in the upstream kernel. > > > > Right, but what I'm telling you is that by deciding to allow automatic > > first boot, you're causing the windows attack vector problem. You could > > easily do a present user test only on first boot which would eliminate > > it. Instead, we get all of this. > > Your definition of "Best practices" is "Automated installs are > impossible"? Have you ever actually spoken to a user? Always polite Matthew... Anyway, problem with introducing random signatures all over the kernel is that it does not _work_. You'll end up signing all the userspace, too. So far you want to sign kexec, soon you'll discover you need to sign s2disk, too, and then you realize X, wine and dosemu needs the same treatment. fwvm95 comes next. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-03 22:56 ` James Bottomley 2012-11-04 4:28 ` Matthew Garrett @ 2012-11-05 21:25 ` Florian Weimer 1 sibling, 0 replies; 224+ messages in thread From: Florian Weimer @ 2012-11-05 21:25 UTC (permalink / raw) To: James Bottomley Cc: Matthew Garrett, Pavel Machek, Chris Friesen, Eric Paris, Jiri Kosina, Oliver Neukum, Alan Cox, Josh Boyer, linux-kernel, linux-security-module, linux-efi * James Bottomley: > Right, but what I'm telling you is that by deciding to allow automatic > first boot, you're causing the windows attack vector problem. You could > easily do a present user test only on first boot which would eliminate > it. Apparently, the warning will look like this: WARNING: This Binary is unsigned Are you sure you wish to run an unsigned binary in a secure environment? To avoid this question in future place the platform into setup mode See http://www.linuxfoundation.org/uefi-setup-mode And reboot. I'm not convinced this will work because users will confirm their presence to get back into the system. We expect GNU/Linux users to do it, why wouldn't Windows users? (And what harm can an unsigned binary do to a "secure environment", anyway? If it's adversely affected, it can't be that secure, can it?) And what's the backup plan if users use this to boot into compromised Windows systems? ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 14:29 ` Eric Paris ` (2 preceding siblings ...) 2012-11-01 20:27 ` Pavel Machek @ 2012-11-02 14:55 ` Vivek Goyal 3 siblings, 0 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 14:55 UTC (permalink / raw) To: Eric Paris Cc: James Bottomley, Jiri Kosina, Oliver Neukum, Chris Friesen, Alan Cox, Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thu, Nov 01, 2012 at 10:29:17AM -0400, Eric Paris wrote: > On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > But that doesn't really help me: untrusted root is an oxymoron. > > Imagine you run windows and you've never heard of Linux. You like > that only windows kernels can boot on your box and not those mean > nasty hacked up malware kernels. Now some attacker manages to take > over your box because you clicked on that executable for young models > in skimpy bathing suits. That executable rewrote your bootloader to > launch a very small carefully crafted Linux environment. This Rewrote bootloader on disk so that it gets executed next time? It will not run as signature will not match. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 9:08 ` James Bottomley 2012-11-01 9:20 ` Jiri Kosina @ 2012-11-01 10:12 ` Oliver Neukum 1 sibling, 0 replies; 224+ messages in thread From: Oliver Neukum @ 2012-11-01 10:12 UTC (permalink / raw) To: James Bottomley Cc: Chris Friesen, Alan Cox, Matthew Garrett, Jiri Kosina, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Thursday 01 November 2012 09:08:25 James Bottomley wrote: > On Wed, 2012-10-31 at 23:19 +0100, Oliver Neukum wrote: > > On Wednesday 31 October 2012 15:58:05 Chris Friesen wrote: > > > On 10/31/2012 02:14 PM, Oliver Neukum wrote: > > > > > > That would do it on my system. > > > > Maybe in theory you could solve this by the kernel invalidating images > > > > it hasn't written itself and forbidding to change the resume partition from the > > > > kernel command line, but that would break user space hibernation. > > > > > > If the resuming kernel refuses to resume from images it didn't create > > > itself, why do you need to forbid changing the resume partition from the > > > kernel command line? > > > > You don't. Signed images solve the problem. > > I really don't think they do. The proposed attack vector is to try to > prevent a local root exploit from running arbitrary in-kernel code, > because that would compromise the secure boot part of the kernel. Well, it is an attempt to prevent unsigned code from altering signed code or data structures private to signed code. That can be seen as a technical question. What that is useful for is not strictly a technical question. We can of course discuss whether secure boot makes sense at all. But that is a different discussion. Once it is decided that it is to be implemented, some issues arise logically. > The point I'm making is that given that the majority of exploits will > already be able to execute arbitrary code in-kernel, there's not much > point trying to consider features like this as attacker prevention. We > should really be focusing on discussing why we'd want to prevent a > legitimate local root from writing to the suspend partition in a secure > boot environment. That is strictly speaking what we are discussing. First, it is not given that root is local. Second, we don't want to stop root from writing to a partition. We just want to prevent that from altering kernel memory. Regards Oliver ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:21 ` Alan Cox 2012-10-31 17:17 ` Matthew Garrett @ 2012-10-31 17:21 ` Jiri Kosina 1 sibling, 0 replies; 224+ messages in thread From: Jiri Kosina @ 2012-10-31 17:21 UTC (permalink / raw) To: Alan Cox Cc: Matthew Garrett, Josh Boyer, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012, Alan Cox wrote: > > > > Prepare (as a root) a hand-crafted image, reboot, let the kernel resume > > > > from that artificial image. > > > > > > It's not signed. It won't reboot from that image. > > > > The kernel is signed. The kernel doesn't check the signature on the > > suspend image. > > Which doesn't matter. How are you going to create the tampered image in > the first place ? Editing the suspend partition/file directly when trusted kernel is booted. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:55 ` Alan Cox 2012-10-31 15:55 ` Jiri Kosina @ 2012-10-31 15:56 ` Matthew Garrett 2012-10-31 17:08 ` Alan Cox 1 sibling, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 15:56 UTC (permalink / raw) To: Alan Cox Cc: Josh Boyer, Jiri Kosina, linux-kernel, linux-security-module, linux-efi 1) Gain root. 2) Modify swap partition directly. 3) Force reboot. 4) Win. Root should not have the ability to elevate themselves to running arbitrary kernel code. Therefore, the above attack needs to be impossible. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:56 ` Matthew Garrett @ 2012-10-31 17:08 ` Alan Cox 2012-10-31 17:08 ` Shea Levy 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:08 UTC (permalink / raw) To: Matthew Garrett Cc: Josh Boyer, Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012 15:56:35 +0000 Matthew Garrett <mjg59@srcf.ucam.org> wrote: > 1) Gain root. > 2) Modify swap partition directly. > 3) Force reboot. > 4) Win. > > Root should not have the ability to elevate themselves to running > arbitrary kernel code. Therefore, the above attack needs to be > impossible. To protect swap you need to basically disallow any unencrypted swap (as he OS can't prove any given swap device is local and inside the case) and disallow the use of most disk management tools (so you'll need to write a few new management interfaces or implement the BPF based command filters that have been discussed for years). In addition of course there is no requirement that a device returns the data you put on it so subverted removable media is a potential issue. Or indeed just cheap memory sticks that do it anyway ;) Oh and of course the file systems in default mode don't guarantee this so you'll need to fix ext3, ext4 8) ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:08 ` Alan Cox @ 2012-10-31 17:08 ` Shea Levy 0 siblings, 0 replies; 224+ messages in thread From: Shea Levy @ 2012-10-31 17:08 UTC (permalink / raw) To: Alan Cox Cc: Matthew Garrett, Josh Boyer, Jiri Kosina, linux-kernel, linux-security-module, linux-efi On 10/31/2012 01:08 PM, Alan Cox wrote: > On Wed, 31 Oct 2012 15:56:35 +0000 > Matthew Garrett <mjg59@srcf.ucam.org> wrote: > >> 1) Gain root. >> 2) Modify swap partition directly. >> 3) Force reboot. >> 4) Win. >> >> Root should not have the ability to elevate themselves to running >> arbitrary kernel code. Therefore, the above attack needs to be >> impossible. > To protect swap you need to basically disallow any unencrypted swap (as > he OS can't prove any given swap device is local and inside the case) and > disallow the use of most disk management tools (so you'll need to write a > few new management interfaces or implement the BPF based command filters > that have been discussed for years). Can any kernel memory get swapped? If not all root can do is mess with the memory of other userspace processes, which isn't a use-case that secure boot cares about from my understanding. > In addition of course there is no requirement that a device returns > the data you put on it so subverted removable media is a potential issue. > Or indeed just cheap memory sticks that do it anyway ;) > > Oh and of course the file systems in default mode don't guarantee this so > you'll need to fix ext3, ext4 8) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 14:54 ` Josh Boyer 2012-10-31 14:59 ` Shea Levy 2012-10-31 15:55 ` Alan Cox @ 2012-10-31 16:04 ` Jiri Kosina 2012-10-31 16:10 ` Josh Boyer 2 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-10-31 16:04 UTC (permalink / raw) To: Josh Boyer Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Wed, 31 Oct 2012, Josh Boyer wrote: > I have a patch that disables that. I imagine it will be included in the > next submission of the patchset. > > You can find it here in the meantime: > > http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch I don't see that patch touching kernel/power/user.c, so using 's2disk' to suspend machine seems to be still possible even with this patch applied, right? -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 16:04 ` Jiri Kosina @ 2012-10-31 16:10 ` Josh Boyer 0 siblings, 0 replies; 224+ messages in thread From: Josh Boyer @ 2012-10-31 16:10 UTC (permalink / raw) To: Jiri Kosina Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 12:04 PM, Jiri Kosina <jkosina@suse.cz> wrote: > On Wed, 31 Oct 2012, Josh Boyer wrote: > >> I have a patch that disables that. I imagine it will be included in the >> next submission of the patchset. >> >> You can find it here in the meantime: >> >> http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch > > I don't see that patch touching kernel/power/user.c, so using 's2disk' to > suspend machine seems to be still possible even with this patch applied, > right? Oh, yes. Good catch. I'll add similar checks there as well in the next revision. Thanks! josh ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 14:50 ` Jiri Kosina 2012-10-31 14:54 ` Josh Boyer @ 2012-10-31 15:02 ` Matthew Garrett 2012-10-31 15:05 ` Shea Levy ` (2 more replies) 1 sibling, 3 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 15:02 UTC (permalink / raw) To: Jiri Kosina; +Cc: linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote: > Reading stored memory image (potentially tampered before reboot) from disk > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > able to imagine a scenario how this could be made "secure" (without > storing private keys to sign the hibernation image on the machine itself > which, well, doesn't sound secure either). shim generates a public and private key. It hands the kernel the private key in a boot parameter and stores the public key in a boot variable. On suspend, the kernel signs the suspend image with that private key and discards it. On the next boot, shim generates a new key pair and hands the new private key to the kernel along with the old public key. The kernel verifies the suspend image before resuming it. The only way to subvert this would be to be able to access kernel memory directly, which means the attacker has already won. Now someone just needs to write it. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:02 ` Matthew Garrett @ 2012-10-31 15:05 ` Shea Levy 2012-10-31 15:09 ` Matthew Garrett 2012-11-02 15:30 ` Vivek Goyal 2012-11-06 12:51 ` Jiri Kosina 2 siblings, 1 reply; 224+ messages in thread From: Shea Levy @ 2012-10-31 15:05 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On 10/31/2012 11:02 AM, Matthew Garrett wrote: > On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote: > >> Reading stored memory image (potentially tampered before reboot) from disk >> is basically DMA-ing arbitrary data over the whole RAM. I am currently not >> able to imagine a scenario how this could be made "secure" (without >> storing private keys to sign the hibernation image on the machine itself >> which, well, doesn't sound secure either). > shim generates a public and private key. It hands the kernel the private > key in a boot parameter and stores the public key in a boot variable. On > suspend, the kernel signs the suspend image with that private key and > discards it. On the next boot, shim generates a new key pair and hands > the new private key to the kernel along with the old public key. The > kernel verifies the suspend image before resuming it. The only way to > subvert this would be to be able to access kernel memory Or the boot variable where you stored the key, but in that case I'd say the attacker has won too. > directly, which > means the attacker has already won. > > Now someone just needs to write it. > ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:05 ` Shea Levy @ 2012-10-31 15:09 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 15:09 UTC (permalink / raw) To: Shea Levy; +Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 11:05:08AM -0400, Shea Levy wrote: > Or the boot variable where you stored the key, but in that case I'd > say the attacker has won too. Right, in that case they can compromise MOK. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:02 ` Matthew Garrett 2012-10-31 15:05 ` Shea Levy @ 2012-11-02 15:30 ` Vivek Goyal 2012-11-02 15:42 ` Matthew Garrett 2012-11-06 12:51 ` Jiri Kosina 2 siblings, 1 reply; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 15:30 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 03:02:01PM +0000, Matthew Garrett wrote: > On Wed, Oct 31, 2012 at 03:50:00PM +0100, Jiri Kosina wrote: > > > Reading stored memory image (potentially tampered before reboot) from disk > > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > > able to imagine a scenario how this could be made "secure" (without > > storing private keys to sign the hibernation image on the machine itself > > which, well, doesn't sound secure either). > > shim generates a public and private key. It hands the kernel the private > key in a boot parameter and stores the public key in a boot variable. On > suspend, the kernel signs the suspend image with that private key and > discards it. On the next boot, shim generates a new key pair and hands > the new private key to the kernel along with the old public key. The > kernel verifies the suspend image before resuming it. The only way to > subvert this would be to be able to access kernel memory directly, which > means the attacker has already won. "crash" utility has module which allows reading kernel memory. So leaking this private key will be easier then you are thinking it to be. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:30 ` Vivek Goyal @ 2012-11-02 15:42 ` Matthew Garrett 2012-11-02 15:52 ` Vivek Goyal 0 siblings, 1 reply; 224+ messages in thread From: Matthew Garrett @ 2012-11-02 15:42 UTC (permalink / raw) To: Vivek Goyal; +Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: > "crash" utility has module which allows reading kernel memory. So leaking > this private key will be easier then you are thinking it to be. That's not upstream, right? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:42 ` Matthew Garrett @ 2012-11-02 15:52 ` Vivek Goyal 2012-11-02 16:22 ` Jiri Kosina 2012-11-02 16:35 ` Shuah Khan 0 siblings, 2 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 15:52 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 03:42:48PM +0000, Matthew Garrett wrote: > On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: > > > "crash" utility has module which allows reading kernel memory. So leaking > > this private key will be easier then you are thinking it to be. > > That's not upstream, right? Yes, checked with Dave, it is not upstream. Well, still it is a concern for distro kernel. So if we keep private key in kernel, looks like we shall have to disable one more feature in secureboot mode. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:52 ` Vivek Goyal @ 2012-11-02 16:22 ` Jiri Kosina 2012-11-02 18:30 ` Vivek Goyal 2012-11-02 16:35 ` Shuah Khan 1 sibling, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-02 16:22 UTC (permalink / raw) To: Vivek Goyal Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Fri, 2 Nov 2012, Vivek Goyal wrote: > > > "crash" utility has module which allows reading kernel memory. So leaking > > > this private key will be easier then you are thinking it to be. > > > > That's not upstream, right? > > Yes, checked with Dave, it is not upstream. Well, still it is a concern > for distro kernel. Well, that's about /dev/crash, right? How about /proc/kcore? -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 16:22 ` Jiri Kosina @ 2012-11-02 18:30 ` Vivek Goyal 0 siblings, 0 replies; 224+ messages in thread From: Vivek Goyal @ 2012-11-02 18:30 UTC (permalink / raw) To: Jiri Kosina Cc: Matthew Garrett, linux-kernel, linux-security-module, linux-efi On Fri, Nov 02, 2012 at 05:22:41PM +0100, Jiri Kosina wrote: > On Fri, 2 Nov 2012, Vivek Goyal wrote: > > > > > "crash" utility has module which allows reading kernel memory. So leaking > > > > this private key will be easier then you are thinking it to be. > > > > > > That's not upstream, right? > > > > Yes, checked with Dave, it is not upstream. Well, still it is a concern > > for distro kernel. > > Well, that's about /dev/crash, right? Yes, I was talking about /dev/crash. > > How about /proc/kcore? Yes, we will have to lock down /proc/kcore too if we go the private key solution way. Thanks Vivek ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-02 15:52 ` Vivek Goyal 2012-11-02 16:22 ` Jiri Kosina @ 2012-11-02 16:35 ` Shuah Khan 1 sibling, 0 replies; 224+ messages in thread From: Shuah Khan @ 2012-11-02 16:35 UTC (permalink / raw) To: Vivek Goyal Cc: Matthew Garrett, Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Fri, Nov 2, 2012 at 9:52 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > On Fri, Nov 02, 2012 at 03:42:48PM +0000, Matthew Garrett wrote: >> On Fri, Nov 02, 2012 at 11:30:48AM -0400, Vivek Goyal wrote: >> >> > "crash" utility has module which allows reading kernel memory. So leaking >> > this private key will be easier then you are thinking it to be. >> >> That's not upstream, right? > > Yes, checked with Dave, it is not upstream. Well, still it is a concern > for distro kernel. > > So if we keep private key in kernel, looks like we shall have to disable > one more feature in secureboot mode. > I have been following parts of this thread and beginning to think, "Are we over engineering" the solution for secureboot. Do we have a list of what is must to meet the Spec.? At this point, Linux secureboot solution is sounding so pervasive and will impact every aspect of Linux user's and kernel developer's use pattern. So far I picked up on the following: Kernel need to be signed. firmware kernel loads needs to be signed What else? Is there a list of what all needs to be signed? I am interested in seeing a list of requirements. At some point, OS will be so secure that, will it become so complex to run anything on it and continue to do development as we are used to doing today? I don't pretend to know much about secureboot, and I am asking as a concerned Linux user, and kernel developer. -- Shuah ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 15:02 ` Matthew Garrett 2012-10-31 15:05 ` Shea Levy 2012-11-02 15:30 ` Vivek Goyal @ 2012-11-06 12:51 ` Jiri Kosina 2012-11-06 13:16 ` Matthew Garrett 2 siblings, 1 reply; 224+ messages in thread From: Jiri Kosina @ 2012-11-06 12:51 UTC (permalink / raw) To: Matthew Garrett Cc: linux-kernel, linux-security-module, linux-efi, James Bottomley, Shea Levy, Vivek Goyal On Wed, 31 Oct 2012, Matthew Garrett wrote: > > Reading stored memory image (potentially tampered before reboot) from disk > > is basically DMA-ing arbitrary data over the whole RAM. I am currently not > > able to imagine a scenario how this could be made "secure" (without > > storing private keys to sign the hibernation image on the machine itself > > which, well, doesn't sound secure either). > > shim generates a public and private key. It seems to me that this brings quite a huge delay into the boot process both for "regular" and resume cases (as shim has no way to know what is going to happen next). Mostly because obtaining enough entropy is generally very difficult when we have just shim running, right? > It hands the kernel the private key in a boot parameter and stores the > public key in a boot variable. On suspend, the kernel signs the suspend > image with that private key and discards it. On the next boot, shim > generates a new key pair and hands the new private key to the kernel > along with the old public key. The kernel verifies the suspend image > before resuming it. The only way to subvert this would be to be able to > access kernel memory directly, which means the attacker has already won. I like this protocol, but after some off-line discussions, I still have doubts about it. Namely: how do we make sure that there is noone tampering with the variable? Obvious step towards solving this is making the variable inaccessible after ExitBootServices() has been called (by not setting runtime access flag on it). Now how about this scenario: - consider securely booted win8 (no Linux installed on that machine, so the variable for storing public key doesn't exist yet), possibly being taken over by a malicious user - he/she creates this secure variable from within the win8 and stores his/her own public key into it - he/she supplies a signed shim (as provided by some Linux distro vendor), signed kernel (as provided by some Linux distro vendor) and specially crafted resume image, signed by his/her own private key - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 image is used to resume - distro kernel verifies the signature of the S4 image against the attacker's public key stored in the variable; the signature is OK - he/she has won, as he has managed to run an arbitrary kernel code (stored in the S4 image) in a trusted mode No? Basically, once the machine is already populated with the "secure" version of Linux, this can't happen, as we will (as far as I understand) set the variable for storing the public key in a way that it can't be accessed from runtime environment. But how can we prevent it being *created* before the machine is ever touched by Linux? Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-06 12:51 ` Jiri Kosina @ 2012-11-06 13:16 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-11-06 13:16 UTC (permalink / raw) To: Jiri Kosina Cc: linux-kernel, linux-security-module, linux-efi, James Bottomley, Shea Levy, Vivek Goyal On Tue, Nov 06, 2012 at 01:51:15PM +0100, Jiri Kosina wrote: > On Wed, 31 Oct 2012, Matthew Garrett wrote: > > shim generates a public and private key. > > It seems to me that this brings quite a huge delay into the boot process > both for "regular" and resume cases (as shim has no way to know what is > going to happen next). Mostly because obtaining enough entropy is > generally very difficult when we have just shim running, right? pseudorandom keys should be sufficient here. It's intended to deal with the case of an automated attack rather than a deliberate effort to break into a given user's system. > > It hands the kernel the private key in a boot parameter and stores the > > public key in a boot variable. On suspend, the kernel signs the suspend > > image with that private key and discards it. On the next boot, shim > > generates a new key pair and hands the new private key to the kernel > > along with the old public key. The kernel verifies the suspend image > > before resuming it. The only way to subvert this would be to be able to > > access kernel memory directly, which means the attacker has already won. > > I like this protocol, but after some off-line discussions, I still have > doubts about it. Namely: how do we make sure that there is noone tampering > with the variable? The variable has the same level of security as MOK, so that would be a more attractive target. > - consider securely booted win8 (no Linux installed on that machine, so > the variable for storing public key doesn't exist yet), possibly being > taken over by a malicious user > - he/she creates this secure variable from within the win8 and stores > his/her own public key into it You can't create a non-RT variable from the OS. > - he/she supplies a signed shim (as provided by some Linux distro vendor), > signed kernel (as provided by some Linux distro vendor) and specially > crafted resume image, signed by his/her own private key shim detects that the key has the RT bit set and deletes it. > - he/she reboots the machine in a way that shim+distro kernel+hacker's S4 > image is used to resume And so this step can't happen. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-29 17:41 ` Matthew Garrett 2012-10-31 14:50 ` Jiri Kosina @ 2012-10-31 17:28 ` Takashi Iwai 2012-10-31 17:37 ` Matthew Garrett 1 sibling, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-10-31 17:28 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi At Mon, 29 Oct 2012 17:41:31 +0000, Matthew Garrett wrote: > > On Mon, Oct 29, 2012 at 08:49:41AM +0100, Jiri Kosina wrote: > > On Thu, 20 Sep 2012, Matthew Garrett wrote: > > > > > This is pretty much identical to the first patchset, but with the capability > > > renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants > > > to deploy these then they should disable kexec until support for signed > > > kexec payloads has been merged. > > > > Apparently your patchset currently doesn't handle device firmware loading, > > nor do you seem to mention in in the comments. > > Correct. > > > I believe signed firmware loading should be put on plate as well, right? > > I think that's definitely something that should be covered. I hadn't > worried about it immediately as any attack would be limited to machines > with a specific piece of hardware, and the attacker would need to expend > a significant amount of reverse engineering work on the firmware - and > we'd probably benefit from them doing that in the long run... request_firmware() is used for microcode loading, too, so it's fairly a core part to cover, I'm afraid. I played a bit about this yesterday. The patch below is a proof of concept to (ab)use the module signing mechanism for firmware loading too. Sign firmware files via scripts/sign-file, and put to /lib/firmware/signed directory. It's just a rough cut, and the module options are other pieces there should be polished better, of course. Also another signature string should be better for firmware files :) Takashi --- diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index b34b5cd..2bc8415 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR this option you can point it elsewhere, such as /lib/firmware/ or some other directory containing the firmware files. +config FIRMWARE_SIG + bool "Firmware signature check" + depends on FW_LOADER && MODULE_SIG + help + Check the embedded signature of firmware files like signed modules. + config DEBUG_DRIVER bool "Driver Core verbose debug messages" depends on DEBUG_KERNEL diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 8945f4e..81fc8a4 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -268,6 +268,12 @@ static void fw_free_buf(struct firmware_buf *buf) /* direct firmware loading support */ static const char *fw_path[] = { +#ifdef CONFIG_FIRMWARE_SIG + "/lib/firmware/updates/" UTS_RELEASE "/signed", + "/lib/firmware/updates/signed", + "/lib/firmware/" UTS_RELEASE "/signed", + "/lib/firmware/signed", +#endif "/lib/firmware/updates/" UTS_RELEASE, "/lib/firmware/updates", "/lib/firmware/" UTS_RELEASE, @@ -844,6 +850,41 @@ exit: return fw_priv; } +#ifdef CONFIG_FIRMWARE_SIG +/* XXX */ +extern int mod_verify_sig(const void *mod, unsigned long *_modlen); + +static bool sig_enforce; +module_param(sig_enforce, bool, 0444); + +static int firmware_sig_check(struct firmware_buf *buf) +{ + unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1; + long len; + int err; + + len = buf->size - markerlen; + if (len <= 0 || + memcmp(buf->data + len, MODULE_SIG_STRING, markerlen)) { + pr_debug("%s: no signature found\n", buf->fw_id); + return sig_enforce ? -ENOKEY : 0; + } + err = mod_verify_sig(buf->data, &len); + if (err < 0) { + pr_debug("%s: signature error: %d\n", buf->fw_id, err); + return err; + } + buf->size = len; + pr_debug("%s: signature OK!\n", buf->fw_id); + return 0; +} +#else +static inline int firmware_sig_check(struct firmware_buf *buf) +{ + return 0; +} +#endif + static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, long timeout) { @@ -909,6 +950,9 @@ handle_fw: if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status)) retval = -ENOENT; + if (!retval) + retval = firmware_sig_check(buf); + /* * add firmware name into devres list so that we can auto cache * and uncache firmware for device. diff --git a/kernel/module_signing.c b/kernel/module_signing.c index ea1b1df..c39f49b 100644 --- a/kernel/module_signing.c +++ b/kernel/module_signing.c @@ -11,6 +11,7 @@ #include <linux/kernel.h> #include <linux/err.h> +#include <linux/export.h> #include <crypto/public_key.h> #include <crypto/hash.h> #include <keys/asymmetric-type.h> @@ -247,3 +248,4 @@ error_put_key: pr_devel("<==%s() = %d\n", __func__, ret); return ret; } +EXPORT_SYMBOL_GPL(mod_verify_sig); ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:28 ` Takashi Iwai @ 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 17:44 ` Alan Cox 2012-10-31 18:53 ` Takashi Iwai 0 siblings, 2 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:37 UTC (permalink / raw) To: Takashi Iwai; +Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote: > request_firmware() is used for microcode loading, too, so it's fairly > a core part to cover, I'm afraid. > > I played a bit about this yesterday. The patch below is a proof of > concept to (ab)use the module signing mechanism for firmware loading > too. Sign firmware files via scripts/sign-file, and put to > /lib/firmware/signed directory. That does still leave me a little uneasy as far as the microcode licenses go. I don't know that we can distribute signed copies of some of them, and we obviously can't sign at the user end. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:37 ` Matthew Garrett @ 2012-10-31 17:44 ` Alan Cox 2012-10-31 17:44 ` Matthew Garrett 2012-10-31 18:53 ` Takashi Iwai 1 sibling, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-10-31 17:44 UTC (permalink / raw) To: Matthew Garrett Cc: Takashi Iwai, Jiri Kosina, linux-kernel, linux-security-module, linux-efi > That does still leave me a little uneasy as far as the microcode > licenses go. I don't know that we can distribute signed copies of some > of them, and we obviously can't sign at the user end. You seem to put them in signed rpm packages ? ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:44 ` Alan Cox @ 2012-10-31 17:44 ` Matthew Garrett 0 siblings, 0 replies; 224+ messages in thread From: Matthew Garrett @ 2012-10-31 17:44 UTC (permalink / raw) To: Alan Cox Cc: Takashi Iwai, Jiri Kosina, linux-kernel, linux-security-module, linux-efi On Wed, Oct 31, 2012 at 05:44:40PM +0000, Alan Cox wrote: > > That does still leave me a little uneasy as far as the microcode > > licenses go. I don't know that we can distribute signed copies of some > > of them, and we obviously can't sign at the user end. > > You seem to put them in signed rpm packages ? That's not a modification of the files that say "You have permission to distribute unmodified versions of this file". If a lawyer says this is fine, I'm happy. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 17:44 ` Alan Cox @ 2012-10-31 18:53 ` Takashi Iwai 2012-11-01 4:21 ` joeyli 1 sibling, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-10-31 18:53 UTC (permalink / raw) To: Matthew Garrett Cc: Jiri Kosina, linux-kernel, linux-security-module, linux-efi At Wed, 31 Oct 2012 17:37:28 +0000, Matthew Garrett wrote: > > On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote: > > > request_firmware() is used for microcode loading, too, so it's fairly > > a core part to cover, I'm afraid. > > > > I played a bit about this yesterday. The patch below is a proof of > > concept to (ab)use the module signing mechanism for firmware loading > > too. Sign firmware files via scripts/sign-file, and put to > > /lib/firmware/signed directory. > > That does still leave me a little uneasy as far as the microcode > licenses go. I don't know that we can distribute signed copies of some > of them, and we obviously can't sign at the user end. Yeah, that's a concern. Although this is a sort of "container" and keeping the original data as is, it might be regarded as a modification. Another approach would be to a signature in a separate file, but I'm not sure whether it makes sense. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-10-31 18:53 ` Takashi Iwai @ 2012-11-01 4:21 ` joeyli 2012-11-01 13:18 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: joeyli @ 2012-11-01 4:21 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Jiri Kosina, linux-kernel, linux-security-module, linux-efi 於 三,2012-10-31 於 19:53 +0100,Takashi Iwai 提到: > At Wed, 31 Oct 2012 17:37:28 +0000, > Matthew Garrett wrote: > > > > On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote: > > > > > request_firmware() is used for microcode loading, too, so it's fairly > > > a core part to cover, I'm afraid. > > > > > > I played a bit about this yesterday. The patch below is a proof of > > > concept to (ab)use the module signing mechanism for firmware loading > > > too. Sign firmware files via scripts/sign-file, and put to > > > /lib/firmware/signed directory. > > > > That does still leave me a little uneasy as far as the microcode > > licenses go. I don't know that we can distribute signed copies of some > > of them, and we obviously can't sign at the user end. > > Yeah, that's a concern. Although this is a sort of "container" and > keeping the original data as is, it might be regarded as a > modification. > > Another approach would be to a signature in a separate file, but I'm > not sure whether it makes sense. > I think it make sense because the private key is still protected by signer. Any hacker who modified firmware is still need use private key to generate signature, but hacker's private key is impossible to match with the public key that kernel used to verify firmware. And, I afraid we have no choice that we need put the firmware signature in a separate file. Contacting with those company's legal department will be very time-consuming, and I am not sure all company will agree we put the signature with firmware then distribute. Thanks a lot! Joey Lee ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 4:21 ` joeyli @ 2012-11-01 13:18 ` Alan Cox 2012-11-05 17:13 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-01 13:18 UTC (permalink / raw) To: joeyli Cc: Takashi Iwai, Matthew Garrett, Jiri Kosina, linux-kernel, linux-security-module, linux-efi > I think it make sense because the private key is still protected by > signer. Any hacker who modified firmware is still need use private key > to generate signature, but hacker's private key is impossible to match > with the public key that kernel used to verify firmware. > > And, I afraid we have no choice that we need put the firmware signature > in a separate file. Contacting with those company's legal department > will be very time-consuming, and I am not sure all company will agree we > put the signature with firmware then distribute. Then you'd better stop storing it on disk because your disk drive is FEC encoding it and adding a CRC 8) It does want checking with a lawyer but my understanding is that if you have a file which is a package that contains the firmware and a signature then there is not generally a problem, any more than putting it in an RPM file - it's packaging/aggregation. This should be referred to the Linux Foundation folks perhaps - no point designing something badly to work around a non existant issue. Also the interface needs to consider that a lot of device firmware is already signed. Nobody notices because they don't ever try and do their own thus many drivers don't need extra signatures in fact. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [RFC] Second attempt at kernel secure boot support 2012-11-01 13:18 ` Alan Cox @ 2012-11-05 17:13 ` Takashi Iwai 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (2 more replies) 0 siblings, 3 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:13 UTC (permalink / raw) To: Alan Cox Cc: joeyli, Matthew Garrett, Jiri Kosina, linux-kernel, linux-security-module, linux-efi At Thu, 1 Nov 2012 13:18:49 +0000, Alan Cox wrote: > > > I think it make sense because the private key is still protected by > > signer. Any hacker who modified firmware is still need use private key > > to generate signature, but hacker's private key is impossible to match > > with the public key that kernel used to verify firmware. > > > > And, I afraid we have no choice that we need put the firmware signature > > in a separate file. Contacting with those company's legal department > > will be very time-consuming, and I am not sure all company will agree we > > put the signature with firmware then distribute. > > Then you'd better stop storing it on disk because your disk drive is FEC > encoding it and adding a CRC 8) > > It does want checking with a lawyer but my understanding is that if you > have a file which is a package that contains the firmware and a signature > then there is not generally a problem, any more than putting it in an RPM > file - it's packaging/aggregation. This should be referred to the Linux > Foundation folks perhaps - no point designing something badly to work > around a non existant issue. > > Also the interface needs to consider that a lot of device firmware is > already signed. Nobody notices because they don't ever try and do their > own thus many drivers don't need extra signatures in fact. Besides the legal concern, embedding the signature into the firmware makes the file incompatible with old kernel that has no support for signed firmware. That's the reason I put the files into a new location in my test patch, /lib/firmware/signed/. Having a separate signature file would make this easier. I cooked again quickly firmware loader code for the separate signature files. I'm going to send a series of test patches. thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:13 ` Takashi Iwai @ 2012-11-05 17:18 ` Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option Takashi Iwai ` (7 more replies) 2012-11-06 0:01 ` [PATCH RFC 0/4] Add firmware signature file check David Howells 2012-11-06 0:05 ` David Howells 2 siblings, 8 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:18 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi Hi, this is a patch series to add the support for firmware signature check. At this time, the kernel checks extra signature file (*.sig) for each firmware, instead of embedded signature. It's just a quick hack using the existing module signing mechanism, thus provided only as a proof of concept for now. To be noted, it doesn't support the firmwares via udev but only the direct loading, and the check for built-in firmware is missing, too. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai @ 2012-11-05 17:19 ` Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 2/4] scripts/sign-file: Support firmware signing Takashi Iwai ` (6 subsequent siblings) 7 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:19 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi Signed-off-by: Takashi Iwai <tiwai@suse.de> --- scripts/sign-file | 57 ++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 40 insertions(+), 17 deletions(-) diff --git a/scripts/sign-file b/scripts/sign-file index 87ca59d..45c771d 100755 --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,21 +4,31 @@ # # Format: # -# ./scripts/sign-file [-v] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-a algo] <key> <x509> <module> [<dest>] # # use strict; use FileHandle; use IPC::Open2; +use Getopt::Long; -my $verbose = 0; -if ($#ARGV >= 0 && $ARGV[0] eq "-v") { - $verbose = 1; - shift; +sub usage() +{ + print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] + -v verbose output + -a algo specify hash algorithm +"; + exit; } -die "Format: ./scripts/sign-file [-v] <key> <x509> <module> [<dest>]\n" - if ($#ARGV != 2 && $#ARGV != 3); +my $verbose = 0; +my $hashalgo = ""; + +GetOptions( + 'v|verbose' => \$verbose, + 'a|algo=s' => \$hashalgo) || usage(); + +usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; my $x509 = $ARGV[1]; @@ -32,10 +42,7 @@ die "Can't read module\n" unless (-r $module); # # Read the kernel configuration # -my %config = ( - CONFIG_MODULE_SIG_SHA512 => 1 - ); - +my %config; if (-r ".config") { open(FD, "<.config") || die ".config"; while (<FD>) { @@ -46,6 +53,22 @@ if (-r ".config") { close(FD); } +if ($hashalgo eq "") { + if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { + $hashalgo="sha1"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { + $hashalgo="sha224"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { + $hashalgo="sha256"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { + $hashalgo="sha384"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { + $hashalgo="sha512"; + } else { + die "Can't determine hash algorithm"; + } +} + # # Function to read the contents of a file into a variable. # @@ -322,35 +345,35 @@ my $id_type = 1; # Identifier type: X.509 # Digest the data # my ($dgst, $prologue) = (); -if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { +if ($hashalgo eq "sha1") { $prologue = pack("C*", 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14); $dgst = "-sha1"; $hash = 2; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { +} elsif ($hashalgo eq "sha224") { $prologue = pack("C*", 0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C); $dgst = "-sha224"; $hash = 7; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { +} elsif ($hashalgo eq "sha256") { $prologue = pack("C*", 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20); $dgst = "-sha256"; $hash = 4; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { +} elsif ($hashalgo eq "sha384") { $prologue = pack("C*", 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30); $dgst = "-sha384"; $hash = 5; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { +} elsif ($hashalgo eq "sha512") { $prologue = pack("C*", 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, @@ -358,7 +381,7 @@ if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { $dgst = "-sha512"; $hash = 6; } else { - die "Can't determine hash algorithm"; + die "Invalid hash algorithm $hashalgo"; } # -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH RFC 2/4] scripts/sign-file: Support firmware signing 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option Takashi Iwai @ 2012-11-05 17:19 ` Takashi Iwai 2012-11-05 17:20 ` [PATCH RFC 3/4] firmware: Add a signature check Takashi Iwai ` (5 subsequent siblings) 7 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:19 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi Add -f option to give a firmware signature file. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- scripts/sign-file | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/scripts/sign-file b/scripts/sign-file index 45c771d..c1c96e7 100755 --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,7 +4,7 @@ # # Format: # -# ./scripts/sign-file [-v] [-a algo] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-f] [-a algo] <key> <x509> <module> [<dest>] # # use strict; @@ -16,16 +16,19 @@ sub usage() { print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] -v verbose output + -f create a firmware signature file -a algo specify hash algorithm "; exit; } my $verbose = 0; +my $sign_fw = 0; my $hashalgo = ""; GetOptions( 'v|verbose' => \$verbose, + 'f|firmware' => \$sign_fw, 'a|algo=s' => \$hashalgo) || usage(); usage() if ($#ARGV != 2 && $#ARGV != 3); @@ -33,11 +36,12 @@ usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; my $x509 = $ARGV[1]; my $module = $ARGV[2]; -my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~"; +my $dest = $ARGV[3] ? $ARGV[3] : $ARGV[2] . ".sig"; +my $mode_name = $sign_fw ? "firmware" : "module"; die "Can't read private key\n" unless (-r $private_key); die "Can't read X.509 certificate\n" unless (-r $x509); -die "Can't read module\n" unless (-r $module); +die "Can't read $mode_name\n" unless (-r $module); # # Read the kernel configuration @@ -416,7 +420,9 @@ die "openssl rsautl died: $?" if ($? >> 8); # my $unsigned_module = read_file($module); -my $magic_number = "~Module signature appended~\n"; +my $magic_number = $sign_fw ? + "~Linux firmware signature~\n" : + "~Module signature appended~\n"; my $info = pack("CCCCCxxxN", $algo, $hash, $id_type, @@ -425,7 +431,7 @@ my $info = pack("CCCCCxxxN", length($signature)); if ($verbose) { - print "Size of unsigned module: ", length($unsigned_module), "\n"; + print "Size of unsigned $mode_name: ", length($unsigned_module), "\n"; print "Size of signer's name : ", length($signers_name), "\n"; print "Size of key identifier : ", length($key_identifier), "\n"; print "Size of signature : ", length($signature), "\n"; @@ -437,7 +443,16 @@ if ($verbose) { open(FD, ">$dest") || die $dest; binmode FD; -print FD +if ($sign_fw) { + print FD + $magic_number, + $info, + $signers_name, + $key_identifier, + $signature + ; +} else { + print FD $unsigned_module, $signers_name, $key_identifier, @@ -445,8 +460,9 @@ print FD $info, $magic_number ; +} close FD || die $dest; -if ($#ARGV != 3) { +if (!$sign_fw && $#ARGV != 3) { rename($dest, $module) || die $module; } -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* [PATCH RFC 3/4] firmware: Add a signature check 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 2/4] scripts/sign-file: Support firmware signing Takashi Iwai @ 2012-11-05 17:20 ` Takashi Iwai 2012-11-06 6:03 ` Mimi Zohar 2012-11-05 17:20 ` [PATCH RFC 4/4] firmware: Install signature files automatically Takashi Iwai ` (4 subsequent siblings) 7 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:20 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi Add a feature to check the firmware signature, specified via Kconfig CONFIG_FIRMWARE_SIG. The signature check is performed only for the direct fw loading without udev. Also no check for built-in firmware blobs is implemented yet. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/base/Kconfig | 6 +++++ drivers/base/firmware_class.c | 56 +++++++++++++++++++++++++++++++++++--- include/linux/firmware.h | 7 +++++ kernel/module_signing.c | 63 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 128 insertions(+), 4 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index b34b5cd..3696fd7 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR this option you can point it elsewhere, such as /lib/firmware/ or some other directory containing the firmware files. +config FIRMWARE_SIG + bool "Firmware signature verification" + depends on FW_LOADER && MODULE_SIG + help + Enable firmware signature check. + config DEBUG_DRIVER bool "Driver Core verbose debug messages" depends on DEBUG_KERNEL diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 8945f4e..575bc4c 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -36,6 +36,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz"); MODULE_DESCRIPTION("Multi purpose firmware loading support"); MODULE_LICENSE("GPL"); +#ifdef CONFIG_FIRMWARE_SIG +static bool sig_enforce; +module_param(sig_enforce, bool, 0644); +#endif + /* Builtin firmware support */ #ifdef CONFIG_FW_LOADER @@ -287,7 +292,7 @@ static noinline long fw_file_size(struct file *file) return st.size; } -static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf) +static bool fw_read_file_contents(struct file *file, void **bufp, size_t *sizep) { long size; char *buf; @@ -302,11 +307,39 @@ static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf vfree(buf); return false; } - fw_buf->data = buf; - fw_buf->size = size; + *bufp = buf; + *sizep = size; return true; } +#ifdef CONFIG_FIRMWARE_SIG +static bool verify_signature(struct firmware_buf *buf, const char *path) +{ + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - 1; + struct file *file; + void *sig_data; + size_t sig_size; + bool success; + + file = filp_open(path, O_RDONLY, 0); + if (IS_ERR(file)) + return false; + + success = fw_read_file_contents(file, &sig_data, &sig_size); + fput(file); + if (success) { + if (sig_size > markerlen && + !memcmp(sig_data, FIRMWARE_SIG_STRING, markerlen)) + success = !fw_verify_sig(buf->data, buf->size, + sig_data + markerlen, + sig_size - markerlen); + pr_debug("verified signature %s: %d\n", path, success); + vfree(sig_data); + } + return success; +} +#endif /* CONFIG_FIRMWARE_SIG */ + static bool fw_get_filesystem_firmware(struct firmware_buf *buf) { int i; @@ -320,8 +353,23 @@ static bool fw_get_filesystem_firmware(struct firmware_buf *buf) file = filp_open(path, O_RDONLY, 0); if (IS_ERR(file)) continue; - success = fw_read_file_contents(file, buf); + success = fw_read_file_contents(file, &buf->data, &buf->size); fput(file); +#ifdef CONFIG_FIRMWARE_SIG + if (success) { + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], + buf->fw_id); + if (!verify_signature(buf, path)) { + pr_err("Invalid signature file %s\n", path); + if (sig_enforce) { + vfree(buf->data); + buf->data = NULL; + buf->size = 0; + success = false; + } + } + } +#endif /* CONFIG_FIRMWARE_SIG */ if (success) break; } diff --git a/include/linux/firmware.h b/include/linux/firmware.h index e4279fe..2e9e457 100644 --- a/include/linux/firmware.h +++ b/include/linux/firmware.h @@ -79,4 +79,11 @@ static inline int uncache_firmware(const char *name) } #endif +#ifdef CONFIG_FIRMWARE_SIG +#define FIRMWARE_SIG_STRING "~Linux firmware signature~\n" +/* defined in kernel/module_signing.c */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size); +#endif + #endif diff --git a/kernel/module_signing.c b/kernel/module_signing.c index ea1b1df..7994452 100644 --- a/kernel/module_signing.c +++ b/kernel/module_signing.c @@ -11,6 +11,7 @@ #include <linux/kernel.h> #include <linux/err.h> +#include <linux/export.h> #include <crypto/public_key.h> #include <crypto/hash.h> #include <keys/asymmetric-type.h> @@ -247,3 +248,65 @@ error_put_key: pr_devel("<==%s() = %d\n", __func__, ret); return ret; } + +#ifdef CONFIG_FIRMWARE_SIG +/* + * Verify the firmware signature, similar like module signature check + * but it's stored in a separate file + */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size) +{ + struct public_key_signature *pks; + struct module_signature ms; + struct key *key; + size_t sig_len; + int ret; + + if (sig_size <= sizeof(ms)) + return -EBADMSG; + + memcpy(&ms, sig_data, sizeof(ms)); + sig_data += sizeof(ms); + sig_size -= sizeof(ms); + + sig_len = be32_to_cpu(ms.sig_len); + if (sig_size < sig_len + (size_t)ms.signer_len + ms.key_id_len) + return -EBADMSG; + + /* For the moment, only support RSA and X.509 identifiers */ + if (ms.algo != PKEY_ALGO_RSA || + ms.id_type != PKEY_ID_X509) + return -ENOPKG; + + if (ms.hash >= PKEY_HASH__LAST || + !pkey_hash_algo[ms.hash]) + return -ENOPKG; + + key = request_asymmetric_key(sig_data, ms.signer_len, + sig_data + ms.signer_len, ms.key_id_len); + if (IS_ERR(key)) + return PTR_ERR(key); + + pks = mod_make_digest(ms.hash, fw_data, fw_size); + if (IS_ERR(pks)) { + ret = PTR_ERR(pks); + goto error_put_key; + } + + sig_data += ms.signer_len + ms.key_id_len; + ret = mod_extract_mpi_array(pks, sig_data, sig_len); + if (ret < 0) + goto error_free_pks; + + ret = verify_signature(key, pks); + +error_free_pks: + mpi_free(pks->rsa.s); + kfree(pks); +error_put_key: + key_put(key); + return ret; +} +EXPORT_SYMBOL_GPL(fw_verify_sig); +#endif /* CONFIG_FIRMWARE_SIG */ -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 3/4] firmware: Add a signature check 2012-11-05 17:20 ` [PATCH RFC 3/4] firmware: Add a signature check Takashi Iwai @ 2012-11-06 6:03 ` Mimi Zohar 0 siblings, 0 replies; 224+ messages in thread From: Mimi Zohar @ 2012-11-06 6:03 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Mon, 2012-11-05 at 18:20 +0100, Takashi Iwai wrote: > Add a feature to check the firmware signature, specified via Kconfig > CONFIG_FIRMWARE_SIG. The signature check is performed only for the > direct fw loading without udev. Also no check for built-in firmware > blobs is implemented yet. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > drivers/base/Kconfig | 6 +++++ > drivers/base/firmware_class.c | 56 +++++++++++++++++++++++++++++++++++--- > include/linux/firmware.h | 7 +++++ > kernel/module_signing.c | 63 +++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 128 insertions(+), 4 deletions(-) > > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index b34b5cd..3696fd7 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR > this option you can point it elsewhere, such as /lib/firmware/ or > some other directory containing the firmware files. > > +config FIRMWARE_SIG > + bool "Firmware signature verification" > + depends on FW_LOADER && MODULE_SIG > + help > + Enable firmware signature check. > + > config DEBUG_DRIVER > bool "Driver Core verbose debug messages" > depends on DEBUG_KERNEL > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index 8945f4e..575bc4c 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -36,6 +36,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz"); > MODULE_DESCRIPTION("Multi purpose firmware loading support"); > MODULE_LICENSE("GPL"); > > +#ifdef CONFIG_FIRMWARE_SIG > +static bool sig_enforce; > +module_param(sig_enforce, bool, 0644); > +#endif > + > /* Builtin firmware support */ > > #ifdef CONFIG_FW_LOADER > @@ -287,7 +292,7 @@ static noinline long fw_file_size(struct file *file) > return st.size; > } > > -static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf) > +static bool fw_read_file_contents(struct file *file, void **bufp, size_t *sizep) > { > long size; > char *buf; > @@ -302,11 +307,39 @@ static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf > vfree(buf); > return false; > } > - fw_buf->data = buf; > - fw_buf->size = size; > + *bufp = buf; > + *sizep = size; > return true; > } > > +#ifdef CONFIG_FIRMWARE_SIG > +static bool verify_signature(struct firmware_buf *buf, const char *path) > +{ > + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - 1; > + struct file *file; > + void *sig_data; > + size_t sig_size; > + bool success; > + > + file = filp_open(path, O_RDONLY, 0); > + if (IS_ERR(file)) > + return false; > + > + success = fw_read_file_contents(file, &sig_data, &sig_size); > + fput(file); > + if (success) { > + if (sig_size > markerlen && > + !memcmp(sig_data, FIRMWARE_SIG_STRING, markerlen)) > + success = !fw_verify_sig(buf->data, buf->size, > + sig_data + markerlen, > + sig_size - markerlen); > + pr_debug("verified signature %s: %d\n", path, success); > + vfree(sig_data); > + } > + return success; > +} > +#endif /* CONFIG_FIRMWARE_SIG */ > + > static bool fw_get_filesystem_firmware(struct firmware_buf *buf) > { > int i; > @@ -320,8 +353,23 @@ static bool fw_get_filesystem_firmware(struct firmware_buf *buf) > file = filp_open(path, O_RDONLY, 0); > if (IS_ERR(file)) > continue; > - success = fw_read_file_contents(file, buf); > + success = fw_read_file_contents(file, &buf->data, &buf->size); > fput(file); > +#ifdef CONFIG_FIRMWARE_SIG > + if (success) { > + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], > + buf->fw_id); > + if (!verify_signature(buf, path)) { > + pr_err("Invalid signature file %s\n", path); > + if (sig_enforce) { > + vfree(buf->data); > + buf->data = NULL; > + buf->size = 0; > + success = false; > + } > + } > + } > +#endif /* CONFIG_FIRMWARE_SIG */ The existing kernel modules are read by userspace into a buffer, which is passed to the kernel. As there is no way of verifying what was read by userspace is the same as what was passed to the kernel, the signature verification is done, in the kernel, on the buffer contents. The new kernel module syscall passes a file descriptor. With commit "41110a4 ima: support new kernel module syscall" the kernel module signature is measured/appraised like any other file in the IMA policy. Although the default policy should already be measuring/appraising the firmware, because of the open, you might want to add a new hook FIRMWARE_CHECK here, for finer grain IMA policy control. thanks, Mimi > if (success) > break; > } > diff --git a/include/linux/firmware.h b/include/linux/firmware.h > index e4279fe..2e9e457 100644 > --- a/include/linux/firmware.h > +++ b/include/linux/firmware.h > @@ -79,4 +79,11 @@ static inline int uncache_firmware(const char *name) > } > #endif > > +#ifdef CONFIG_FIRMWARE_SIG > +#define FIRMWARE_SIG_STRING "~Linux firmware signature~\n" > +/* defined in kernel/module_signing.c */ > +int fw_verify_sig(const void *fw_data, size_t fw_size, > + const void *sig_data, size_t sig_size); > +#endif > + > #endif > diff --git a/kernel/module_signing.c b/kernel/module_signing.c > index ea1b1df..7994452 100644 > --- a/kernel/module_signing.c > +++ b/kernel/module_signing.c > @@ -11,6 +11,7 @@ > > #include <linux/kernel.h> > #include <linux/err.h> > +#include <linux/export.h> > #include <crypto/public_key.h> > #include <crypto/hash.h> > #include <keys/asymmetric-type.h> > @@ -247,3 +248,65 @@ error_put_key: > pr_devel("<==%s() = %d\n", __func__, ret); > return ret; > } > + > +#ifdef CONFIG_FIRMWARE_SIG > +/* > + * Verify the firmware signature, similar like module signature check > + * but it's stored in a separate file > + */ > +int fw_verify_sig(const void *fw_data, size_t fw_size, > + const void *sig_data, size_t sig_size) > +{ > + struct public_key_signature *pks; > + struct module_signature ms; > + struct key *key; > + size_t sig_len; > + int ret; > + > + if (sig_size <= sizeof(ms)) > + return -EBADMSG; > + > + memcpy(&ms, sig_data, sizeof(ms)); > + sig_data += sizeof(ms); > + sig_size -= sizeof(ms); > + > + sig_len = be32_to_cpu(ms.sig_len); > + if (sig_size < sig_len + (size_t)ms.signer_len + ms.key_id_len) > + return -EBADMSG; > + > + /* For the moment, only support RSA and X.509 identifiers */ > + if (ms.algo != PKEY_ALGO_RSA || > + ms.id_type != PKEY_ID_X509) > + return -ENOPKG; > + > + if (ms.hash >= PKEY_HASH__LAST || > + !pkey_hash_algo[ms.hash]) > + return -ENOPKG; > + > + key = request_asymmetric_key(sig_data, ms.signer_len, > + sig_data + ms.signer_len, ms.key_id_len); > + if (IS_ERR(key)) > + return PTR_ERR(key); > + > + pks = mod_make_digest(ms.hash, fw_data, fw_size); > + if (IS_ERR(pks)) { > + ret = PTR_ERR(pks); > + goto error_put_key; > + } > + > + sig_data += ms.signer_len + ms.key_id_len; > + ret = mod_extract_mpi_array(pks, sig_data, sig_len); > + if (ret < 0) > + goto error_free_pks; > + > + ret = verify_signature(key, pks); > + > +error_free_pks: > + mpi_free(pks->rsa.s); > + kfree(pks); > +error_put_key: > + key_put(key); > + return ret; > +} > +EXPORT_SYMBOL_GPL(fw_verify_sig); > +#endif /* CONFIG_FIRMWARE_SIG */ ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC 4/4] firmware: Install signature files automatically 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (2 preceding siblings ...) 2012-11-05 17:20 ` [PATCH RFC 3/4] firmware: Add a signature check Takashi Iwai @ 2012-11-05 17:20 ` Takashi Iwai 2012-11-05 18:12 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (3 subsequent siblings) 7 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 17:20 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi ... when CONFIG_FIRMWARE_SIG is set. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- Makefile | 6 ++++++ scripts/Makefile.fwinst | 18 ++++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index a1ccf22..c6d7a3e 100644 --- a/Makefile +++ b/Makefile @@ -729,6 +729,12 @@ mod_sign_cmd = true endif export mod_sign_cmd +ifeq ($(CONFIG_FIRMWARE_SIG),y) +fw_sign_cmd = perl $(srctree)/scripts/sign-file -f $(MODSECKEY) $(MODPUBKEY) +else +fw_sign_cmd = true +endif +export fw_sign_cmd ifeq ($(KBUILD_EXTMOD),) core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 4d908d1..df256f0 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -29,6 +29,20 @@ installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw)) installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ +ifeq ($(CONFIG_FIRMWARE_SIG),y) +installed-fw-sig := $(patsubst %,%.sig, $(installed-fw)) +installed-mod-fw-sig := $(patsubst %,%.sig, $(installed-mod-fw)) +else +installed-fw-sig := +installed-mod-fw-sig := +endif + +quiet_cmd_fwsig = FWSIG $@ + cmd_fwsig = $(fw_sign_cmd) $(patsubst %.sig,%,$@) $@ + +%.sig: % + $(call cmd,fwsig) + # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs $(INSTALL_FW_PATH)/$$(%): install-all-dirs @@ -49,9 +63,9 @@ PHONY += __fw_install __fw_modinst FORCE .PHONY: $(PHONY) -__fw_install: $(installed-fw) +__fw_install: $(installed-fw) $(installed-fw-sig) -__fw_modinst: $(installed-mod-fw) +__fw_modinst: $(installed-mod-fw) $(installed-mod-fw-sig) @: __fw_modbuild: $(addprefix $(obj)/,$(mod-fw)) -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (3 preceding siblings ...) 2012-11-05 17:20 ` [PATCH RFC 4/4] firmware: Install signature files automatically Takashi Iwai @ 2012-11-05 18:12 ` Takashi Iwai 2012-11-05 20:43 ` Josh Boyer ` (2 subsequent siblings) 7 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-05 18:12 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Mon, 05 Nov 2012 18:18:24 +0100, Takashi Iwai wrote: > > Hi, > > this is a patch series to add the support for firmware signature > check. At this time, the kernel checks extra signature file (*.sig) > for each firmware, instead of embedded signature. > It's just a quick hack using the existing module signing mechanism, > thus provided only as a proof of concept for now. > > To be noted, it doesn't support the firmwares via udev but only the > direct loading, and the check for built-in firmware is missing, too. On the second thought, checking the signature for builtin firmwares is superfluous. And udev usage for firmware loading should be pretty rare with 3.7 kernel. So, locking down the udev loading case when sig_enforce = true should suffice in most cases, I guess. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (4 preceding siblings ...) 2012-11-05 18:12 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai @ 2012-11-05 20:43 ` Josh Boyer 2012-11-06 6:46 ` Takashi Iwai 2012-11-06 2:30 ` Ming Lei 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai 7 siblings, 1 reply; 224+ messages in thread From: Josh Boyer @ 2012-11-05 20:43 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Mon, Nov 5, 2012 at 12:18 PM, Takashi Iwai <tiwai@suse.de> wrote: > Hi, > > this is a patch series to add the support for firmware signature > check. At this time, the kernel checks extra signature file (*.sig) > for each firmware, instead of embedded signature. > It's just a quick hack using the existing module signing mechanism, > thus provided only as a proof of concept for now. > > To be noted, it doesn't support the firmwares via udev but only the > direct loading, and the check for built-in firmware is missing, too. Just to make sure I'm reading this correctly, it will sign any of the firwmare files installed directly from the kernel tree if the option is set. So for the firmware in the linux-firmware tree we'd need to either copy that into the kernel tree during build time, or duplicate the signing bits in the linux-firmware tree itself. However if we do the latter, we'd probably need to use the same keys as the per-build kernel key which means copying keys (ew) or tell the kernel to include a separate firmware key in the extra list. I feel like I'm rambling a bit, but I'm trying to work out how signed firmware would look from a distro perspective. A significant amount of work has been done to decouple linux-firmware from the kernel tree and if signed firmware is used it seems to couple them together one way or another. At the moment, using generated per-build keys to come up with the firmware signatures seems a bit suboptimal in that regard. josh ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 20:43 ` Josh Boyer @ 2012-11-06 6:46 ` Takashi Iwai 2012-11-06 9:20 ` Alan Cox 0 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 6:46 UTC (permalink / raw) To: Josh Boyer Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Mon, 5 Nov 2012 15:43:09 -0500, Josh Boyer wrote: > > On Mon, Nov 5, 2012 at 12:18 PM, Takashi Iwai <tiwai@suse.de> wrote: > > Hi, > > > > this is a patch series to add the support for firmware signature > > check. At this time, the kernel checks extra signature file (*.sig) > > for each firmware, instead of embedded signature. > > It's just a quick hack using the existing module signing mechanism, > > thus provided only as a proof of concept for now. > > > > To be noted, it doesn't support the firmwares via udev but only the > > direct loading, and the check for built-in firmware is missing, too. > > Just to make sure I'm reading this correctly, it will sign any of the > firwmare files installed directly from the kernel tree if the option is > set. So for the firmware in the linux-firmware tree we'd need to > either copy that into the kernel tree during build time, or duplicate the > signing bits in the linux-firmware tree itself. However if we do the > latter, we'd probably need to use the same keys as the per-build kernel > key which means copying keys (ew) or tell the kernel to include a > separate firmware key in the extra list. Yes, the situation is as same as the external module builds. > I feel like I'm rambling a bit, but I'm trying to work out how signed > firmware would look from a distro perspective. A significant amount of > work has been done to decouple linux-firmware from the kernel tree and > if signed firmware is used it seems to couple them together one way or > another. Well, the primary question is whether the firmware signature check is required or not. Of course, these patches assume that it is for secure boot lockdown :) > At the moment, using generated per-build keys to come up with > the firmware signatures seems a bit suboptimal in that regard. But how would distro sign modules that are built externally? It should be the pretty same situation. I thought that the current module signing is already supported (at least accepted) by distro, even for external modules. Isn't it? thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 6:46 ` Takashi Iwai @ 2012-11-06 9:20 ` Alan Cox 2012-11-06 10:05 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Alan Cox @ 2012-11-06 9:20 UTC (permalink / raw) To: Takashi Iwai Cc: Josh Boyer, Matthew Garrett, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi > But how would distro sign modules that are built externally? > It should be the pretty same situation. I would start with the "would" and lawyers and liability and then stop worrying about the how. Absent someone actually intending to do it and saying so. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 9:20 ` Alan Cox @ 2012-11-06 10:05 ` Takashi Iwai 0 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 10:05 UTC (permalink / raw) To: Alan Cox Cc: Josh Boyer, Matthew Garrett, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 09:20:19 +0000, Alan Cox wrote: > > > But how would distro sign modules that are built externally? > > It should be the pretty same situation. > > I would start with the "would" and lawyers and liability and then stop > worrying about the how. Absent someone actually intending to do it and > saying so. Well, what I meant for external built modules are not about things like nvidia, but rather normal (legal) drivers or updated modules that are built from out-of-kernel source. I'm sure that distros will provide such update module packages on the secure boot system, too. So, discussing about "how" isn't so bad even for now, since this shall be anyway mandatory (for distros) once when the module signing is deployed. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (5 preceding siblings ...) 2012-11-05 20:43 ` Josh Boyer @ 2012-11-06 2:30 ` Ming Lei 2012-11-06 5:46 ` lee joey ` (2 more replies) 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai 7 siblings, 3 replies; 224+ messages in thread From: Ming Lei @ 2012-11-06 2:30 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai <tiwai@suse.de> wrote: > > To be noted, it doesn't support the firmwares via udev but only the > direct loading, and the check for built-in firmware is missing, too. Generally, both direct loading and udev may request one same firmware image. And after check failed, current firmware load will fallback on udev to complete loading, so looks a check-failed firmware still can be loaded into kernel no matter if there is firmware signature check or not. Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 2:30 ` Ming Lei @ 2012-11-06 5:46 ` lee joey 2012-11-06 7:03 ` Takashi Iwai [not found] ` <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com> 2 siblings, 0 replies; 224+ messages in thread From: lee joey @ 2012-11-06 5:46 UTC (permalink / raw) To: Ming Lei Cc: Takashi Iwai, Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi 2012/11/6 Ming Lei <tom.leiming@gmail.com>: > On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai <tiwai@suse.de> wrote: >> >> To be noted, it doesn't support the firmwares via udev but only the >> direct loading, and the check for built-in firmware is missing, too. > > Generally, both direct loading and udev may request one same firmware > image. And after check failed, current firmware load will fallback on udev > to complete loading, so looks a check-failed firmware still can be loaded > into kernel no matter if there is firmware signature check or not. > > > Thanks, > -- > Ming Lei > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ The udev direct write firmware through data attribute, maybe we can do the same signature verification in firmware_data_write? The following patch didn't test yet. Thanks Joey Lee >From 035dde5fadc9e7f4b7811b18d3a5094ef88e8bbb Mon Sep 17 00:00:00 2001 From: Lee, Chun-Yi <jlee@suse.com> Date: Tue, 6 Nov 2012 13:07:04 +0800 Subject: [PATCH] firmware: Add signature check to firmware_data_write --- drivers/base/firmware_class.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 8945f4e..40d8cc6 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -621,6 +621,7 @@ static ssize_t firmware_data_write(struct file *filp, struct kobject *kobj, struct firmware_priv *fw_priv = to_firmware_priv(dev); struct firmware_buf *buf; ssize_t retval; + bool success = false; if (!capable(CAP_SYS_RAWIO)) return -EPERM; @@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file *filp, struct kobject *kobj, } buf->size = max_t(size_t, offset, buf->size); + +#ifdef CONFIG_FIRMWARE_SIG + for (i = 0; i < ARRAY_SIZE(fw_path); i++) { + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], buf->fw_id); + if (verify_signature(buf, path)) + success = true; + } + if (!success) { + pr_err("Invalid signature file %s\n", path); + if (sig_enforce) { + vfree(buf->data); + buf->data = NULL; + buf->size = 0; + } + retval = -ENOENT; + } +#endif /* CONFIG_FIRMWARE_SIG */ out: mutex_unlock(&fw_lock); return retval; -- 1.6.4.2 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 2:30 ` Ming Lei 2012-11-06 5:46 ` lee joey @ 2012-11-06 7:03 ` Takashi Iwai 2012-11-06 7:16 ` Ming Lei [not found] ` <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com> 2 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 7:03 UTC (permalink / raw) To: Ming Lei Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 10:30:26 +0800, Ming Lei wrote: > > On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai <tiwai@suse.de> wrote: > > > > To be noted, it doesn't support the firmwares via udev but only the > > direct loading, and the check for built-in firmware is missing, too. > > Generally, both direct loading and udev may request one same firmware > image. And after check failed, current firmware load will fallback on udev > to complete loading, so looks a check-failed firmware still can be loaded > into kernel no matter if there is firmware signature check or not. Yeah, it's just uncovered in the patch. As a easy solution, apply the patch like below to disallow the udev fw loading when signature check is enforced. thanks, Takashi --- diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 575bc4c..93121c3 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, goto handle_fw; } + /* signature check isn't handled via udev fw loading */ + if (sig_enforce) { + fw_load_abort(fw_priv); + direct_load = 1; + goto handle_fw; + } + /* fall back on userspace loading */ buf->fmt = PAGE_BUF; ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 7:03 ` Takashi Iwai @ 2012-11-06 7:16 ` Ming Lei 2012-11-06 7:32 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Ming Lei @ 2012-11-06 7:16 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai <tiwai@suse.de> wrote: > > Yeah, it's just uncovered in the patch. As a easy solution, apply the > patch like below to disallow the udev fw loading when signature check > is enforced. > > > thanks, > > Takashi > > --- > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index 575bc4c..93121c3 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, > goto handle_fw; > } > > + /* signature check isn't handled via udev fw loading */ > + if (sig_enforce) { > + fw_load_abort(fw_priv); > + direct_load = 1; > + goto handle_fw; > + } > + The above might be wrong if the firmware file doesn't exist in default search paths. You should skip loading from user space only if verify_signature() returns false. And the udev loading should be resorted to if there is no such firmware file in default search paths. > /* fall back on userspace loading */ > buf->fmt = PAGE_BUF; > Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 7:16 ` Ming Lei @ 2012-11-06 7:32 ` Takashi Iwai 2012-11-06 8:04 ` Ming Lei 0 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 7:32 UTC (permalink / raw) To: Ming Lei Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 15:16:43 +0800, Ming Lei wrote: > > On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai <tiwai@suse.de> wrote: > > > > Yeah, it's just uncovered in the patch. As a easy solution, apply the > > patch like below to disallow the udev fw loading when signature check > > is enforced. > > > > > > thanks, > > > > Takashi > > > > --- > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > > index 575bc4c..93121c3 100644 > > --- a/drivers/base/firmware_class.c > > +++ b/drivers/base/firmware_class.c > > @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, > > goto handle_fw; > > } > > > > + /* signature check isn't handled via udev fw loading */ > > + if (sig_enforce) { > > + fw_load_abort(fw_priv); > > + direct_load = 1; > > + goto handle_fw; > > + } > > + > > The above might be wrong if the firmware file doesn't exist in default > search paths. Heh, I didn't call it's a perfect patch. It's just an easy solution, as mentioned. > You should skip loading from user space only if > verify_signature() returns false. And the udev loading should be > resorted to if there is no such firmware file in default search paths. ... and the kernel should ask udev again for the corresponding signature. I'm too lazy to implement that just for unknown corner cases, so put the patch like above. Honestly speaking, I have a feeling that we should rather go for getting rid of udev fw loading. The fw loader code is overly complex just for udev handshaking. Do you know how many firmwares still rely on udev...? thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 7:32 ` Takashi Iwai @ 2012-11-06 8:04 ` Ming Lei 2012-11-06 8:18 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Ming Lei @ 2012-11-06 8:04 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 3:32 PM, Takashi Iwai <tiwai@suse.de> wrote: > At Tue, 6 Nov 2012 15:16:43 +0800, > Ming Lei wrote: >> >> On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai <tiwai@suse.de> wrote: >> > >> > Yeah, it's just uncovered in the patch. As a easy solution, apply the >> > patch like below to disallow the udev fw loading when signature check >> > is enforced. >> > >> > >> > thanks, >> > >> > Takashi >> > >> > --- >> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c >> > index 575bc4c..93121c3 100644 >> > --- a/drivers/base/firmware_class.c >> > +++ b/drivers/base/firmware_class.c >> > @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, >> > goto handle_fw; >> > } >> > >> > + /* signature check isn't handled via udev fw loading */ >> > + if (sig_enforce) { >> > + fw_load_abort(fw_priv); >> > + direct_load = 1; >> > + goto handle_fw; >> > + } >> > + >> >> The above might be wrong if the firmware file doesn't exist in default >> search paths. > > Heh, I didn't call it's a perfect patch. It's just an easy solution, > as mentioned. > >> You should skip loading from user space only if >> verify_signature() returns false. And the udev loading should be >> resorted to if there is no such firmware file in default search paths. > > ... and the kernel should ask udev again for the corresponding > signature. I mean you can't skip user space loading if there is no firmware file in the default search path. And you can do it if verify_signature() returns false. So you needn't have to implement the signature for user space loading. > I'm too lazy to implement that just for unknown corner > cases, so put the patch like above. There might be some distributions in which the firmwares aren't stored under the default search path, so your change may cause regression on these distributions. And, it is a easy change in your patch to make the situation working. Also the default search path in firmware_class.c is from built-in path of udev, and distributions may customize their firmware path by udev configure option. > > Honestly speaking, I have a feeling that we should rather go for > getting rid of udev fw loading. The fw loader code is overly complex Yes, I have the feeling too, but we need to make sure no regressions introduced. > just for udev handshaking. > > Do you know how many firmwares still rely on udev...? Do you know how many distributions have switched to 3.7-rcX to start using direct loading? Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 8:04 ` Ming Lei @ 2012-11-06 8:18 ` Takashi Iwai 2012-11-06 10:04 ` Ming Lei 0 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 8:18 UTC (permalink / raw) To: Ming Lei Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 16:04:50 +0800, Ming Lei wrote: > > On Tue, Nov 6, 2012 at 3:32 PM, Takashi Iwai <tiwai@suse.de> wrote: > > At Tue, 6 Nov 2012 15:16:43 +0800, > > Ming Lei wrote: > >> > >> On Tue, Nov 6, 2012 at 3:03 PM, Takashi Iwai <tiwai@suse.de> wrote: > >> > > >> > Yeah, it's just uncovered in the patch. As a easy solution, apply the > >> > patch like below to disallow the udev fw loading when signature check > >> > is enforced. > >> > > >> > > >> > thanks, > >> > > >> > Takashi > >> > > >> > --- > >> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > >> > index 575bc4c..93121c3 100644 > >> > --- a/drivers/base/firmware_class.c > >> > +++ b/drivers/base/firmware_class.c > >> > @@ -912,6 +912,13 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, > >> > goto handle_fw; > >> > } > >> > > >> > + /* signature check isn't handled via udev fw loading */ > >> > + if (sig_enforce) { > >> > + fw_load_abort(fw_priv); > >> > + direct_load = 1; > >> > + goto handle_fw; > >> > + } > >> > + > >> > >> The above might be wrong if the firmware file doesn't exist in default > >> search paths. > > > > Heh, I didn't call it's a perfect patch. It's just an easy solution, > > as mentioned. > > > >> You should skip loading from user space only if > >> verify_signature() returns false. And the udev loading should be > >> resorted to if there is no such firmware file in default search paths. > > > > ... and the kernel should ask udev again for the corresponding > > signature. > > I mean you can't skip user space loading if there is no firmware file > in the default search path. And you can do it if verify_signature() > returns false. So you needn't have to implement the signature for > user space loading. Right, and it's intentionally dropped so. For the non-default fw path, it can be added via proc dynamically or via kconfig statically. If the firmware is generated via udev, then it doesn't make sense to check a static signature file. > > I'm too lazy to implement that just for unknown corner > > cases, so put the patch like above. > > There might be some distributions in which the firmwares aren't stored > under the default search path, so your change may cause regression > on these distributions. And, it is a easy change in your patch to make > the situation working. A "regression" can't happen in this case because the secure boot is a completely new stuff :) For normal boot, sig_enforce is false, so no behavior change here (well my patch still applies the signature check for direct fw loading, but it won't regress at least). > Also the default search path in firmware_class.c is from built-in path of > udev, and distributions may customize their firmware path by udev > configure option. Well, the default paths in kernel can be changed to follow that as well, no? > > Honestly speaking, I have a feeling that we should rather go for > > getting rid of udev fw loading. The fw loader code is overly complex > > Yes, I have the feeling too, but we need to make sure no regressions > introduced. Right. And I guess the exceptional firmware case is better found by checking udev. But it's a bit off topic from secure boot. > > just for udev handshaking. > > > > Do you know how many firmwares still rely on udev...? > > Do you know how many distributions have switched to 3.7-rcX to > start using direct loading? Obviously no distro releases using 3.7-rc since it's still rc. But what's your point? Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 8:18 ` Takashi Iwai @ 2012-11-06 10:04 ` Ming Lei 2012-11-06 10:17 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Ming Lei @ 2012-11-06 10:04 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai <tiwai@suse.de> wrote: > > Right, and it's intentionally dropped so. For the non-default fw > path, it can be added via proc dynamically or via kconfig statically. > If the firmware is generated via udev, then it doesn't make sense to > check a static signature file. kconfig should be better, and proc isn't a good way because it is a bit late. Also the firmware might be loaded dynamically from other where(network, ...). So it is better to fall back on user space if the firmware file isn't found by direct loading even firmware signature is enabled. > A "regression" can't happen in this case because the secure boot is > a completely new stuff :) For normal boot, sig_enforce is false, so > no behavior change here (well my patch still applies the signature > check for direct fw loading, but it won't regress at least). Got it, so FIRMWARE_SIG and MODULE_SIG should be enabled only for secure boot. The regression might still be triggered if falling back on user space is not supported, see above. > >> Also the default search path in firmware_class.c is from built-in path of >> udev, and distributions may customize their firmware path by udev >> configure option. > > Well, the default paths in kernel can be changed to follow that as > well, no? > >> > Honestly speaking, I have a feeling that we should rather go for >> > getting rid of udev fw loading. The fw loader code is overly complex >> >> Yes, I have the feeling too, but we need to make sure no regressions >> introduced. > > Right. And I guess the exceptional firmware case is better found by > checking udev. But it's a bit off topic from secure boot. Not sure, some distributions may not use udev at all. Some application might need the firmware add/remove event. Some may not store the firmware in fs. So now it is difficult to say we can remove firmware loading from user space. Better to just keep it. > Obviously no distro releases using 3.7-rc since it's still rc. > But what's your point? I mean direct loading hasn't been tested completely, so we don't know which distributions may fallback on user space loading. Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 10:04 ` Ming Lei @ 2012-11-06 10:17 ` Takashi Iwai 2012-11-06 10:40 ` Ming Lei 0 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 10:17 UTC (permalink / raw) To: Ming Lei Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 18:04:36 +0800, Ming Lei wrote: > > On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai <tiwai@suse.de> wrote: > > > > Right, and it's intentionally dropped so. For the non-default fw > > path, it can be added via proc dynamically or via kconfig statically. > > If the firmware is generated via udev, then it doesn't make sense to > > check a static signature file. > > kconfig should be better, and proc isn't a good way because it > is a bit late. Also the firmware might be loaded dynamically from other > where(network, ...). So it is better to fall back on user space if the > firmware file isn't found by direct loading even firmware signature > is enabled. It will even with my patch, when enforce_sig is false. > > A "regression" can't happen in this case because the secure boot is > > a completely new stuff :) For normal boot, sig_enforce is false, so > > no behavior change here (well my patch still applies the signature > > check for direct fw loading, but it won't regress at least). > > Got it, so FIRMWARE_SIG and MODULE_SIG should be enabled only > for secure boot. The kernels with these kconfigs set can run on normal systems. In non-secure boot mode, however, sig_enable option are off, thus the fallback is still applied. > The regression might still be triggered if falling back on user space is not > supported, see above. > > > > >> Also the default search path in firmware_class.c is from built-in path of > >> udev, and distributions may customize their firmware path by udev > >> configure option. > > > > Well, the default paths in kernel can be changed to follow that as > > well, no? > > > >> > Honestly speaking, I have a feeling that we should rather go for > >> > getting rid of udev fw loading. The fw loader code is overly complex > >> > >> Yes, I have the feeling too, but we need to make sure no regressions > >> introduced. > > > > Right. And I guess the exceptional firmware case is better found by > > checking udev. But it's a bit off topic from secure boot. > > Not sure, some distributions may not use udev at all. Hmm, I can't imagine a system without udev but still supporting the firmware loading with user-space interaction... > Some application > might need the firmware add/remove event. Then this is already broken with the direct fw loading on 3.7, no? > Some may not store the > firmware in fs. And these won't satisfy the firmware signing, so we don't need to care too much. > So now it is difficult to say we can remove firmware loading from user > space. Better to just keep it. Yeah, I don't mean to drop it now. But I meant to go for dropping it. For example, put a deprecated flag and give a warning for udev fw loading path so that user notices something to be fixed. > > Obviously no distro releases using 3.7-rc since it's still rc. > > But what's your point? > > I mean direct loading hasn't been tested completely, so we don't > know which distributions may fallback on user space loading. The transition to direct fw loading is seamless, so I don't think you can see which drivers use udev fw loading from the results of distros... It might reveal some potential issues of direct fw loading (like udev-trigger dependency), though. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 10:17 ` Takashi Iwai @ 2012-11-06 10:40 ` Ming Lei 2012-11-06 10:53 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: Ming Lei @ 2012-11-06 10:40 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 6:17 PM, Takashi Iwai <tiwai@suse.de> wrote: > At Tue, 6 Nov 2012 18:04:36 +0800, > Ming Lei wrote: >> >> On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai <tiwai@suse.de> wrote: >> > >> > Right, and it's intentionally dropped so. For the non-default fw >> > path, it can be added via proc dynamically or via kconfig statically. >> > If the firmware is generated via udev, then it doesn't make sense to >> > check a static signature file. >> >> kconfig should be better, and proc isn't a good way because it >> is a bit late. Also the firmware might be loaded dynamically from other >> where(network, ...). So it is better to fall back on user space if the >> firmware file isn't found by direct loading even firmware signature >> is enabled. > > It will even with my patch, when enforce_sig is false. It is true if all firmwares are signed on safe boot. If firmware is allowed to be loaded from network or other non-fs place in secure distribution, your patch will break this loading. > >> > A "regression" can't happen in this case because the secure boot is >> > a completely new stuff :) For normal boot, sig_enforce is false, so >> > no behavior change here (well my patch still applies the signature >> > check for direct fw loading, but it won't regress at least). >> >> Got it, so FIRMWARE_SIG and MODULE_SIG should be enabled only >> for secure boot. > > The kernels with these kconfigs set can run on normal systems. In > non-secure boot mode, however, sig_enable option are off, thus the > fallback is still applied. > >> The regression might still be triggered if falling back on user space is not >> supported, see above. >> >> > >> >> Also the default search path in firmware_class.c is from built-in path of >> >> udev, and distributions may customize their firmware path by udev >> >> configure option. >> > >> > Well, the default paths in kernel can be changed to follow that as >> > well, no? >> > >> >> > Honestly speaking, I have a feeling that we should rather go for >> >> > getting rid of udev fw loading. The fw loader code is overly complex >> >> >> >> Yes, I have the feeling too, but we need to make sure no regressions >> >> introduced. >> > >> > Right. And I guess the exceptional firmware case is better found by >> > checking udev. But it's a bit off topic from secure boot. >> >> Not sure, some distributions may not use udev at all. > > Hmm, I can't imagine a system without udev but still supporting the > firmware loading with user-space interaction... It is not so difficult, :-) Some embedded systems use mdev in busybox, and some can just parse the firmware event and run the below script: Documentation/firmware_class/hotplug-script on firmware ADD event. I remembered that android loading is very simple. > >> Some application >> might need the firmware add/remove event. > > Then this is already broken with the direct fw loading on 3.7, no? Maybe, the direct loading hasn't been tested widely, and depends on user space. >> Some may not store the >> firmware in fs. > > And these won't satisfy the firmware signing, so we don't need to care > too much. > >> So now it is difficult to say we can remove firmware loading from user >> space. Better to just keep it. > > Yeah, I don't mean to drop it now. But I meant to go for dropping > it. For example, put a deprecated flag and give a warning for udev fw > loading path so that user notices something to be fixed. Maybe we can do it until direct loading has been tested for some time. > >> > Obviously no distro releases using 3.7-rc since it's still rc. >> > But what's your point? >> >> I mean direct loading hasn't been tested completely, so we don't >> know which distributions may fallback on user space loading. > > The transition to direct fw loading is seamless, so I don't think > you can see which drivers use udev fw loading from the results of > distros... It might reveal some potential issues of direct fw loading > (like udev-trigger dependency), though. The clue can be found from debug message. Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 10:40 ` Ming Lei @ 2012-11-06 10:53 ` Takashi Iwai 2012-11-06 11:03 ` Ming Lei 2012-11-06 11:15 ` Alan Cox 0 siblings, 2 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 10:53 UTC (permalink / raw) To: Ming Lei Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 18:40:57 +0800, Ming Lei wrote: > > On Tue, Nov 6, 2012 at 6:17 PM, Takashi Iwai <tiwai@suse.de> wrote: > > At Tue, 6 Nov 2012 18:04:36 +0800, > > Ming Lei wrote: > >> > >> On Tue, Nov 6, 2012 at 4:18 PM, Takashi Iwai <tiwai@suse.de> wrote: > >> > > >> > Right, and it's intentionally dropped so. For the non-default fw > >> > path, it can be added via proc dynamically or via kconfig statically. > >> > If the firmware is generated via udev, then it doesn't make sense to > >> > check a static signature file. > >> > >> kconfig should be better, and proc isn't a good way because it > >> is a bit late. Also the firmware might be loaded dynamically from other > >> where(network, ...). So it is better to fall back on user space if the > >> firmware file isn't found by direct loading even firmware signature > >> is enabled. > > > > It will even with my patch, when enforce_sig is false. > > It is true if all firmwares are signed on safe boot. If firmware is allowed > to be loaded from network or other non-fs place in secure distribution, > your patch will break this loading. Do we already have such a secure mechanism? How is the security assured? > >> > A "regression" can't happen in this case because the secure boot is > >> > a completely new stuff :) For normal boot, sig_enforce is false, so > >> > no behavior change here (well my patch still applies the signature > >> > check for direct fw loading, but it won't regress at least). > >> > >> Got it, so FIRMWARE_SIG and MODULE_SIG should be enabled only > >> for secure boot. > > > > The kernels with these kconfigs set can run on normal systems. In > > non-secure boot mode, however, sig_enable option are off, thus the > > fallback is still applied. > > > >> The regression might still be triggered if falling back on user space is not > >> supported, see above. > >> > >> > > >> >> Also the default search path in firmware_class.c is from built-in path of > >> >> udev, and distributions may customize their firmware path by udev > >> >> configure option. > >> > > >> > Well, the default paths in kernel can be changed to follow that as > >> > well, no? > >> > > >> >> > Honestly speaking, I have a feeling that we should rather go for > >> >> > getting rid of udev fw loading. The fw loader code is overly complex > >> >> > >> >> Yes, I have the feeling too, but we need to make sure no regressions > >> >> introduced. > >> > > >> > Right. And I guess the exceptional firmware case is better found by > >> > checking udev. But it's a bit off topic from secure boot. > >> > >> Not sure, some distributions may not use udev at all. > > > > Hmm, I can't imagine a system without udev but still supporting the > > firmware loading with user-space interaction... > > It is not so difficult, :-) > > Some embedded systems use mdev in busybox, and some can > just parse the firmware event and run the below script: > > Documentation/firmware_class/hotplug-script > > on firmware ADD event. I remembered that android loading is > very simple. But I don't think Android devices will run on secure boot :) That is, the whole signing madness is just for allowing boot on upcoming machines that need the secure boot mode forced by Microsoft. And this doesn't match with systems you suggested in the above. > >> Some application > >> might need the firmware add/remove event. > > > > Then this is already broken with the direct fw loading on 3.7, no? > > Maybe, the direct loading hasn't been tested widely, and depends on > user space. > > >> Some may not store the > >> firmware in fs. > > > > And these won't satisfy the firmware signing, so we don't need to care > > too much. > > > >> So now it is difficult to say we can remove firmware loading from user > >> space. Better to just keep it. > > > > Yeah, I don't mean to drop it now. But I meant to go for dropping > > it. For example, put a deprecated flag and give a warning for udev fw > > loading path so that user notices something to be fixed. > > Maybe we can do it until direct loading has been tested for some time. Yeah, it's a future plan. But I'd say it's better clarified that we should go for that direction instead of keeping the stuff forever. > >> > Obviously no distro releases using 3.7-rc since it's still rc. > >> > But what's your point? > >> > >> I mean direct loading hasn't been tested completely, so we don't > >> know which distributions may fallback on user space loading. > > > > The transition to direct fw loading is seamless, so I don't think > > you can see which drivers use udev fw loading from the results of > > distros... It might reveal some potential issues of direct fw loading > > (like udev-trigger dependency), though. > > The clue can be found from debug message. Debug messages are turned off on normal machines, unfortunately. Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 10:53 ` Takashi Iwai @ 2012-11-06 11:03 ` Ming Lei 2012-11-06 11:15 ` Alan Cox 1 sibling, 0 replies; 224+ messages in thread From: Ming Lei @ 2012-11-06 11:03 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 6:53 PM, Takashi Iwai <tiwai@suse.de> wrote: > At Tue, 6 Nov 2012 18:40:57 +0800, >> It is true if all firmwares are signed on safe boot. If firmware is allowed >> to be loaded from network or other non-fs place in secure distribution, >> your patch will break this loading. > > Do we already have such a secure mechanism? How is the security > assured? I don't know, and my comments are just on your patch and the condition. I understand secure guys should know if the condition may be true or false, :-) >> The clue can be found from debug message. > > Debug messages are turned off on normal machines, unfortunately. Kernel guys will put one eye on bug report, also enabling udev log can help the problem too. Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 10:53 ` Takashi Iwai 2012-11-06 11:03 ` Ming Lei @ 2012-11-06 11:15 ` Alan Cox 1 sibling, 0 replies; 224+ messages in thread From: Alan Cox @ 2012-11-06 11:15 UTC (permalink / raw) To: Takashi Iwai Cc: Ming Lei, Matthew Garrett, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi > > It is true if all firmwares are signed on safe boot. If firmware is allowed > > to be loaded from network or other non-fs place in secure distribution, > > your patch will break this loading. Actually it's not. It should be true that firmware that can harm machine integrity and is loaded by the OS is signed at some level. However it is not true that - firmware that is no integrity threat (eg USB firmware) - firmware that can be flash updated on another PC and not observed by the target are necessarily in any way signed or secure. > Do we already have such a secure mechanism? How is the security > assured? Another thing to consider is that a lot of hardware (particularly anything aimed at such 'secure boot' machines) is already digitally signed. Whether you need to enforce external signing is a mix of driver specific questions ("does this device have signed firmware anyway", "can bogus firmware do anything interesting") and local policy "do I as admin want to block any firmware that isn't corporate site approved" For USB this is quite important because there is a ton of hardware out there which is intended to have firmware dumped into it for hacking and fun purposes and should generally be totally outside of the signing stuff. Alan ^ permalink raw reply [flat|nested] 224+ messages in thread
[parent not found: <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com>]
* Re: [PATCH RFC 0/4] Add firmware signature file check [not found] ` <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com> @ 2012-11-06 7:06 ` Takashi Iwai 2012-11-06 7:30 ` Ming Lei 1 sibling, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 7:06 UTC (permalink / raw) To: Li Joey Cc: Ming Lei, Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 6 Nov 2012 13:36:46 +0800, Li Joey wrote: > > [1 <text/plain; ISO-8859-1 (7bit)>] > 2012/11/6 Ming Lei <tom.leiming@gmail.com> > > > On Tue, Nov 6, 2012 at 1:18 AM, Takashi Iwai <tiwai@suse.de> wrote: > > > > > > To be noted, it doesn't support the firmwares via udev but only the > > > direct loading, and the check for built-in firmware is missing, too. > > > > Generally, both direct loading and udev may request one same firmware > > image. And after check failed, current firmware load will fallback on udev > > to complete loading, so looks a check-failed firmware still can be loaded > > into kernel no matter if there is firmware signature check or not. > > > > > > Thanks, > > -- > > Ming Lei > > > The udev direct write firmware through data attribute, maybe we can do the > same signature verification in firmware_data_write? The following patch > didn't test yet. This would work in theory. But in practice, when the direct file loading fails and falls back to udev, it means that the firmware is no file but generated somehow dynamically. If so, a static signature won't help, I'm afraid. thanks, Takashi > > > Thanks > Joey Lee > > >From 035dde5fadc9e7f4b7811b18d3a5094ef88e8bbb Mon Sep 17 00:00:00 2001 > From: Lee, Chun-Yi <jlee@suse.com> > Date: Tue, 6 Nov 2012 13:07:04 +0800 > Subject: [PATCH] firmware: Add signature check to firmware_data_write > > --- > drivers/base/firmware_class.c | 18 ++++++++++++++++++ > 1 files changed, 18 insertions(+), 0 deletions(-) > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index 8945f4e..40d8cc6 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -621,6 +621,7 @@ static ssize_t firmware_data_write(struct file *filp, > struct kobject *kobj, > struct firmware_priv *fw_priv = to_firmware_priv(dev); > struct firmware_buf *buf; > ssize_t retval; > + bool success = false; > > if (!capable(CAP_SYS_RAWIO)) > return -EPERM; > @@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file *filp, > struct kobject *kobj, > } > > buf->size = max_t(size_t, offset, buf->size); > + > +#ifdef CONFIG_FIRMWARE_SIG > + for (i = 0; i < ARRAY_SIZE(fw_path); i++) { > + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], > buf->fw_id); > + if (verify_signature(buf, path)) > + success = true; > + } > + if (!success) { > + pr_err("Invalid signature file %s\n", path); > + if (sig_enforce) { > + vfree(buf->data); > + buf->data = NULL; > + buf->size = 0; > + } > + retval = -ENOENT; > + } > +#endif /* CONFIG_FIRMWARE_SIG */ > out: > mutex_unlock(&fw_lock); > return retval; > -- > 1.6.4.2 > [2 <text/html; ISO-8859-1 (quoted-printable)>] > ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check [not found] ` <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com> 2012-11-06 7:06 ` Takashi Iwai @ 2012-11-06 7:30 ` Ming Lei 1 sibling, 0 replies; 224+ messages in thread From: Ming Lei @ 2012-11-06 7:30 UTC (permalink / raw) To: Li Joey Cc: Takashi Iwai, Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, linux-kernel, linux-security-module, linux-efi On Tue, Nov 6, 2012 at 1:36 PM, Li Joey <jlee@novell.com> wrote: > The udev direct write firmware through data attribute, maybe we can do the > same signature verification in firmware_data_write? The following patch > didn't test yet. > @@ -655,6 +656,23 @@ static ssize_t firmware_data_write(struct file *filp, > struct kobject *kobj, > } > > buf->size = max_t(size_t, offset, buf->size); > + > +#ifdef CONFIG_FIRMWARE_SIG > + for (i = 0; i < ARRAY_SIZE(fw_path); i++) { > + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], > buf->fw_id); > + if (verify_signature(buf, path)) > + success = true; > + } When direct loading failed, it means that the firmware isn't under the default search path, so the above verification might return false always. Thanks, -- Ming Lei ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC v2 0/4] Add firmware signature file check 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai ` (6 preceding siblings ...) 2012-11-06 2:30 ` Ming Lei @ 2012-11-08 17:35 ` Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file Takashi Iwai ` (3 more replies) 7 siblings, 4 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-08 17:35 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi Hi, this is the revised patches I sent in this week for adding the firmware signing support. No big changes in the code but a bit of clean ups and more descriptions in changelog and comments now. At this point, it still needs to have a proper Kconfig help text, and move the stuff of CONFIG_MODULE_SIG to be indepdent from CONFIG_MODULE so that the code required for signature checks can be built for the firmware loader even without module. But, before doing that, I'd like to hear whether this approach is really a way to go, or better to throw away and scratch. Any suggests / comments appreciated. thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai @ 2012-11-08 17:35 ` Takashi Iwai 2012-11-23 6:51 ` joeyli 2012-11-08 17:35 ` [PATCH RFC v2 2/4] firmware: Add -a option " Takashi Iwai ` (2 subsequent siblings) 3 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-08 17:35 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi, Takashi Iwai Add -f option to sign-file script for generating a firmware signature file. A firmware signature file contains a pretty similar structure like a signed module but in a different order (because it's a separate file while the module signature is embedded at the tail of unsigned module contents). The file consists of - the magic string - the signature information, which is identical with the module signature - signer's name - key id - signature bytes Signed-off-by: Takashi Iwai <tiwai@suse.de> --- scripts/sign-file | 48 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 35 insertions(+), 13 deletions(-) diff --git a/scripts/sign-file b/scripts/sign-file index 87ca59d..5b9d44d 100755 --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,30 +4,40 @@ # # Format: # -# ./scripts/sign-file [-v] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] # # use strict; use FileHandle; use IPC::Open2; +use Getopt::Long; -my $verbose = 0; -if ($#ARGV >= 0 && $ARGV[0] eq "-v") { - $verbose = 1; - shift; +sub usage() +{ + print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] + -v verbose output + -f create a firmware signature file +"; + exit; } -die "Format: ./scripts/sign-file [-v] <key> <x509> <module> [<dest>]\n" - if ($#ARGV != 2 && $#ARGV != 3); +my $verbose = 0; +my $sign_fw = 0; + +GetOptions( + 'v|verbose' => \$verbose, + 'f|firmware' => \$sign_fw) || usage(); +usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; my $x509 = $ARGV[1]; my $module = $ARGV[2]; -my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~"; +my $dest = $ARGV[3] ? $ARGV[3] : $ARGV[2] . ($sign_fw ? ".sig" : "~"); +my $mode_name = $sign_fw ? "firmware" : "module"; die "Can't read private key\n" unless (-r $private_key); die "Can't read X.509 certificate\n" unless (-r $x509); -die "Can't read module\n" unless (-r $module); +die "Can't read $mode_name\n" unless (-r $module); # # Read the kernel configuration @@ -393,7 +403,9 @@ die "openssl rsautl died: $?" if ($? >> 8); # my $unsigned_module = read_file($module); -my $magic_number = "~Module signature appended~\n"; +my $magic_number = $sign_fw ? + "~Linux firmware signature~\n" : + "~Module signature appended~\n"; my $info = pack("CCCCCxxxN", $algo, $hash, $id_type, @@ -402,7 +414,7 @@ my $info = pack("CCCCCxxxN", length($signature)); if ($verbose) { - print "Size of unsigned module: ", length($unsigned_module), "\n"; + print "Size of unsigned $mode_name: ", length($unsigned_module), "\n"; print "Size of signer's name : ", length($signers_name), "\n"; print "Size of key identifier : ", length($key_identifier), "\n"; print "Size of signature : ", length($signature), "\n"; @@ -414,7 +426,16 @@ if ($verbose) { open(FD, ">$dest") || die $dest; binmode FD; -print FD +if ($sign_fw) { + print FD + $magic_number, + $info, + $signers_name, + $key_identifier, + $signature + ; +} else { + print FD $unsigned_module, $signers_name, $key_identifier, @@ -422,8 +443,9 @@ print FD $info, $magic_number ; +} close FD || die $dest; -if ($#ARGV != 3) { +if (!$sign_fw && $#ARGV != 3) { rename($dest, $module) || die $module; } -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file 2012-11-08 17:35 ` [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file Takashi Iwai @ 2012-11-23 6:51 ` joeyli 0 siblings, 0 replies; 224+ messages in thread From: joeyli @ 2012-11-23 6:51 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi 於 四,2012-11-08 於 18:35 +0100,Takashi Iwai 提到: > Add -f option to sign-file script for generating a firmware signature > file. > > A firmware signature file contains a pretty similar structure like a > signed module but in a different order (because it's a separate file > while the module signature is embedded at the tail of unsigned module > contents). The file consists of > - the magic string > - the signature information, which is identical with the module > signature > - signer's name > - key id > - signature bytes > > Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Chun-Yi Lee <jlee@suse.com> Joey Lee > --- > scripts/sign-file | 48 +++++++++++++++++++++++++++++++++++------------- > 1 file changed, 35 insertions(+), 13 deletions(-) > > diff --git a/scripts/sign-file b/scripts/sign-file > index 87ca59d..5b9d44d 100755 > --- a/scripts/sign-file > +++ b/scripts/sign-file > @@ -4,30 +4,40 @@ > # > # Format: > # > -# ./scripts/sign-file [-v] <key> <x509> <module> [<dest>] > +# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] > # > # > use strict; > use FileHandle; > use IPC::Open2; > +use Getopt::Long; > > -my $verbose = 0; > -if ($#ARGV >= 0 && $ARGV[0] eq "-v") { > - $verbose = 1; > - shift; > +sub usage() > +{ > + print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] > + -v verbose output > + -f create a firmware signature file > +"; > + exit; > } > > -die "Format: ./scripts/sign-file [-v] <key> <x509> <module> [<dest>]\n" > - if ($#ARGV != 2 && $#ARGV != 3); > +my $verbose = 0; > +my $sign_fw = 0; > + > +GetOptions( > + 'v|verbose' => \$verbose, > + 'f|firmware' => \$sign_fw) || usage(); > +usage() if ($#ARGV != 2 && $#ARGV != 3); > > my $private_key = $ARGV[0]; > my $x509 = $ARGV[1]; > my $module = $ARGV[2]; > -my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~"; > +my $dest = $ARGV[3] ? $ARGV[3] : $ARGV[2] . ($sign_fw ? ".sig" : "~"); > +my $mode_name = $sign_fw ? "firmware" : "module"; > > die "Can't read private key\n" unless (-r $private_key); > die "Can't read X.509 certificate\n" unless (-r $x509); > -die "Can't read module\n" unless (-r $module); > +die "Can't read $mode_name\n" unless (-r $module); > > # > # Read the kernel configuration > @@ -393,7 +403,9 @@ die "openssl rsautl died: $?" if ($? >> 8); > # > my $unsigned_module = read_file($module); > > -my $magic_number = "~Module signature appended~\n"; > +my $magic_number = $sign_fw ? > + "~Linux firmware signature~\n" : > + "~Module signature appended~\n"; > > my $info = pack("CCCCCxxxN", > $algo, $hash, $id_type, > @@ -402,7 +414,7 @@ my $info = pack("CCCCCxxxN", > length($signature)); > > if ($verbose) { > - print "Size of unsigned module: ", length($unsigned_module), "\n"; > + print "Size of unsigned $mode_name: ", length($unsigned_module), "\n"; > print "Size of signer's name : ", length($signers_name), "\n"; > print "Size of key identifier : ", length($key_identifier), "\n"; > print "Size of signature : ", length($signature), "\n"; > @@ -414,7 +426,16 @@ if ($verbose) { > > open(FD, ">$dest") || die $dest; > binmode FD; > -print FD > +if ($sign_fw) { > + print FD > + $magic_number, > + $info, > + $signers_name, > + $key_identifier, > + $signature > + ; > +} else { > + print FD > $unsigned_module, > $signers_name, > $key_identifier, > @@ -422,8 +443,9 @@ print FD > $info, > $magic_number > ; > +} > close FD || die $dest; > > -if ($#ARGV != 3) { > +if (!$sign_fw && $#ARGV != 3) { > rename($dest, $module) || die $module; > } ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC v2 2/4] firmware: Add -a option to scripts/sign-file 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file Takashi Iwai @ 2012-11-08 17:35 ` Takashi Iwai 2012-11-23 6:51 ` joeyli 2012-11-08 17:35 ` [PATCH RFC v2 3/4] firmware: Add support for signature checks Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically Takashi Iwai 3 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-08 17:35 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi, Takashi Iwai Add a new option -a to sign-file for specifying the hash algorithm to sign a file, to make it working without .config file. This will be useful signing external module or firmware files. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- scripts/sign-file | 40 ++++++++++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 12 deletions(-) diff --git a/scripts/sign-file b/scripts/sign-file index 5b9d44d..581cdcd 100755 --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,7 +4,7 @@ # # Format: # -# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-f] [-a algo] <key> <x509> <module> [<dest>] # # use strict; @@ -17,16 +17,19 @@ sub usage() print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] -v verbose output -f create a firmware signature file + -a algo specify hash algorithm "; exit; } my $verbose = 0; +my $hashalgo = ""; my $sign_fw = 0; GetOptions( 'v|verbose' => \$verbose, - 'f|firmware' => \$sign_fw) || usage(); + 'f|firmware' => \$sign_fw, + 'a|algo=s' => \$hashalgo) || usage(); usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; @@ -42,10 +45,7 @@ die "Can't read $mode_name\n" unless (-r $module); # # Read the kernel configuration # -my %config = ( - CONFIG_MODULE_SIG_SHA512 => 1 - ); - +my %config; if (-r ".config") { open(FD, "<.config") || die ".config"; while (<FD>) { @@ -56,6 +56,22 @@ if (-r ".config") { close(FD); } +if ($hashalgo eq "") { + if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { + $hashalgo="sha1"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { + $hashalgo="sha224"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { + $hashalgo="sha256"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { + $hashalgo="sha384"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { + $hashalgo="sha512"; + } else { + die "Can't determine hash algorithm"; + } +} + # # Function to read the contents of a file into a variable. # @@ -332,35 +348,35 @@ my $id_type = 1; # Identifier type: X.509 # Digest the data # my ($dgst, $prologue) = (); -if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { +if ($hashalgo eq "sha1") { $prologue = pack("C*", 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14); $dgst = "-sha1"; $hash = 2; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { +} elsif ($hashalgo eq "sha224") { $prologue = pack("C*", 0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C); $dgst = "-sha224"; $hash = 7; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { +} elsif ($hashalgo eq "sha256") { $prologue = pack("C*", 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20); $dgst = "-sha256"; $hash = 4; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { +} elsif ($hashalgo eq "sha384") { $prologue = pack("C*", 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30); $dgst = "-sha384"; $hash = 5; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { +} elsif ($hashalgo eq "sha512") { $prologue = pack("C*", 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, @@ -368,7 +384,7 @@ if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { $dgst = "-sha512"; $hash = 6; } else { - die "Can't determine hash algorithm"; + die "Invalid hash algorithm $hashalgo"; } # -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC v2 2/4] firmware: Add -a option to scripts/sign-file 2012-11-08 17:35 ` [PATCH RFC v2 2/4] firmware: Add -a option " Takashi Iwai @ 2012-11-23 6:51 ` joeyli 0 siblings, 0 replies; 224+ messages in thread From: joeyli @ 2012-11-23 6:51 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi 於 四,2012-11-08 於 18:35 +0100,Takashi Iwai 提到: > Add a new option -a to sign-file for specifying the hash algorithm > to sign a file, to make it working without .config file. > This will be useful signing external module or firmware files. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Chun-Yi Lee<jlee@suse.com> Joey Lee > --- > scripts/sign-file | 40 ++++++++++++++++++++++++++++------------ > 1 file changed, 28 insertions(+), 12 deletions(-) > > diff --git a/scripts/sign-file b/scripts/sign-file > index 5b9d44d..581cdcd 100755 > --- a/scripts/sign-file > +++ b/scripts/sign-file > @@ -4,7 +4,7 @@ > # > # Format: > # > -# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] > +# ./scripts/sign-file [-v] [-f] [-a algo] <key> <x509> <module> [<dest>] > # > # > use strict; > @@ -17,16 +17,19 @@ sub usage() > print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] > -v verbose output > -f create a firmware signature file > + -a algo specify hash algorithm > "; > exit; > } > > my $verbose = 0; > +my $hashalgo = ""; > my $sign_fw = 0; > > GetOptions( > 'v|verbose' => \$verbose, > - 'f|firmware' => \$sign_fw) || usage(); > + 'f|firmware' => \$sign_fw, > + 'a|algo=s' => \$hashalgo) || usage(); > usage() if ($#ARGV != 2 && $#ARGV != 3); > > my $private_key = $ARGV[0]; > @@ -42,10 +45,7 @@ die "Can't read $mode_name\n" unless (-r $module); > # > # Read the kernel configuration > # > -my %config = ( > - CONFIG_MODULE_SIG_SHA512 => 1 > - ); > - > +my %config; > if (-r ".config") { > open(FD, "<.config") || die ".config"; > while (<FD>) { > @@ -56,6 +56,22 @@ if (-r ".config") { > close(FD); > } > > +if ($hashalgo eq "") { > + if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { > + $hashalgo="sha1"; > + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { > + $hashalgo="sha224"; > + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { > + $hashalgo="sha256"; > + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { > + $hashalgo="sha384"; > + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { > + $hashalgo="sha512"; > + } else { > + die "Can't determine hash algorithm"; > + } > +} > + > # > # Function to read the contents of a file into a variable. > # > @@ -332,35 +348,35 @@ my $id_type = 1; # Identifier type: X.509 > # Digest the data > # > my ($dgst, $prologue) = (); > -if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { > +if ($hashalgo eq "sha1") { > $prologue = pack("C*", > 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, > 0x2B, 0x0E, 0x03, 0x02, 0x1A, > 0x05, 0x00, 0x04, 0x14); > $dgst = "-sha1"; > $hash = 2; > -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { > +} elsif ($hashalgo eq "sha224") { > $prologue = pack("C*", > 0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, > 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, > 0x05, 0x00, 0x04, 0x1C); > $dgst = "-sha224"; > $hash = 7; > -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { > +} elsif ($hashalgo eq "sha256") { > $prologue = pack("C*", > 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, > 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, > 0x05, 0x00, 0x04, 0x20); > $dgst = "-sha256"; > $hash = 4; > -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { > +} elsif ($hashalgo eq "sha384") { > $prologue = pack("C*", > 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, > 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, > 0x05, 0x00, 0x04, 0x30); > $dgst = "-sha384"; > $hash = 5; > -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { > +} elsif ($hashalgo eq "sha512") { > $prologue = pack("C*", > 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, > 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, > @@ -368,7 +384,7 @@ if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { > $dgst = "-sha512"; > $hash = 6; > } else { > - die "Can't determine hash algorithm"; > + die "Invalid hash algorithm $hashalgo"; > } > > # ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC v2 3/4] firmware: Add support for signature checks 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 2/4] firmware: Add -a option " Takashi Iwai @ 2012-11-08 17:35 ` Takashi Iwai 2012-11-23 6:56 ` joeyli 2012-11-08 17:35 ` [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically Takashi Iwai 3 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-08 17:35 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi, Takashi Iwai Add a feature to check the firmware signature, specified via Kconfig CONFIG_FIRMWARE_SIG. The signature check is performed only for the direct fw loading without udev. If sig_enforce is set but no firmware file is found in fs, request_firmware*() returns an error for now. It would be possible to improve this situation, e.g. by adding an extra request of signature via yet another uevent, but I'm too lazy to implement it and also skeptical whether it's needed. On a kernel with CONFIG_FIRMWARE_SIG=y and sig_enforce=1 set, when no firmware signature is present or the signature doesn't match, the kernel rejects such a firmware and proceeds to the next possible one. With sig_enforce=0, a firmware is loaded even if no signature is found or the signature doesn't match, but it taints the kernel with TAINT_USER. This behavior is similar like the signed module loading. Last to be noted, in this version, the firmware signature support depends on CONFIG_MODULE_SIG, that is, the system requires the module support for now. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/base/Kconfig | 6 ++++ drivers/base/firmware_class.c | 78 +++++++++++++++++++++++++++++++++++++++---- include/linux/firmware.h | 7 ++++ kernel/module_signing.c | 63 ++++++++++++++++++++++++++++++++++ 4 files changed, 147 insertions(+), 7 deletions(-) diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index b34b5cd..3696fd7 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR this option you can point it elsewhere, such as /lib/firmware/ or some other directory containing the firmware files. +config FIRMWARE_SIG + bool "Firmware signature verification" + depends on FW_LOADER && MODULE_SIG + help + Enable firmware signature check. + config DEBUG_DRIVER bool "Driver Core verbose debug messages" depends on DEBUG_KERNEL diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 8945f4e..501cff4 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -36,6 +36,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz"); MODULE_DESCRIPTION("Multi purpose firmware loading support"); MODULE_LICENSE("GPL"); +#ifdef CONFIG_FIRMWARE_SIG +static bool sig_enforce; +module_param(sig_enforce, bool, 0644); +#endif + /* Builtin firmware support */ #ifdef CONFIG_FW_LOADER @@ -287,7 +292,7 @@ static noinline long fw_file_size(struct file *file) return st.size; } -static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf) +static bool fw_read_file_contents(struct file *file, void **bufp, size_t *sizep) { long size; char *buf; @@ -302,14 +307,42 @@ static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf vfree(buf); return false; } - fw_buf->data = buf; - fw_buf->size = size; + *bufp = buf; + *sizep = size; return true; } +#ifdef CONFIG_FIRMWARE_SIG +static int verify_sig_file(struct firmware_buf *buf, const char *path) +{ + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - 1; + struct file *file; + void *sig_data; + size_t sig_size; + int ret; + + file = filp_open(path, O_RDONLY, 0); + if (IS_ERR(file)) + return -ENOKEY; + + ret = fw_read_file_contents(file, &sig_data, &sig_size); + fput(file); + if (!ret) + return -ENOKEY; + if (sig_size <= markerlen || + memcmp(sig_data, FIRMWARE_SIG_STRING, markerlen)) + return -EBADMSG; + ret = fw_verify_sig(buf->data, buf->size, + sig_data + markerlen, sig_size - markerlen); + pr_debug("verified signature %s: %d\n", path, ret); + vfree(sig_data); + return ret; +} +#endif /* CONFIG_FIRMWARE_SIG */ + static bool fw_get_filesystem_firmware(struct firmware_buf *buf) { - int i; + int i, ret; bool success = false; char *path = __getname(); @@ -320,10 +353,30 @@ static bool fw_get_filesystem_firmware(struct firmware_buf *buf) file = filp_open(path, O_RDONLY, 0); if (IS_ERR(file)) continue; - success = fw_read_file_contents(file, buf); + success = fw_read_file_contents(file, &buf->data, &buf->size); fput(file); - if (success) - break; + if (!success) + continue; +#ifdef CONFIG_FIRMWARE_SIG + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], buf->fw_id); + ret = verify_sig_file(buf, path); + if (ret < 0) { + if (ret == -ENOENT) + pr_err("Cannot find firmware signature %s\n", + path); + else + pr_err("Invalid firmware signature %s\n", path); + if (sig_enforce) { + vfree(buf->data); + buf->data = NULL; + buf->size = 0; + success = false; + continue; + } + add_taint(TAINT_USER); + } +#endif /* CONFIG_FIRMWARE_SIG */ + break; } __putname(path); return success; @@ -864,6 +917,17 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent, goto handle_fw; } +#ifdef CONFIG_FIRMWARE_SIG + /* FIXME: we don't handle signature check for fw loaded via udev */ + if (sig_enforce) { + pr_err("Cannot find firmware file %s; aborting fw loading\n", + buf->fw_id); + fw_load_abort(fw_priv); + direct_load = 1; + goto handle_fw; + } +#endif + /* fall back on userspace loading */ buf->fmt = PAGE_BUF; diff --git a/include/linux/firmware.h b/include/linux/firmware.h index e4279fe..2e9e457 100644 --- a/include/linux/firmware.h +++ b/include/linux/firmware.h @@ -79,4 +79,11 @@ static inline int uncache_firmware(const char *name) } #endif +#ifdef CONFIG_FIRMWARE_SIG +#define FIRMWARE_SIG_STRING "~Linux firmware signature~\n" +/* defined in kernel/module_signing.c */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size); +#endif + #endif diff --git a/kernel/module_signing.c b/kernel/module_signing.c index ea1b1df..7994452 100644 --- a/kernel/module_signing.c +++ b/kernel/module_signing.c @@ -11,6 +11,7 @@ #include <linux/kernel.h> #include <linux/err.h> +#include <linux/export.h> #include <crypto/public_key.h> #include <crypto/hash.h> #include <keys/asymmetric-type.h> @@ -247,3 +248,65 @@ error_put_key: pr_devel("<==%s() = %d\n", __func__, ret); return ret; } + +#ifdef CONFIG_FIRMWARE_SIG +/* + * Verify the firmware signature, similar like module signature check + * but it's stored in a separate file + */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size) +{ + struct public_key_signature *pks; + struct module_signature ms; + struct key *key; + size_t sig_len; + int ret; + + if (sig_size <= sizeof(ms)) + return -EBADMSG; + + memcpy(&ms, sig_data, sizeof(ms)); + sig_data += sizeof(ms); + sig_size -= sizeof(ms); + + sig_len = be32_to_cpu(ms.sig_len); + if (sig_size < sig_len + (size_t)ms.signer_len + ms.key_id_len) + return -EBADMSG; + + /* For the moment, only support RSA and X.509 identifiers */ + if (ms.algo != PKEY_ALGO_RSA || + ms.id_type != PKEY_ID_X509) + return -ENOPKG; + + if (ms.hash >= PKEY_HASH__LAST || + !pkey_hash_algo[ms.hash]) + return -ENOPKG; + + key = request_asymmetric_key(sig_data, ms.signer_len, + sig_data + ms.signer_len, ms.key_id_len); + if (IS_ERR(key)) + return PTR_ERR(key); + + pks = mod_make_digest(ms.hash, fw_data, fw_size); + if (IS_ERR(pks)) { + ret = PTR_ERR(pks); + goto error_put_key; + } + + sig_data += ms.signer_len + ms.key_id_len; + ret = mod_extract_mpi_array(pks, sig_data, sig_len); + if (ret < 0) + goto error_free_pks; + + ret = verify_signature(key, pks); + +error_free_pks: + mpi_free(pks->rsa.s); + kfree(pks); +error_put_key: + key_put(key); + return ret; +} +EXPORT_SYMBOL_GPL(fw_verify_sig); +#endif /* CONFIG_FIRMWARE_SIG */ -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC v2 3/4] firmware: Add support for signature checks 2012-11-08 17:35 ` [PATCH RFC v2 3/4] firmware: Add support for signature checks Takashi Iwai @ 2012-11-23 6:56 ` joeyli 2012-11-23 7:34 ` Takashi Iwai 0 siblings, 1 reply; 224+ messages in thread From: joeyli @ 2012-11-23 6:56 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi 於 四,2012-11-08 於 18:35 +0100,Takashi Iwai 提到: > +#ifdef CONFIG_FIRMWARE_SIG > +static int verify_sig_file(struct firmware_buf *buf, const char > *path) > +{ > + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - > 1; > + struct file *file; > + void *sig_data; > + size_t sig_size; > + int ret; > + > + file = filp_open(path, O_RDONLY, 0); > + if (IS_ERR(file)) > + return -ENOKEY; I think there should return '-ENOENT', otherwise the firmware will show 'Invalid firmware signature' even didn't find the sig file. > + > + ret = fw_read_file_contents(file, &sig_data, &sig_size); > + fput(file); Tested-by: Chun-Yi Lee <jlee@suse.com> Thanks a lot! Joey Lee ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC v2 3/4] firmware: Add support for signature checks 2012-11-23 6:56 ` joeyli @ 2012-11-23 7:34 ` Takashi Iwai 0 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-23 7:34 UTC (permalink / raw) To: joeyli Cc: Matthew Garrett, Alan Cox, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi At Fri, 23 Nov 2012 14:56:11 +0800, joeyli wrote: > > 於 四,2012-11-08 於 18:35 +0100,Takashi Iwai 提到: > > +#ifdef CONFIG_FIRMWARE_SIG > > +static int verify_sig_file(struct firmware_buf *buf, const char > > *path) > > +{ > > + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - > > 1; > > + struct file *file; > > + void *sig_data; > > + size_t sig_size; > > + int ret; > > + > > + file = filp_open(path, O_RDONLY, 0); > > + if (IS_ERR(file)) > > + return -ENOKEY; > > I think there should return '-ENOENT', otherwise the firmware will show > 'Invalid firmware signature' even didn't find the sig file. Actually this is the intentional behavior. In the secure boot mode, unsigned firmware should be rejected. In the normal boot mode, the -ENOKEY error is ignored. (Whether we should taint the kernel with such an unsigned firmware is a bit different question, though.) thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai ` (2 preceding siblings ...) 2012-11-08 17:35 ` [PATCH RFC v2 3/4] firmware: Add support for signature checks Takashi Iwai @ 2012-11-08 17:35 ` Takashi Iwai 2012-11-23 6:52 ` joeyli 3 siblings, 1 reply; 224+ messages in thread From: Takashi Iwai @ 2012-11-08 17:35 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Cox, joeyli, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi, Takashi Iwai ... when CONFIG_FIRMWARE_SIG is set. Signed-off-by: Takashi Iwai <tiwai@suse.de> --- Makefile | 6 ++++++ scripts/Makefile.fwinst | 18 ++++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index a1ccf22..c6d7a3e 100644 --- a/Makefile +++ b/Makefile @@ -729,6 +729,12 @@ mod_sign_cmd = true endif export mod_sign_cmd +ifeq ($(CONFIG_FIRMWARE_SIG),y) +fw_sign_cmd = perl $(srctree)/scripts/sign-file -f $(MODSECKEY) $(MODPUBKEY) +else +fw_sign_cmd = true +endif +export fw_sign_cmd ifeq ($(KBUILD_EXTMOD),) core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst index 4d908d1..df256f0 100644 --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -29,6 +29,20 @@ installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw)) installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ +ifeq ($(CONFIG_FIRMWARE_SIG),y) +installed-fw-sig := $(patsubst %,%.sig, $(installed-fw)) +installed-mod-fw-sig := $(patsubst %,%.sig, $(installed-mod-fw)) +else +installed-fw-sig := +installed-mod-fw-sig := +endif + +quiet_cmd_fwsig = FWSIG $@ + cmd_fwsig = $(fw_sign_cmd) $(patsubst %.sig,%,$@) $@ + +%.sig: % + $(call cmd,fwsig) + # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs $(INSTALL_FW_PATH)/$$(%): install-all-dirs @@ -49,9 +63,9 @@ PHONY += __fw_install __fw_modinst FORCE .PHONY: $(PHONY) -__fw_install: $(installed-fw) +__fw_install: $(installed-fw) $(installed-fw-sig) -__fw_modinst: $(installed-mod-fw) +__fw_modinst: $(installed-mod-fw) $(installed-mod-fw-sig) @: __fw_modbuild: $(addprefix $(obj)/,$(mod-fw)) -- 1.8.0 ^ permalink raw reply related [flat|nested] 224+ messages in thread
* Re: [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically 2012-11-08 17:35 ` [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically Takashi Iwai @ 2012-11-23 6:52 ` joeyli 0 siblings, 0 replies; 224+ messages in thread From: joeyli @ 2012-11-23 6:52 UTC (permalink / raw) To: Takashi Iwai Cc: Matthew Garrett, Alan Cox, Jiri Kosina, David Howells, Rusty Russell, Ming Lei, linux-kernel, linux-security-module, linux-efi 於 四,2012-11-08 於 18:35 +0100,Takashi Iwai 提到: > ... when CONFIG_FIRMWARE_SIG is set. > > Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Chun-Yi Lee <jlee@suse.com> Joey Lee > --- > Makefile | 6 ++++++ > scripts/Makefile.fwinst | 18 ++++++++++++++++-- > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index a1ccf22..c6d7a3e 100644 > --- a/Makefile > +++ b/Makefile > @@ -729,6 +729,12 @@ mod_sign_cmd = true > endif > export mod_sign_cmd > > +ifeq ($(CONFIG_FIRMWARE_SIG),y) > +fw_sign_cmd = perl $(srctree)/scripts/sign-file -f $(MODSECKEY) $(MODPUBKEY) > +else > +fw_sign_cmd = true > +endif > +export fw_sign_cmd > > ifeq ($(KBUILD_EXTMOD),) > core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ > diff --git a/scripts/Makefile.fwinst b/scripts/Makefile.fwinst > index 4d908d1..df256f0 100644 > --- a/scripts/Makefile.fwinst > +++ b/scripts/Makefile.fwinst > @@ -29,6 +29,20 @@ installed-mod-fw := $(addprefix $(INSTALL_FW_PATH)/,$(mod-fw)) > installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) > installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ > > +ifeq ($(CONFIG_FIRMWARE_SIG),y) > +installed-fw-sig := $(patsubst %,%.sig, $(installed-fw)) > +installed-mod-fw-sig := $(patsubst %,%.sig, $(installed-mod-fw)) > +else > +installed-fw-sig := > +installed-mod-fw-sig := > +endif > + > +quiet_cmd_fwsig = FWSIG $@ > + cmd_fwsig = $(fw_sign_cmd) $(patsubst %.sig,%,$@) $@ > + > +%.sig: % > + $(call cmd,fwsig) > + > # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. > PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs > $(INSTALL_FW_PATH)/$$(%): install-all-dirs > @@ -49,9 +63,9 @@ PHONY += __fw_install __fw_modinst FORCE > > .PHONY: $(PHONY) > > -__fw_install: $(installed-fw) > +__fw_install: $(installed-fw) $(installed-fw-sig) > > -__fw_modinst: $(installed-mod-fw) > +__fw_modinst: $(installed-mod-fw) $(installed-mod-fw-sig) > @: > > __fw_modbuild: $(addprefix $(obj)/,$(mod-fw)) ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:13 ` Takashi Iwai 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai @ 2012-11-06 0:01 ` David Howells 2012-11-06 7:01 ` Takashi Iwai 2012-11-06 0:05 ` David Howells 2 siblings, 1 reply; 224+ messages in thread From: David Howells @ 2012-11-06 0:01 UTC (permalink / raw) To: Takashi Iwai Cc: dhowells, Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, Rusty Russell, linux-kernel, linux-security-module, linux-efi Takashi Iwai <tiwai@suse.de> wrote: > this is a patch series to add the support for firmware signature > check. At this time, the kernel checks extra signature file (*.sig) > for each firmware, instead of embedded signature. > It's just a quick hack using the existing module signing mechanism, > thus provided only as a proof of concept for now. There is another way to do this. If you look at the patches I proposed to wrap keys in PE binaries, you'll find that that can handle PKCS#7 format messages as that's what's in the sort of signed PE binary we're dealing with. You could use this to put the firmware inside a signed-data PKCS#7 message. David ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-06 0:01 ` [PATCH RFC 0/4] Add firmware signature file check David Howells @ 2012-11-06 7:01 ` Takashi Iwai 0 siblings, 0 replies; 224+ messages in thread From: Takashi Iwai @ 2012-11-06 7:01 UTC (permalink / raw) To: David Howells Cc: Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, Rusty Russell, linux-kernel, linux-security-module, linux-efi At Tue, 06 Nov 2012 00:01:52 +0000, David Howells wrote: > > Takashi Iwai <tiwai@suse.de> wrote: > > > this is a patch series to add the support for firmware signature > > check. At this time, the kernel checks extra signature file (*.sig) > > for each firmware, instead of embedded signature. > > It's just a quick hack using the existing module signing mechanism, > > thus provided only as a proof of concept for now. > > There is another way to do this. If you look at the patches I proposed to > wrap keys in PE binaries, you'll find that that can handle PKCS#7 format > messages as that's what's in the sort of signed PE binary we're dealing with. > > You could use this to put the firmware inside a signed-data PKCS#7 message. Yeah, embedding the signature is more straightforward. Actually I tried the embedded signature (just like module) at first, then a couple of concerns arose: - Legally unclear about "modifying" the firmware data or file, - The signed firmware is no longer compatible with the older kernel, thus bad for distro packaging. thanks, Takashi ^ permalink raw reply [flat|nested] 224+ messages in thread
* Re: [PATCH RFC 0/4] Add firmware signature file check 2012-11-05 17:13 ` Takashi Iwai 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai 2012-11-06 0:01 ` [PATCH RFC 0/4] Add firmware signature file check David Howells @ 2012-11-06 0:05 ` David Howells 2 siblings, 0 replies; 224+ messages in thread From: David Howells @ 2012-11-06 0:05 UTC (permalink / raw) To: Takashi Iwai Cc: dhowells, Matthew Garrett, Alan Cox, joeyli, Jiri Kosina, Rusty Russell, linux-kernel, linux-security-module, linux-efi David Howells <dhowells@redhat.com> wrote: > Takashi Iwai <tiwai@suse.de> wrote: > > > this is a patch series to add the support for firmware signature > > check. At this time, the kernel checks extra signature file (*.sig) > > for each firmware, instead of embedded signature. > > It's just a quick hack using the existing module signing mechanism, > > thus provided only as a proof of concept for now. > > There is another way to do this. If you look at the patches I proposed to > wrap keys in PE binaries, you'll find that that can handle PKCS#7 format > messages as that's what's in the sort of signed PE binary we're dealing with. See: http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel-pekey > You could use this to put the firmware inside a signed-data PKCS#7 message. Note that the ASN.1 decoder in the kernel would need altering to handle messages larger than 64KB. David ^ permalink raw reply [flat|nested] 224+ messages in thread
end of thread, other threads:[~2012-11-23 7:34 UTC | newest] Thread overview: 224+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-09-20 14:40 [RFC] Second attempt at kernel secure boot support Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 01/10] Secure boot: Add new capability Matthew Garrett 2012-09-28 3:10 ` Serge Hallyn 2012-10-20 0:15 ` joeyli 2012-10-20 9:02 ` Matt Fleming 2012-09-20 14:40 ` [PATCH V2 02/10] PCI: Lock down BAR access in secure boot environments Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 03/10] x86: Lock down IO port " Matthew Garrett 2012-09-20 14:40 ` [PATCH V2 04/10] ACPI: Limit access to custom_method Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 05/10] asus-wmi: Restrict debugfs interface Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 06/10] Restrict /dev/mem and /dev/kmem in secure boot setups Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett 2012-09-20 16:32 ` Greg KH 2012-09-20 17:40 ` Josh Boyer 2012-09-25 13:08 ` [PATCH V3 " Josh Boyer 2012-10-29 9:00 ` joeyli 2012-10-30 17:48 ` Josh Boyer 2012-10-30 19:27 ` joeyli 2012-09-21 8:20 ` [PATCH V2 " joeyli 2012-09-28 3:20 ` Serge Hallyn 2012-09-20 14:41 ` [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett 2012-09-28 3:21 ` Serge Hallyn 2012-10-22 13:22 ` Matt Fleming 2012-09-20 14:41 ` [PATCH V2 09/10] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment Matthew Garrett 2012-09-20 14:41 ` [PATCH V2 10/10] SELinux: define mapping for new Secure Boot capability Matthew Garrett 2012-09-21 22:55 ` [RFC] Second attempt at kernel secure boot support Eric W. Biederman 2012-09-22 15:21 ` Matthew Garrett 2012-10-29 7:49 ` Jiri Kosina 2012-10-29 17:41 ` Matthew Garrett 2012-10-31 14:50 ` Jiri Kosina 2012-10-31 14:54 ` Josh Boyer 2012-10-31 14:59 ` Shea Levy 2012-10-31 15:55 ` Alan Cox 2012-10-31 15:55 ` Jiri Kosina 2012-10-31 17:03 ` Alan Cox 2012-10-31 17:01 ` Shea Levy 2012-10-31 17:17 ` Alan Cox 2012-10-31 17:10 ` Matthew Garrett 2012-10-31 17:21 ` Alan Cox 2012-10-31 17:17 ` Matthew Garrett 2012-10-31 17:39 ` Alan Cox 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 17:49 ` Alan Cox 2012-10-31 17:45 ` Matthew Garrett 2012-10-31 20:14 ` Oliver Neukum 2012-10-31 21:58 ` Chris Friesen 2012-10-31 22:00 ` Jiri Kosina 2012-10-31 22:19 ` Oliver Neukum 2012-11-01 9:08 ` James Bottomley 2012-11-01 9:20 ` Jiri Kosina 2012-11-01 9:38 ` James Bottomley 2012-11-01 9:45 ` Jiri Kosina 2012-11-01 9:59 ` James Bottomley 2012-11-01 10:06 ` Jiri Kosina 2012-11-01 14:29 ` Eric Paris 2012-11-01 14:42 ` James Bottomley 2012-11-01 14:49 ` Matthew Garrett 2012-11-01 15:06 ` James Bottomley 2012-11-01 15:17 ` Eric Paris 2012-11-01 16:26 ` Matthew Garrett 2012-11-01 15:06 ` Alan Cox 2012-11-01 16:29 ` Matthew Garrett 2012-11-01 16:40 ` Alan Cox 2012-11-01 14:59 ` Eric Paris 2012-11-01 15:11 ` Alan Cox 2012-11-01 15:18 ` James Bottomley 2012-11-01 17:50 ` Eric Paris 2012-11-01 21:03 ` James Bottomley 2012-11-01 21:06 ` Matthew Garrett 2012-11-01 21:14 ` James Bottomley 2012-11-01 21:18 ` Matthew Garrett 2012-11-01 21:35 ` Alan Cox 2012-11-01 21:31 ` Alan Cox 2012-11-01 21:28 ` Matthew Garrett 2012-11-01 21:37 ` Alan Cox 2012-11-01 21:34 ` Matthew Garrett 2012-11-01 21:58 ` Alan Cox 2012-11-01 21:57 ` Matthew Garrett 2012-11-02 8:49 ` Eric W. Biederman 2012-11-02 14:00 ` Matthew Garrett 2012-11-02 22:03 ` Eric W. Biederman 2012-11-02 22:19 ` Chris Friesen 2012-11-02 23:46 ` Alan Cox 2012-11-03 0:23 ` Matthew Garrett 2012-11-03 0:55 ` Alan Cox 2012-11-03 0:20 ` Matthew Garrett 2012-11-03 0:47 ` Eric W. Biederman 2012-11-03 1:03 ` Alan Cox 2012-11-03 1:43 ` Matthew Garrett 2012-11-03 16:31 ` Alan Cox 2012-11-03 16:37 ` Matthew Garrett 2012-11-03 16:37 ` Eric Paris 2012-11-03 16:42 ` Matthew Garrett 2012-11-02 17:19 ` Vivek Goyal 2012-11-01 14:46 ` Alan Cox 2012-11-01 15:04 ` Eric Paris 2012-11-01 20:27 ` Pavel Machek 2012-11-01 21:02 ` Chris Friesen 2012-11-02 15:48 ` Vivek Goyal 2012-11-02 16:54 ` Chris Friesen 2012-11-02 17:03 ` Vivek Goyal 2012-11-03 23:09 ` Jiri Kosina 2012-11-05 6:38 ` Eric W. Biederman 2012-11-05 14:40 ` Jiri Kosina 2012-11-05 15:31 ` Jiri Kosina 2012-11-05 15:37 ` Chris Friesen 2012-11-05 18:22 ` Vivek Goyal 2012-11-02 16:33 ` Pavel Machek 2012-11-02 16:52 ` James Bottomley 2012-11-02 16:54 ` Matthew Garrett 2012-11-02 17:48 ` James Bottomley 2012-11-02 17:54 ` Matthew Garrett 2012-11-02 17:57 ` James Bottomley 2012-11-02 18:04 ` Matthew Garrett 2012-11-02 19:18 ` Eric Paris 2012-11-02 23:38 ` James Bottomley 2012-11-03 0:22 ` Matthew Garrett 2012-11-03 12:03 ` James Bottomley 2012-11-03 13:46 ` Matthew Garrett 2012-11-03 22:56 ` James Bottomley 2012-11-04 4:28 ` Matthew Garrett 2012-11-04 9:14 ` James Bottomley 2012-11-04 13:52 ` Matthew Garrett 2012-11-05 6:14 ` Eric W. Biederman 2012-11-05 7:12 ` H. Peter Anvin 2012-11-05 7:24 ` Eric W. Biederman 2012-11-05 7:40 ` H. Peter Anvin 2012-11-05 8:50 ` Eric W. Biederman 2012-11-05 8:53 ` H. Peter Anvin 2012-11-05 12:38 ` Matthew Garrett 2012-11-05 13:44 ` Alan Cox 2012-11-05 13:46 ` Matthew Garrett 2012-11-05 19:16 ` Eric W. Biederman 2012-11-05 20:25 ` Matthew Garrett 2012-11-06 2:46 ` Eric W. Biederman 2012-11-06 3:12 ` Matthew Garrett 2012-11-06 3:36 ` Eric W. Biederman 2012-11-06 3:53 ` Matthew Garrett 2012-11-06 5:19 ` Eric W. Biederman 2012-11-06 5:34 ` Matthew Garrett 2012-11-06 7:56 ` Florian Weimer 2012-11-06 15:14 ` Chris Friesen 2012-11-06 15:19 ` Jiri Kosina 2012-11-06 21:51 ` Florian Weimer 2012-11-06 21:55 ` Matthew Garrett 2012-11-06 22:06 ` Florian Weimer 2012-11-06 22:31 ` Matthew Garrett 2012-11-06 22:49 ` Alan Cox 2012-11-06 22:47 ` Matthew Garrett [not found] ` <CAMFK0gt7oAr4ArD8FmD8QE+i4g4rSTmQjbbLcjs02xwQeXGx-A@mail.gmail.com> 2012-11-07 14:55 ` Matthew Garrett 2012-11-08 10:18 ` James Courtier-Dutton [not found] ` <CAAMvbhFF=kb8TJ4oE+40Zrx7HD1OkD0NOYj7QEZegZKGtqDm_A@mail.gmail.com> 2012-11-08 11:19 ` Alan Cox 2012-11-06 9:12 ` Alan Cox 2012-11-06 13:17 ` Matthew Garrett 2012-11-06 8:13 ` Valdis.Kletnieks 2012-11-05 8:20 ` James Bottomley 2012-11-05 12:36 ` Matthew Garrett 2012-11-04 11:53 ` Pavel Machek 2012-11-05 21:25 ` Florian Weimer 2012-11-02 14:55 ` Vivek Goyal 2012-11-01 10:12 ` Oliver Neukum 2012-10-31 17:21 ` Jiri Kosina 2012-10-31 15:56 ` Matthew Garrett 2012-10-31 17:08 ` Alan Cox 2012-10-31 17:08 ` Shea Levy 2012-10-31 16:04 ` Jiri Kosina 2012-10-31 16:10 ` Josh Boyer 2012-10-31 15:02 ` Matthew Garrett 2012-10-31 15:05 ` Shea Levy 2012-10-31 15:09 ` Matthew Garrett 2012-11-02 15:30 ` Vivek Goyal 2012-11-02 15:42 ` Matthew Garrett 2012-11-02 15:52 ` Vivek Goyal 2012-11-02 16:22 ` Jiri Kosina 2012-11-02 18:30 ` Vivek Goyal 2012-11-02 16:35 ` Shuah Khan 2012-11-06 12:51 ` Jiri Kosina 2012-11-06 13:16 ` Matthew Garrett 2012-10-31 17:28 ` Takashi Iwai 2012-10-31 17:37 ` Matthew Garrett 2012-10-31 17:44 ` Alan Cox 2012-10-31 17:44 ` Matthew Garrett 2012-10-31 18:53 ` Takashi Iwai 2012-11-01 4:21 ` joeyli 2012-11-01 13:18 ` Alan Cox 2012-11-05 17:13 ` Takashi Iwai 2012-11-05 17:18 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option Takashi Iwai 2012-11-05 17:19 ` [PATCH RFC 2/4] scripts/sign-file: Support firmware signing Takashi Iwai 2012-11-05 17:20 ` [PATCH RFC 3/4] firmware: Add a signature check Takashi Iwai 2012-11-06 6:03 ` Mimi Zohar 2012-11-05 17:20 ` [PATCH RFC 4/4] firmware: Install signature files automatically Takashi Iwai 2012-11-05 18:12 ` [PATCH RFC 0/4] Add firmware signature file check Takashi Iwai 2012-11-05 20:43 ` Josh Boyer 2012-11-06 6:46 ` Takashi Iwai 2012-11-06 9:20 ` Alan Cox 2012-11-06 10:05 ` Takashi Iwai 2012-11-06 2:30 ` Ming Lei 2012-11-06 5:46 ` lee joey 2012-11-06 7:03 ` Takashi Iwai 2012-11-06 7:16 ` Ming Lei 2012-11-06 7:32 ` Takashi Iwai 2012-11-06 8:04 ` Ming Lei 2012-11-06 8:18 ` Takashi Iwai 2012-11-06 10:04 ` Ming Lei 2012-11-06 10:17 ` Takashi Iwai 2012-11-06 10:40 ` Ming Lei 2012-11-06 10:53 ` Takashi Iwai 2012-11-06 11:03 ` Ming Lei 2012-11-06 11:15 ` Alan Cox [not found] ` <CAGB3EUTrSMDhja9Gu3h7nuZX+H2_owp8MnUNwbZuCW=_GuawqQ@mail.gmail.com> 2012-11-06 7:06 ` Takashi Iwai 2012-11-06 7:30 ` Ming Lei 2012-11-08 17:35 ` [PATCH RFC v2 " Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file Takashi Iwai 2012-11-23 6:51 ` joeyli 2012-11-08 17:35 ` [PATCH RFC v2 2/4] firmware: Add -a option " Takashi Iwai 2012-11-23 6:51 ` joeyli 2012-11-08 17:35 ` [PATCH RFC v2 3/4] firmware: Add support for signature checks Takashi Iwai 2012-11-23 6:56 ` joeyli 2012-11-23 7:34 ` Takashi Iwai 2012-11-08 17:35 ` [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically Takashi Iwai 2012-11-23 6:52 ` joeyli 2012-11-06 0:01 ` [PATCH RFC 0/4] Add firmware signature file check David Howells 2012-11-06 7:01 ` Takashi Iwai 2012-11-06 0:05 ` David Howells
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).