[RFC] First attempt at kernel secure boot support

[RFC] First attempt at kernel secure boot support

[Matthew Garrett]

The UEFI Secure Boot trust model is based on it not being possible for a
user to cause a signed OS to boot an unsigned OS, even if that user has
administrative privileges. This is an initial attempt at a set of patches
to reduce root's ability to modify the kernel. We've done this with an
additional capability for a couple of reasons:

1) CAP_SYS_RAWIO already covers pretty much everything we want, but also
   disables a lot of functionality that we don't want to lose. Following
   the same model seems reasonable.
2) This capability may be more generically useful for some use-cases.
   Adding a set of hardcoded is_secure_boot() checks in the same places would
   prevent that.

Feedback welcome.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[PATCH 01/11] 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..6a39163 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 are dangerous under secure boot */
+
+#define CAP_SECURE_FIRMWARE  37
+
+#define CAP_LAST_CAP         CAP_SECURE_FIRMWARE
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
-- 
1.7.11.4

[PATCH 02/11] 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 6869009..a1ad0f7 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -542,6 +542,9 @@ pci_write_config(struct file* filp, struct kobject *kobj,
 	loff_t init_off = off;
 	u8 *data = (u8*) buf;
 
+	if (!capable(CAP_SECURE_FIRMWARE))
+		return -EPERM;
+
 	if (off > dev->cfg_size)
 		return 0;
 	if (off + count > dev->cfg_size) {
@@ -844,6 +847,9 @@ pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
 	resource_size_t start, end;
 	int i;
 
+	if (!capable(CAP_SECURE_FIRMWARE))
+		return -EPERM;
+
 	for (i = 0; i < PCI_ROM_RESOURCE; i++)
 		if (res == &pdev->resource[i])
 			break;
@@ -951,6 +957,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_SECURE_FIRMWARE))
+		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..01d4753 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_SECURE_FIRMWARE))
+		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_SECURE_FIRMWARE))
+		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_SECURE_FIRMWARE))
 		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..a778ba9 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_SECURE_FIRMWARE))
 		return -EPERM;
 
 	dev = pci_get_bus_and_slot(bus, dfn);
-- 
1.7.11.4

Re: [PATCH 02/11] PCI: Lock down BAR access in secure boot environments

[Pavel Machek]

On Tue 2012-09-04 11:55:08, Matthew Garrett wrote:
> 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.

Would it be possible to

1) Use some better name than CAP_SECURE_FIRMWARE

2) Explain somewhere what the real requirements for "secure" boot are?

"Secure" kernel may not boot unsigned kernel... what does it mean
exactly?

Suppose I launch full-screen window with dosemu running original
windows installation on HDD, accessing raw disks, at nearly native
speed. That is not something kernel should prevent, but it still
allows me to do to do the stuff "secure" boot was designed to
prevent... right?

What is the exact threat "secure" boot should protect us against?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 03/11] 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..c3a1bb2 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_SECURE_FIRMWARE)))
 		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_SECURE_FIRMWARE))
 			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..8f5f872 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_SECURE_FIRMWARE))
+		return -EPERM;
+
 	if (!access_ok(VERIFY_READ, buf, count))
 		return -EFAULT;
 	while (count-- > 0 && i < 65536) {
-- 
1.7.11.4

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

[Alan Cox]

On Tue,  4 Sep 2012 11:55:09 -0400
Matthew Garrett <mjg@redhat.com> wrote:

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

You've missed a load of others, all over the kernel, let alone getting
into devices with other paths to firmware reprogramming of which there
are many.

You need to enforce signing on request_firmware for example, and sign
every firmware.

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

[Matthew Garrett]

On Tue, Sep 04, 2012 at 05:16:03PM +0100, Alan Cox wrote:
> On Tue,  4 Sep 2012 11:55:09 -0400
> Matthew Garrett <mjg@redhat.com> wrote:
> 
> > 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.
> 
> You've missed a load of others, all over the kernel, let alone getting
> into devices with other paths to firmware reprogramming of which there
> are many.
> 
> You need to enforce signing on request_firmware for example, and sign
> every firmware.

Sure, but that's going to depend on the module signing code which hasn't 
landed yet. But for the most part, devices that are designed for these 
platforms will only accept signed firmware at the device level.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[PATCH 04/11] 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..3e78014 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_SECURE_FIRMWARE))
+		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 05/11] 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 2eb9fe8..03ea0e8 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1523,6 +1523,9 @@ static int show_dsts(struct seq_file *m, void *data)
 	int err;
 	u32 retval = -1;
 
+	if (!capable(CAP_SECURE_FIRMWARE))
+		return -EPERM;
+
 	err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
 
 	if (err < 0)
@@ -1539,6 +1542,9 @@ static int show_devs(struct seq_file *m, void *data)
 	int err;
 	u32 retval = -1;
 
+	if (!capable(CAP_SECURE_FIRMWARE))
+		return -EPERM;
+
 	err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
 				    &retval);
 
@@ -1563,6 +1569,9 @@ static int show_call(struct seq_file *m, void *data)
 	union acpi_object *obj;
 	acpi_status status;
 
+	if (!capable(CAP_SECURE_FIRMWARE))
+		return -EPERM;
+
 	status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
 				     1, asus->debug.method_id,
 				     &input, &output);
-- 
1.7.11.4

Re: [PATCH 05/11] asus-wmi: Restrict debugfs interface

[Alan Cox]

On Tue,  4 Sep 2012 11:55:11 -0400
Matthew Garrett <mjg@redhat.com> wrote:

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

This is true of any firmware method on any device Why pick on ASUS. Have
you run this through ASUS and discussed it with them. It seems highly
inappropriate to cripple a specific vendors feature set without
discussion and an Ack from the vendor concerned.

Alan

Re: [PATCH 05/11] asus-wmi: Restrict debugfs interface

[Matthew Garrett]

On Tue, Sep 04, 2012 at 05:12:05PM +0100, Alan Cox wrote:
> On Tue,  4 Sep 2012 11:55:11 -0400
> Matthew Garrett <mjg@redhat.com> wrote:
> 
> > 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.
> 
> This is true of any firmware method on any device Why pick on ASUS. Have
> you run this through ASUS and discussed it with them. It seems highly
> inappropriate to cripple a specific vendors feature set without
> discussion and an Ack from the vendor concerned.

Because asus-wmi is the only driver that has a debugfs interface that 
lets you run arbitrary WMI methods.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

[PATCH 06/11] 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 8f5f872..c1de8e1 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_SECURE_FIRMWARE))
+		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_SECURE_FIRMWARE))
+		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 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

kexec could be used as a vector for a malicious user to use a signed kernel
to circumvent the secure boot trust model. In the long run we'll want to
support signed kexec payloads, but for the moment we should just disable
loading entirely in that situation.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
 kernel/kexec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..48852ec 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -944,7 +944,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT))
+	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SECURE_FIRMWARE))
 		return -EPERM;
 
 	/*
-- 
1.7.11.4

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric W. Biederman]

Matthew Garrett <mjg@redhat.com> writes:

> kexec could be used as a vector for a malicious user to use a signed kernel
> to circumvent the secure boot trust model. In the long run we'll want to
> support signed kexec payloads, but for the moment we should just disable
> loading entirely in that situation.

Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This makes no sense.  The naming CAP_SECURE_FIRMWARE is attrocious,
you aren't implementing or enforcing secure firmware.

You don't give any justification for this other than to support some
silly EFI feature.  Why would anyone want this if we were not booting
under EFI?

Eric

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote:
> 
> Matthew Garrett <mjg@redhat.com> writes:
> 
> > kexec could be used as a vector for a malicious user to use a signed kernel
> > to circumvent the secure boot trust model. In the long run we'll want to
> > support signed kexec payloads, but for the moment we should just disable
> > loading entirely in that situation.
> 
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 
> This makes no sense.  The naming CAP_SECURE_FIRMWARE is attrocious,
> you aren't implementing or enforcing secure firmware.

I'm certainly not attached to the name, and have no problem replacing 
it.

> You don't give any justification for this other than to support some
> silly EFI feature.  Why would anyone want this if we were not booting
> under EFI?

Well, given that approximately everyone will be booting under EFI within 
18 months, treating it as a niche case seems a little short sighted. And 
secondly, there are already several non-EFI platforms that want to enact 
a policy preventing root from being able to arbitrarily replace the 
kernel. Given that people are doing this in the wild, it makes sense to 
move towards offering that policy in the mainline kernel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric W. Biederman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote:
>> 
>> Matthew Garrett <mjg@redhat.com> writes:
>> 
>> > kexec could be used as a vector for a malicious user to use a signed kernel
>> > to circumvent the secure boot trust model. In the long run we'll want to
>> > support signed kexec payloads, but for the moment we should just disable
>> > loading entirely in that situation.
>> 
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> 
>> This makes no sense.  The naming CAP_SECURE_FIRMWARE is attrocious,
>> you aren't implementing or enforcing secure firmware.
>
> I'm certainly not attached to the name, and have no problem replacing 
> it.
>
>> You don't give any justification for this other than to support some
>> silly EFI feature.  Why would anyone want this if we were not booting
>> under EFI?
>
> Well, given that approximately everyone will be booting under EFI within 
> 18 months, treating it as a niche case seems a little short sighted.

If we are all going to be using the code we need to keep the code
quality high.

> And 
> secondly, there are already several non-EFI platforms that want to enact 
> a policy preventing root from being able to arbitrarily replace the 
> kernel. Given that people are doing this in the wild, it makes sense to 
> move towards offering that policy in the mainline kernel.

Either this code makes sense without an appeal to EFI or this code makes
no sense.

It is fine for jumping through the EFI trusted boot hoops to be your
motivation, but EFI policy should not be the justification for kernel
implementation details.

There may be some sense to the desired functionality.  From what I have
seen of the policies so far I have no respect for the way people are
using EFI secure boot.  I have no expectation that EFI secure boot will
stop malware as long as anything signed by microsoft's key is trusted by
the firmware.  We have already seen malware in the wild that could be
verified with Microsoft's key.

So please rework this to come from an angle that makes sense all by
itself.

Eric

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 02:13:54PM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
> > And 
> > secondly, there are already several non-EFI platforms that want to enact 
> > a policy preventing root from being able to arbitrarily replace the 
> > kernel. Given that people are doing this in the wild, it makes sense to 
> > move towards offering that policy in the mainline kernel.
> 
> Either this code makes sense without an appeal to EFI or this code makes
> no sense.

The driving force behind this code right now is that our choices are 
either (1) do something like this, or (2) disable kexec entirely. Like I 
said, long term we'd want to provide appropriate technical mechanisms to 
make kexec usable in a world where people want to be able to trust their 
kernel, and we have people working on that. But that being our 
motivation for the implementation doesn't mean that other parties won't 
have uses for it, and I'd like to find a solution that satisfies them as 
well.

> It is fine for jumping through the EFI trusted boot hoops to be your
> motivation, but EFI policy should not be the justification for kernel
> implementation details.

Sure it is. The kernel exists to provide the functionality that people 
require, and UEFI imposes that requirement on the people. It's like 
saying gcc policy shouldn't be the justification for kernel 
implementation details. We don't control the gcc developers, but we have 
to consume what they provide us with.

> So please rework this to come from an angle that makes sense all by
> itself.

I'm afraid I have no idea what you're asking for here. Some vendors want 
to be able to ensure that kexec is only used to load trusted code. Right 
now there's no mechanism for ensuring that, so why not at least provide 
a mechanism for them to turn it off at runtime?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric W. Biederman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Tue, Sep 04, 2012 at 02:13:54PM -0700, Eric W. Biederman wrote:
>> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>> > And 
>> > secondly, there are already several non-EFI platforms that want to enact 
>> > a policy preventing root from being able to arbitrarily replace the 
>> > kernel. Given that people are doing this in the wild, it makes sense to 
>> > move towards offering that policy in the mainline kernel.
>> 
>> Either this code makes sense without an appeal to EFI or this code makes
>> no sense.
>
> The driving force behind this code right now is that our choices are 
> either (1) do something like this, or (2) disable kexec entirely.

Actually there is an interesting question here. Why does even EFI secure
boot justify this?  If I install my own key in EFI I should be able to
boot a kernel that does anything I want it to.   My machine doing what I
want it to is the point of trusted boot is it not?

> Like I 
> said, long term we'd want to provide appropriate technical mechanisms to 
> make kexec usable in a world where people want to be able to trust their 
> kernel, and we have people working on that. But that being our 
> motivation for the implementation doesn't mean that other parties won't 
> have uses for it, and I'd like to find a solution that satisfies them as 
> well.

I expect you want to make that that medium term.  Enterprise distros
don't ship without kexec-on-panic.  Too often long term seems to be
something that no one ever gets around to in kernel development.

>> It is fine for jumping through the EFI trusted boot hoops to be your
>> motivation, but EFI policy should not be the justification for kernel
>> implementation details.
>
> Sure it is. The kernel exists to provide the functionality that people 
> require, and UEFI imposes that requirement on the people. It's like 
> saying gcc policy shouldn't be the justification for kernel 
> implementation details. We don't control the gcc developers, but we have 
> to consume what they provide us with.

This isn't efi specific code.  We need to be able to think about what
is happening with a local analysis so we can see if it is correct.

This is slightly violated already as pointed out elsewhere,
as CAP_SECURE_BOOT means we did not boot securely.

>> So please rework this to come from an angle that makes sense all by
>> itself.
>
> I'm afraid I have no idea what you're asking for here. Some vendors want 
> to be able to ensure that kexec is only used to load trusted code. Right 
> now there's no mechanism for ensuring that, so why not at least provide 
> a mechanism for them to turn it off at runtime?

There is a mechanism to turn it off at runtime CAP_SYS_BOOT.

In general booting anything else besides what you are running is equally
bad.

What I am asking for is a mechanism that makes sense without having to
think about EFI.  Without having to think about the silly hoops people
are going through because of the impending launch of windows 8.

As Alan says a capability doesn't seem horrible.  But if we use a
capability it needs to be a well named capability, and the semantics
of the capability need to make inherent sense.

I have the basic question, why can't I trust the root who has all
capabilities?  What makes the root user more trusted than the linux
kernel.  Especially when typically the root user is the owner of
the machine.

There is a element here where it seems implementing the policy you
are proposing will start encouraging people to start hoarding kernel
bugs instead of reporting them.  So implementing this policy might
make the kernel in net less secure.  How is that prevented?

Ultimately the question is.

This is Unix.  In Unix we give root rope and let him hang himself
or shoot himself in the foot (not that we encourage it).

Why are we now implementing a security model where we don't trust root?

What is gained from a security model where root is untrusted?

Eric

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
> > The driving force behind this code right now is that our choices are 
> > either (1) do something like this, or (2) disable kexec entirely.
> 
> Actually there is an interesting question here. Why does even EFI secure
> boot justify this?  If I install my own key in EFI I should be able to
> boot a kernel that does anything I want it to.   My machine doing what I
> want it to is the point of trusted boot is it not?

The full implementation should trust keys that are trusted by the 
platform, so it'd boot any kexec image you cared to sign. Or simply 
patch this code out and rebuild and self-sign, or disable the code that 
turns off the capability when in secure boot mode. I've no objection to 
putting that behind an #ifdef.

> > Like I 
> > said, long term we'd want to provide appropriate technical mechanisms to 
> > make kexec usable in a world where people want to be able to trust their 
> > kernel, and we have people working on that. But that being our 
> > motivation for the implementation doesn't mean that other parties won't 
> > have uses for it, and I'd like to find a solution that satisfies them as 
> > well.
> 
> I expect you want to make that that medium term.  Enterprise distros
> don't ship without kexec-on-panic.  Too often long term seems to be
> something that no one ever gets around to in kernel development.

I can't comment on the release schedule of unnanounced products or 
features that we may wish to be implemented in them.

> > Sure it is. The kernel exists to provide the functionality that people 
> > require, and UEFI imposes that requirement on the people. It's like 
> > saying gcc policy shouldn't be the justification for kernel 
> > implementation details. We don't control the gcc developers, but we have 
> > to consume what they provide us with.
> 
> This isn't efi specific code.  We need to be able to think about what
> is happening with a local analysis so we can see if it is correct.
> 
> This is slightly violated already as pointed out elsewhere,
> as CAP_SECURE_BOOT means we did not boot securely.

If your problem is the naming, we'll change the name. Really not a 
problem.

> > I'm afraid I have no idea what you're asking for here. Some vendors want 
> > to be able to ensure that kexec is only used to load trusted code. Right 
> > now there's no mechanism for ensuring that, so why not at least provide 
> > a mechanism for them to turn it off at runtime?
> 
> There is a mechanism to turn it off at runtime CAP_SYS_BOOT.

Which also prevents anyone from rebooting the system, which is really 
not what we're aiming for here. The firmware can enforce the booting of 
trusted code, the aim is to ensure that the kernel has equivalent 
functionality.

> What I am asking for is a mechanism that makes sense without having to
> think about EFI.  Without having to think about the silly hoops people
> are going through because of the impending launch of windows 8.

Again, I'm not clear on what you're talking about here. There's nothing 
UEFI specific about this patch. Anyone who has firmware-level trust can 
drop this capability in order to make it harder for someone to 
circumvent that trust by replacing the running kernel at runtime.

> I have the basic question, why can't I trust the root who has all
> capabilities?  What makes the root user more trusted than the linux
> kernel.  Especially when typically the root user is the owner of
> the machine.

Because historically we've found that root is also often someone who has 
determined a mechanism for running arbitrary code on your machine, 
rather than someone you trust. Root and the kernel aren't equivalent, 
otherwise root would just be able to turn off memory protection in their 
userspace processes. This patchset merely strengthens that existing 
dividing line.

> There is a element here where it seems implementing the policy you
> are proposing will start encouraging people to start hoarding kernel
> bugs instead of reporting them.  So implementing this policy might
> make the kernel in net less secure.  How is that prevented?

It's not. The metric I'm concerned with says a kernel where root can 
load arbitrary code into the kernel is less secure than one where root 
can't do that. Implementing this functionality may result in some 
unfixed flaws that permit root to load arbitrary code. Not implementing 
this functionality *guarantees* that root can load arbitrary code. So, 
by the metric I'm concerned with, security improves. But security isn't 
a bright line subject, and other people may disagree. I can't force 
anyone to implement a given policy.

> Ultimately the question is.
> 
> This is Unix.  In Unix we give root rope and let him hang himself
> or shoot himself in the foot (not that we encourage it).
> 
> Why are we now implementing a security model where we don't trust root?
> 
> What is gained from a security model where root is untrusted?

Root is already untrusted to a degree. We want to provide a mechanism 
that permits the user to indicate that they want to make that more 
explicit.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric W. Biederman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote:
>> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>> > The driving force behind this code right now is that our choices are 
>> > either (1) do something like this, or (2) disable kexec entirely.
>> 
>> Actually there is an interesting question here. Why does even EFI secure
>> boot justify this?  If I install my own key in EFI I should be able to
>> boot a kernel that does anything I want it to.   My machine doing what I
>> want it to is the point of trusted boot is it not?
>
> The full implementation should trust keys that are trusted by the 
> platform, so it'd boot any kexec image you cared to sign. Or simply 
> patch this code out and rebuild and self-sign, or disable the code that 
> turns off the capability when in secure boot mode. I've no objection to 
> putting that behind an #ifdef.

I will be happy to see a version of kexec that accepts signed images,
allowing the functionality to work in your brave new world where
everything must be signed.

Until then I don't see a point in merging anything else.

I will be happy to see some reasonable patchs for signing support on the
kexec path.

Eric

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 09:33:31PM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
> > The full implementation should trust keys that are trusted by the 
> > platform, so it'd boot any kexec image you cared to sign. Or simply 
> > patch this code out and rebuild and self-sign, or disable the code that 
> > turns off the capability when in secure boot mode. I've no objection to 
> > putting that behind an #ifdef.
> 
> I will be happy to see a version of kexec that accepts signed images,
> allowing the functionality to work in your brave new world where
> everything must be signed.
> 
> Until then I don't see a point in merging anything else.

Fine. We'll just carry this one out of tree for now.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric W. Biederman]

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> On Tue, Sep 04, 2012 at 09:33:31PM -0700, Eric W. Biederman wrote:
>> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>> > The full implementation should trust keys that are trusted by the 
>> > platform, so it'd boot any kexec image you cared to sign. Or simply 
>> > patch this code out and rebuild and self-sign, or disable the code that 
>> > turns off the capability when in secure boot mode. I've no objection to 
>> > putting that behind an #ifdef.
>> 
>> I will be happy to see a version of kexec that accepts signed images,
>> allowing the functionality to work in your brave new world where
>> everything must be signed.
>> 
>> Until then I don't see a point in merging anything else.
>
> Fine. We'll just carry this one out of tree for now.

It is your tree.

I am disappointed to learn that you aren't enthusiastic about
implementing verification of signatures for all code that goes into
ring 0.

Eric

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Wed, Sep 05, 2012 at 12:00:31AM -0700, Eric W. Biederman wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
> > Fine. We'll just carry this one out of tree for now.
> 
> It is your tree.
> 
> I am disappointed to learn that you aren't enthusiastic about
> implementing verification of signatures for all code that goes into
> ring 0.

I am enthusiastic, but October 26th is a date outside my control and 
kexec isn't at the top of the priority list. We ship with the code we 
have, not the code we want.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Alan Cox]

> > Well, given that approximately everyone will be booting under EFI within 
> > 18 months, treating it as a niche case seems a little short sighted.

Actually the majority of Linux devices are not PCs 8)

> > secondly, there are already several non-EFI platforms that want to enact 
> > a policy preventing root from being able to arbitrarily replace the 
> > kernel. Given that people are doing this in the wild, it makes sense to 
> > move towards offering that policy in the mainline kernel.
> 
> Either this code makes sense without an appeal to EFI or this code makes
> no sense.

Yes - and the capability is I think the right starting point (although
you'll never make any OS locked down this way even if you are not in fact
violating the GPLv2 license by doing so, which I suspect will be the case
for some implementations)

> So please rework this to come from an angle that makes sense all by
> itself.

I think it needs to be defined in terms of what the capability is
supposed to guarantee. I have a feeling Matthew has a pretty clear idea
about that in his head so can nail it fairly precisely ?

Alan

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 10:39:57PM +0100, Alan Cox wrote:
> > > Well, given that approximately everyone will be booting under EFI within 
> > > 18 months, treating it as a niche case seems a little short sighted.
> 
> Actually the majority of Linux devices are not PCs 8)

ARM's going UEFI as well...

> I think it needs to be defined in terms of what the capability is
> supposed to guarantee. I have a feeling Matthew has a pretty clear idea
> about that in his head so can nail it fairly precisely ?

In the absence of this capability, all users (including root) should be 
unable to cause untrusted code to be executed in ring 0. This requires 
some straightforward and obvious conditions like "The user must not be 
able to load untrusted modules", but also conditions like "The user must 
not be able to cause devices to DMA over the kernel". "The user must not 
be able to kexec into an untrusted kernel" is at the more obvious end of 
the scale. This is obviously dependent upon there being some mechanism 
for ensuring that the initial kernel is trusted in the first place, 
which is where the firmware security comes in.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Roland Eggner]

[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]

On 2012-09-04 Tuesday at 22:40 +0100 Matthew Garrett wrote:
> On Tue, Sep 04, 2012 at 10:39:57PM +0100, Alan Cox wrote:
> > I think it needs to be defined in terms of what the capability is
> > supposed to guarantee. I have a feeling Matthew has a pretty clear idea
> > about that in his head so can nail it fairly precisely ?
> 
> In the absence of this capability, all users (including root) should be 
> unable to cause untrusted code to be executed in ring 0. This requires 
> some straightforward and obvious conditions like "The user must not be 
> able to load untrusted modules", but also conditions like "The user must 
> not be able to cause devices to DMA over the kernel". "The user must not 
> be able to kexec into an untrusted kernel" is at the more obvious end of 
> the scale. This is obviously dependent upon there being some mechanism 
> for ensuring that the initial kernel is trusted in the first place, 
> which is where the firmware security comes in.

You believe in firmware security?  Not yet heard of “Rakshasa”?  Reading [1] may 
change your mind.


Want to support Erics technical arguments, given in another branche of this
thread, by some “political” aspects:  If I have payed for a device and then would
not be allowed to use it due to some obscure “security” feature, this could
perhaps be close to criminal.  I am not a lawyer, can only guess.  A few years ago
a friend of mine bought an originally quite expensive, used notebook for just a
few Euro.  The seller was forced to do so, just because he added RAM and changed
HD, causing activation of an unknown hardware password.  It has been set by a
retailer or the vendor, the latter being one of the largest players on the world
market.  Certainly I will never buy a device of this brand.  If Linux mainline
would really implement some kind of knock-out “security” feature, and would
switch from GPL to another, for such a new policy more adequate copyright
licence:  it would be sad, but technically no problem, there are plenty of
alternatives beyond penguins, windows and gates.  Other users and contributors
might follow … not good for the future of the Linux project.  Better stick to the
GPL and policy of freedom, then 20 years of aweful success on servers and
embedded devices are more likely to continue or even to grow.


[1]
Jonathan Brossard:  “… We have built a generic proof of concept malware for the 
Intel architecture,  called 'Rakshasa',  capable of infecting more than 100 
different motherboards.  Targets are BIOS and firmware of PCI-devices.  …”
http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf


-- 
Roland Eggner

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Wed, Sep 05, 2012 at 05:43:08PM +0200, Roland Eggner wrote:

> Jonathan Brossard:  “… We have built a generic proof of concept malware for the 
> Intel architecture,  called 'Rakshasa',  capable of infecting more than 100 
> different motherboards.  Targets are BIOS and firmware of PCI-devices.  …”
> http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf

Neatly avoided by the relevant UEFI platforms requiring that all 
firmware be signed.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Mimi Zohar]

On Tue, 2012-09-04 at 11:55 -0400, Matthew Garrett wrote:
> kexec could be used as a vector for a malicious user to use a signed kernel
> to circumvent the secure boot trust model. In the long run we'll want to
> support signed kexec payloads, but for the moment we should just disable
> loading entirely in that situation.
> 
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
> ---
>  kernel/kexec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 0668d58..48852ec 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -944,7 +944,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  	int result;
> 
>  	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SECURE_FIRMWARE))
>  		return -EPERM;
> 
>  	/*

Normally capabilities provide additional permissions. So if you don't
have the capability, an errno is returned.  CAP_SYS_BOOT is a good
example.  With CAP_SECURE_FIRMWARE, it reads backwards - if not
CAP_SECURE_FIRMWARE, return error.  I think you want to invert the name
to CAP_NOT_SECURE_FIRMWARE, CAP_NOT_SECURE_BOOT or perhaps
CAP_UNSECURED_BOOT.

Mimi

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Matthew Garrett]

On Wed, Sep 05, 2012 at 05:13:49PM -0400, Mimi Zohar wrote:

> Normally capabilities provide additional permissions. So if you don't
> have the capability, an errno is returned.  CAP_SYS_BOOT is a good
> example.  With CAP_SECURE_FIRMWARE, it reads backwards - if not
> CAP_SECURE_FIRMWARE, return error.  I think you want to invert the name
> to CAP_NOT_SECURE_FIRMWARE, CAP_NOT_SECURE_BOOT or perhaps
> CAP_UNSECURED_BOOT.

Yeah, I think renaming the cap is a given.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 07/11] kexec: Disable in a secure boot environment

[Eric Paris]

On Wed, Sep 5, 2012 at 5:41 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> Yeah, I think renaming the cap is a given.

CAP_RING_ZERO

Needed for any activity which would give root the ability to run code in ring 0?

[PATCH 08/11] 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_SECURE_FIRMWARE 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..47669a9 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_SECURE_FIRMWARE);
+	cap_lower((&init_cred)->cap_permitted, CAP_SECURE_FIRMWARE);
+}
+
+/* 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

[PATCH 09/11] 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

[PATCH 10/11] 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_SECURE_FIRMWARE 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..50c94e4 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_SECURE_FIRMWARE))
 		return acpi_rsdp;
 #endif
 
-- 
1.7.11.4

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

[Shuah Khan]

On Tue, Sep 4, 2012 at 9:55 AM, Matthew Garrett <mjg@redhat.com> wrote:
> 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_SECURE_FIRMWARE capability.

Does this mean, acpi_rsdp is disabled on all current platforms that
don't support CAP_SECURE_FIRMWARE?

-- Shuah
>
> 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..50c94e4 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_SECURE_FIRMWARE))
>                 return acpi_rsdp;
>  #endif
>
> --
> 1.7.11.4
>
> --
> 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: [PATCH 10/11] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment

[Matthew Garrett]

On Tue, Sep 04, 2012 at 10:30:46AM -0600, Shuah Khan wrote:
> On Tue, Sep 4, 2012 at 9:55 AM, Matthew Garrett <mjg@redhat.com> wrote:
> > 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_SECURE_FIRMWARE capability.
> 
> Does this mean, acpi_rsdp is disabled on all current platforms that
> don't support CAP_SECURE_FIRMWARE?

No, if you're not using secure boot then you'll have 
CAP_SECURE_FIRMWARE.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Shuah Khan]

On Tue, Sep 4, 2012 at 10:38 AM, Matthew Garrett <mjg@redhat.com> wrote:
> On Tue, Sep 04, 2012 at 10:30:46AM -0600, Shuah Khan wrote:
>> On Tue, Sep 4, 2012 at 9:55 AM, Matthew Garrett <mjg@redhat.com> wrote:
>> > 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_SECURE_FIRMWARE capability.
>>
>> Does this mean, acpi_rsdp is disabled on all current platforms that
>> don't support CAP_SECURE_FIRMWARE?
>
> No, if you're not using secure boot then you'll have
> CAP_SECURE_FIRMWARE.

Gotta say this capability name is confusing. Naming is
CAP_PRE_SECURE_BOOT or something along the lines might be a better
choice. When I just look at this name, I sure thought this
CAP_SECURE_FIRMWARE true means it is a secure boot capable firmware.

-- Shuah

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

[Alan Cox]

> Gotta say this capability name is confusing. Naming is
> CAP_PRE_SECURE_BOOT or something along the lines might be a better
> choice. When I just look at this name, I sure thought this
> CAP_SECURE_FIRMWARE true means it is a secure boot capable firmware.

Given there is nothing secure about it would it also be better to call it
AUTHENTICATED_BOOT ?

Alan

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

[Matthew Garrett]

On Tue, Sep 04, 2012 at 09:37:42PM +0100, Alan Cox wrote:
> > Gotta say this capability name is confusing. Naming is
> > CAP_PRE_SECURE_BOOT or something along the lines might be a better
> > choice. When I just look at this name, I sure thought this
> > CAP_SECURE_FIRMWARE true means it is a secure boot capable firmware.
> 
> Given there is nothing secure about it would it also be better to call it
> AUTHENTICATED_BOOT ?

Well, there is the question of whether the sense is correct - you'll 
only have this capability if you don't boot with any form of 
authentication. CAP_KERNEL_ACCESS?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Josh Boyer]

On Tue, Sep 04, 2012 at 09:37:32PM +0100, Matthew Garrett wrote:
> On Tue, Sep 04, 2012 at 09:37:42PM +0100, Alan Cox wrote:
> > > Gotta say this capability name is confusing. Naming is
> > > CAP_PRE_SECURE_BOOT or something along the lines might be a better
> > > choice. When I just look at this name, I sure thought this
> > > CAP_SECURE_FIRMWARE true means it is a secure boot capable firmware.
> > 
> > Given there is nothing secure about it would it also be better to call it
> > AUTHENTICATED_BOOT ?
> 
> Well, there is the question of whether the sense is correct - you'll 
> only have this capability if you don't boot with any form of 
> authentication. CAP_KERNEL_ACCESS?

I'm fine with whatever name we come up with, but I'd like to avoid
bikeshedding it in every patch.  Maybe we could work on the naming
through comments to the patch that actually adds the capability?

josh

[PATCH 11/11] 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_SECURE_FIRMWARE 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..0a1e348 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", "secure_firmware", NULL } },
 	{ "kernel_service", { "use_as_override", "create_files_as", NULL } },
 	{ "tun_socket",
 	  { COMMON_SOCK_PERMS, NULL } },
-- 
1.7.11.4

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

[Alan Cox]

On Tue,  4 Sep 2012 11:55:06 -0400
Matthew Garrett <mjg@redhat.com> wrote:

> The UEFI Secure Boot trust model is based on it not being possible for a
> user to cause a signed OS to boot an unsigned OS

Unfortunately you can't fix this at kernel level because an untrusted
application can at GUI level fake a system crash, reboot cycle and phish
any basic credentials such as passwords for the windows partition.

Alan

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

[Matthew Garrett]

On Tue, Sep 04, 2012 at 05:08:53PM +0100, Alan Cox wrote:
> On Tue,  4 Sep 2012 11:55:06 -0400
> Matthew Garrett <mjg@redhat.com> wrote:
> 
> > The UEFI Secure Boot trust model is based on it not being possible for a
> > user to cause a signed OS to boot an unsigned OS
> 
> Unfortunately you can't fix this at kernel level because an untrusted
> application can at GUI level fake a system crash, reboot cycle and phish
> any basic credentials such as passwords for the windows partition.

Any well-designed software asking for credentials should already be 
requiring a SAK, so in that case we just need to implement sensible SAK 
support in Linux.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Pavel Machek]

On Tue 2012-09-04 17:12:56, Matthew Garrett wrote:
> On Tue, Sep 04, 2012 at 05:08:53PM +0100, Alan Cox wrote:
> > On Tue,  4 Sep 2012 11:55:06 -0400
> > Matthew Garrett <mjg@redhat.com> wrote:
> > 
> > > The UEFI Secure Boot trust model is based on it not being possible for a
> > > user to cause a signed OS to boot an unsigned OS
> > 
> > Unfortunately you can't fix this at kernel level because an untrusted
> > application can at GUI level fake a system crash, reboot cycle and phish
> > any basic credentials such as passwords for the windows partition.
> 
> Any well-designed software asking for credentials should already be 
> requiring a SAK, so in that case we just need to implement sensible SAK 
> support in Linux.

So... the "secure" boot specification also describes what the SAK is?
It has to be same on all the operating systems to be effective.

And... you'd need to put SAK functionality into the kernel. (Currently
SAK only notifies _root_ user. You'd need to implement SAK
functionality displaying penguin with "This is not Windows"
message... in kernel).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html