[RFC] Second attempt at kernel secure boot support

[RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

[PATCH V2 01/10] Secure boot: Add new capability

[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

Re: [PATCH V2 01/10] Secure boot: Add new capability

[Serge Hallyn]

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

Re: [PATCH V2 01/10] Secure boot: Add new capability

[joeyli]

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)
>  

Re: [PATCH V2 01/10] Secure boot: Add new capability

[Matt Fleming]

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.

[PATCH V2 02/10] PCI: Lock down BAR access in secure boot environments

[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

[PATCH V2 03/10] x86: Lock down IO port access in secure boot environments

[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

[PATCH V2 04/10] ACPI: Limit access to custom_method

[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

[PATCH V2 05/10] asus-wmi: Restrict debugfs interface

[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

[PATCH V2 06/10] Restrict /dev/mem and /dev/kmem in secure boot setups

[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

[PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[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>
---
 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

Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[Greg KH]

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

Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[Josh Boyer]

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

[PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[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
--- 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

Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[joeyli]

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

Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[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

Re: [PATCH V3 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[joeyli]

於 二，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

Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[joeyli]

於 四，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

Re: [PATCH V2 07/10] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode

[Serge Hallyn]

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

[PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware

[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

Re: [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware

[Serge Hallyn]

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

Re: [PATCH V2 08/10] efi: Enable secure boot lockdown automatically when enabled in firmware

[Matt Fleming]

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>

[PATCH V2 09/10] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment

[Matthew Garrett]

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

[PATCH V2 10/10] SELinux: define mapping for new Secure Boot capability

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Josh Boyer]

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

Re: [RFC] Second attempt at kernel secure boot support

[Shea Levy]

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?

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> > 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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Shea Levy]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> >> 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.

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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 ?

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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 ?

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Oliver Neukum]

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

Re: [RFC] Second attempt at kernel secure boot support

[Chris Friesen]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Oliver Neukum]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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)...

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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.

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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.

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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)

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Chris Friesen]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> You're guaranteed to be able 
> to do this on any Windows 8 certified hardware.

Thats not my understanding of the situation.

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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.

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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)

Re: [RFC] Second attempt at kernel secure boot support

[Pavel Machek]

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

Re: [RFC] Second attempt at kernel secure boot support

[Chris Friesen]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Chris Friesen]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Chris Friesen]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Pavel Machek]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

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.

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[H. Peter Anvin]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

"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

Re: [RFC] Second attempt at kernel secure boot support

[H. Peter Anvin]

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.

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

"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

Re: [RFC] Second attempt at kernel secure boot support

[H. Peter Anvin]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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)

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Eric W. Biederman]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Florian Weimer]

* 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.

Re: [RFC] Second attempt at kernel secure boot support

[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?

Secure boot does arguably solve a class of problems, so it seems a bit 
odd to recommend just throwing it out entirely.

Chris

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Florian Weimer]

* 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).

Re: [RFC] Second attempt at kernel secure boot support

[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. 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

Re: [RFC] Second attempt at kernel secure boot support

[Florian Weimer]

* 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.

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[James Courtier-Dutton]

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/

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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.

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Valdis.Kletnieks]

[-- 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 --]

Re: [RFC] Second attempt at kernel secure boot support

[James Bottomley]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Pavel Machek]

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

Re: [RFC] Second attempt at kernel secure boot support

[Florian Weimer]

* 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?

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Oliver Neukum]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

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)

Re: [RFC] Second attempt at kernel secure boot support

[Shea Levy]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Josh Boyer]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Shea Levy]

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.
>

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Vivek Goyal]

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

Re: [RFC] Second attempt at kernel secure boot support

[Shuah Khan]

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

Re: [RFC] Second attempt at kernel secure boot support

[Jiri Kosina]

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

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Takashi Iwai]

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);

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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 ?
 

Re: [RFC] Second attempt at kernel secure boot support

[Matthew Garrett]

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

Re: [RFC] Second attempt at kernel secure boot support

[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.


Takashi

Re: [RFC] Second attempt at kernel secure boot support

[joeyli]

於 三，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

Re: [RFC] Second attempt at kernel secure boot support

[Alan Cox]

> 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

Re: [RFC] Second attempt at kernel secure boot support

[Takashi Iwai]

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

[PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

[PATCH RFC 1/4] scripts/sign-file: Allow specifying hash algorithm via -a option

[Takashi Iwai]

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

[PATCH RFC 2/4] scripts/sign-file: Support firmware signing

[Takashi Iwai]

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

[PATCH RFC 3/4] firmware: Add a signature check

[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.  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

Re: [PATCH RFC 3/4] firmware: Add a signature check

[Mimi Zohar]

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 */

[PATCH RFC 4/4] firmware: Install signature files automatically

[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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Josh Boyer]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Alan Cox]

> 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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[lee joey]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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;
 

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Alan Cox]

> > 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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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)>]
> 

Re: [PATCH RFC 0/4] Add firmware signature file check

[Ming Lei]

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

[PATCH RFC v2 0/4] Add firmware signature file check

[Takashi Iwai]

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

[PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file

[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

Re: [PATCH RFC v2 1/4] firmware: Add the firmware signing support to scripts/sign-file

[joeyli]

於 四，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;
>  }

[PATCH RFC v2 2/4] firmware: Add -a option to scripts/sign-file

[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

Re: [PATCH RFC v2 2/4] firmware: Add -a option to scripts/sign-file

[joeyli]

於 四，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";
>  }
>  
>  #

[PATCH RFC v2 3/4] firmware: Add support for signature checks

[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

Re: [PATCH RFC v2 3/4] firmware: Add support for signature checks

[joeyli]

於 四，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

Re: [PATCH RFC v2 3/4] firmware: Add support for signature checks

[Takashi Iwai]

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

[PATCH RFC v2 4/4] firmware: Install firmware signature files automatically

[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

Re: [PATCH RFC v2 4/4] firmware: Install firmware signature files automatically

[joeyli]

於 四，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))

Re: [PATCH RFC 0/4] Add firmware signature file check

[David Howells]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[Takashi Iwai]

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

Re: [PATCH RFC 0/4] Add firmware signature file check

[David Howells]

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

[PATCH 0/10] Add additional security checks when module loading is restricted

[Matthew Garrett]

We have two in-kernel mechanisms for restricting module loading - disabling
it entirely, or limiting it to the loading of modules signed with a trusted
key. These can both be configured in such a way that even root is unable to
relax the restrictions.

However, right now, there's several other straightforward ways for root to
modify running kernel code. At the most basic level these allow root to
reset the configuration such that modules can be loaded again, rendering
the existing restrictions useless.

This patchset adds additional restrictions to various kernel entry points
that would otherwise make it straightforward for root to disable enforcement
of module loading restrictions. It also provides a patch that allows the
kernel to be configured such that module signing will be automatically
enabled when the system is booting via UEFI Secure Boot, allowing a stronger
guarantee of kernel integrity.

[PATCH V2 04/10] ACPI: Limit access to custom_method

[Matthew Garrett]

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if any such restrictions have been enabled.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
---
 drivers/acpi/custom_method.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index 12b62f2..55a013f 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -7,6 +7,7 @@
 #include <linux/kernel.h>
 #include <linux/uaccess.h>
 #include <linux/debugfs.h>
+#include <linux/module.h>
 #include <acpi/acpi_drivers.h>
 
 #include "internal.h"
@@ -29,6 +30,9 @@ static ssize_t cm_write(struct file *file, const char __user * user_buf,
 	struct acpi_table_header table;
 	acpi_status status;
 
+	if (secure_modules())
+		return -EPERM;
+
 	if (!(*ppos)) {
 		/* parse the table header to get the table length */
 		if (count <= sizeof(struct acpi_table_header))
-- 
1.8.3.1