archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <>
To: "Eric W. Biederman" <>
Subject: Re: [PATCH 07/11] kexec: Disable in a secure boot environment
Date: Wed, 5 Sep 2012 00:25:03 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Sep 04, 2012 at 03:12:52PM -0700, Eric W. Biederman wrote:
> Matthew Garrett <> 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 

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

> 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 

Matthew Garrett |

  reply	other threads:[~2012-09-04 23:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04 15:55 [RFC] First attempt at kernel secure boot support Matthew Garrett
2012-09-04 15:55 ` [PATCH 01/11] Secure boot: Add new capability Matthew Garrett
2012-09-04 15:55 ` [PATCH 02/11] PCI: Lock down BAR access in secure boot environments Matthew Garrett
2012-10-01 21:00   ` Pavel Machek
2012-09-04 15:55 ` [PATCH 03/11] x86: Lock down IO port " Matthew Garrett
2012-09-04 16:16   ` Alan Cox
2012-09-04 16:16     ` Matthew Garrett
2012-09-04 15:55 ` [PATCH 04/11] ACPI: Limit access to custom_method Matthew Garrett
2012-09-04 15:55 ` [PATCH 05/11] asus-wmi: Restrict debugfs interface Matthew Garrett
2012-09-04 16:12   ` Alan Cox
2012-09-04 16:13     ` Matthew Garrett
2012-09-04 15:55 ` [PATCH 06/11] Restrict /dev/mem and /dev/kmem in secure boot setups Matthew Garrett
2012-09-04 15:55 ` [PATCH 07/11] kexec: Disable in a secure boot environment Matthew Garrett
2012-09-04 20:13   ` Eric W. Biederman
2012-09-04 20:22     ` Matthew Garrett
2012-09-04 21:13       ` Eric W. Biederman
2012-09-04 21:27         ` Matthew Garrett
2012-09-04 22:12           ` Eric W. Biederman
2012-09-04 23:25             ` Matthew Garrett [this message]
2012-09-05  4:33               ` Eric W. Biederman
2012-09-05  5:16                 ` Matthew Garrett
2012-09-05  7:00                   ` Eric W. Biederman
2012-09-05  7:03                     ` Matthew Garrett
2012-09-04 21:39         ` Alan Cox
2012-09-04 21:40           ` Matthew Garrett
2012-09-05 15:43             ` Roland Eggner
2012-09-05 15:46               ` Matthew Garrett
2012-09-05 21:13   ` Mimi Zohar
2012-09-05 21:41     ` Matthew Garrett
2012-09-05 21:49       ` Eric Paris
2012-09-04 15:55 ` [PATCH 08/11] Secure boot: Add a dummy kernel parameter that will switch on Secure Boot mode Matthew Garrett
2012-09-04 15:55 ` [PATCH 09/11] efi: Enable secure boot lockdown automatically when enabled in firmware Matthew Garrett
2012-09-04 15:55 ` [PATCH 10/11] acpi: Ignore acpi_rsdp kernel parameter in a secure boot environment Matthew Garrett
2012-09-04 16:30   ` Shuah Khan
2012-09-04 16:38     ` Matthew Garrett
2012-09-04 16:44       ` Shuah Khan
2012-09-04 20:37         ` Alan Cox
2012-09-04 20:37           ` Matthew Garrett
2012-09-04 20:50             ` Josh Boyer
2012-09-04 15:55 ` [PATCH 11/11] SELinux: define mapping for new Secure Boot capability Matthew Garrett
2012-09-04 16:08 ` [RFC] First attempt at kernel secure boot support Alan Cox
2012-09-04 16:12   ` Matthew Garrett
2012-10-01 21:07     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).